Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160424113558.ZM3564@torch.brasslantern.com>
Date: Sun, 24 Apr 2016 11:35:58 -0700
In-Reply-To: <571CFD70.7090506@matrix.ai>
Comments: In reply to Roger Qiu <roger.qiu@matrix.ai>
        "Re: Possible ZSH bug with IO direction" (Apr 25,  3:08am)
References: <571BBF3C.50402@matrix.ai> 
	<160423151436.ZM6912@torch.brasslantern.com> 
	<571CFD70.7090506@matrix.ai>
To: zsh-workers@zsh.org
Subject: Re: Possible ZSH bug with IO direction
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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.

} 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.