Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <160424145300.ZM4045@torch.brasslantern.com>
References: <571BBF3C.50402@matrix.ai>
	<160423151436.ZM6912@torch.brasslantern.com>
	<20160424131748.441d605f@pwslap01u.europe.root.pri>
	<160424113644.ZM3576@torch.brasslantern.com>
	<20160424200132.7d0d00bc@ntlworld.com>
	<160424145300.ZM4045@torch.brasslantern.com>
Date: Mon, 25 Apr 2016 23:12:51 +0200
Message-ID: <CAHYJk3T_hS5S_bnVHgGMN5=42BG38Y5_Mg-pG5i9FHQoSRd79A@mail.gmail.com>
Subject: Re: Possible ZSH bug with IO direction
From: Mikael Magnusson <mikachu@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh workers <zsh-workers@zsh.org>
Content-Type: text/plain; charset=UTF-8

On Sun, Apr 24, 2016 at 11:53 PM, 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.

It's perhaps worth noting that (f) is explicitly documented as being
short for ps:\n: and nothing else.

-- 
Mikael Magnusson