From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-38333-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 25757 invoked by alias); 25 Apr 2016 08:56:54 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 38333
Received: (qmail 20022 invoked from network); 25 Apr 2016 08:56:52 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.1
X-AuditID: cbfec7f5-f792a6d000001302-a8-571dd974a207
Date: Mon, 25 Apr 2016 09:46:41 +0100
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: Possible ZSH bug with IO direction
Message-id: <20160425094641.7ce89157@pwslap01u.europe.root.pri>
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>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsVy+t/xa7olN2XDDd62CFscbH7I5MDoserg
	B6YAxigum5TUnMyy1CJ9uwSujLtTtjMX7OComPtpH2MD4x22LkZODgkBE4l182dA2WISF+6t
	B7K5OIQEljJKTO67zwThzGCS+LnvKwuEc45Rom/ecWaQFiGBs4wS5+c7gNgsAqoSt/o/sYLY
	bAKGElM3zWYEsUUExCXOrj3PAmILC+hLnH95CqyGV8BeYsbJDWA2p4ClxKc5x6C2TWKS2HD8
	ExNIgh+o4epfCFsCqGHmlTOMEM2CEj8m3wMbyiygJbF5WxMrhC0vsXnNW6jj1CVu3N3NPoFR
	eBaSlllIWmYhaVnAyLyKUTS1NLmgOCk910ivODG3uDQvXS85P3cTIySgv+5gXHrM6hCjAAej
	Eg/vBxbZcCHWxLLiytxDjBIczEoivLLXgEK8KYmVValF+fFFpTmpxYcYpTlYlMR5Z+56HyIk
	kJ5YkpqdmlqQWgSTZeLglGpgjGKRfuPWbZKkI9y2UV1s0/xHTx/NmPXY4xpvo/XKdWITRILZ
	t3WuYTHmcupkOvYkccOdNs930X1ie4uSPkydcV301GTW8+x/E56e/n1k8YkTvpFpSXsqhWew
	mGyqkEoyi123wULj0eo5DD2avf8/ugtI96T+kWjj01zTL3LsUyUHk4vw6YgAJZbijERDLeai
	4kQAODeGpWQCAAA=

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