Subject: Re: Possible ZSH bug with IO direction
From: "Peter A. Castro" <[email-masked]>
To: Bart Schaefer <[email-masked]>
Cc: [email-masked]
Date: Mon, 25 Apr 2016 10:31:54 -0700 (PDT)
List-Id: Zsh Workers List <zsh-workers.zsh.org>

On Sun, 24 Apr 2016, Bart Schaefer wrote:

> Date: Sun, 24 Apr 2016 11:35:58 -0700
> From: Bart Schaefer <[email-masked]>
> To: [email-masked]
> 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