Re: Possible ZSH bug with IO direction

[Peter Stephenson <p.stephenson@samsung.com>]

On Sun, 24 Apr 2016 14:53:00 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 24,  8:01pm, Peter Stephenson wrote:
> }
> } The alternative might be to do something similar in the lower levels of
> } zsh, i.e. map \r\n to \n when reading shell input.  If done in input.c
> } it's no worse than doing it in the OS abstraction, and doesn't affect
> } fd's used by othe programmes.
> 
> Will input.c cover the $(...) construct, "read" command, etc.?  All of
> those have to get CRFL translation or things like ${(f)...} don't work;
> stray \r end up in parameter values, and so on.

Commands within $(...) are processed as part of normal shell input, but
if you're executing an external command inside and processing the output
as text that's another matter.  "read" and implicit reads such as
"$(<...)" are similar.  In general you don't know whether you expect the
output to be text or binary; there's nothing to stop you capturing
raw data using a $(...).  There are partial workarounds for read
and word splitting by adding $'\r' to IFS.

pws