From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19417 invoked by alias); 25 Apr 2016 17:33:36 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 38339 Received: (qmail 13855 invoked from network); 25 Apr 2016 17:33:35 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,TVD_RCVD_IP autolearn=ham autolearn_force=no version=3.4.1 Date: Mon, 25 Apr 2016 10:31:54 -0700 (PDT) From: "Peter A. Castro" To: Bart Schaefer cc: zsh-workers@zsh.org Subject: Re: Possible ZSH bug with IO direction In-Reply-To: <160424113558.ZM3564@torch.brasslantern.com> Message-ID: References: <571BBF3C.50402@matrix.ai> <160423151436.ZM6912@torch.brasslantern.com> <571CFD70.7090506@matrix.ai> <160424113558.ZM3564@torch.brasslantern.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sun, 24 Apr 2016, Bart Schaefer wrote: > Date: Sun, 24 Apr 2016 11:35:58 -0700 > From: Bart Schaefer > To: zsh-workers@zsh.org > Subject: Re: Possible ZSH bug with IO direction Greetings, Bart, > On Apr 25, 3:08am, Roger Qiu wrote: > } Subject: Re: Possible ZSH bug with IO direction > } > } Thanks, the workaround did work. But I've never seen read & write > } redirection at the interactive prompt. Does that make the STDIN for the > } program I'm running readable and writable? > > Yes. > > } How does that work? > > Stdin/out/err are just file descriptors 0/1/2. They can be open in > whatever mode the parent process likes. It wouldn't make much sense > to have stdin open for write only, but nothing prevents that. > > Consider that /dev/tty is all of stdin/out/err for most interactive > programs. It's open read/write even though programs don't usually treat > the individual descriptors that way. > > } Can the program then rewind that descriptor, and write to `input.jpg`? > > If the program were using system-call interfaces on descriptor 0, yes. > However the STDIO library object STDIN will still be initialized for > reading only, so in most cases the program won't notice. That was kind of the idea. The program wouldn't know and can happily read input as if it were a proper-unix text file. That the file isn't really "text" is beyond scope. :) > } Also since Bash doesn't suffer from this problem, will this be fixed > } eventually? > > As the comment from main.c explains, it's a question of either breaking > a few external programs that care about raw file data, or breaking the > entire internal string-processing in e.g. zsh's parameter substitution > any time those strings are read from a file. So I would expect the > answer is that this won't change unless Cygwin changes something. Also, > we're woefully short on any volunteers for Windows-specific issues. Really you need to fix Windows, not Cygwin. Or you need to fix every program that's ported to Cygwin. Cygwin is trying to bridge the two worlds the best it can, with as little code change as possible. That it's imperfect is implied. I believe the best solution is to teach Zsh code to handle CR+LF properly, but I lack knowledge of the internal workings to addequate do this. -- --=> Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com "Cats are just autistic Dogs" -- Dr. Tony Attwood