Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160424145300.ZM4045@torch.brasslantern.com>
Date: Sun, 24 Apr 2016 14:53:00 -0700
In-Reply-To: <20160424200132.7d0d00bc@ntlworld.com>
Comments: In reply to Peter Stephenson <p.w.stephenson@ntlworld.com>
        "Re: Possible ZSH bug with IO direction" (Apr 24,  8:01pm)
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>
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 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.