Zsh Mailing List Archive
Messages sorted by:
Re: shwordsplit: final non-whitespace IFS character problem
- X-seq: zsh-workers 41488
- From: Stephane Chazelas <stephane.chazelas@xxxxxxxxx>
- To: Martijn Dekker <martijn@xxxxxxxx>
- Subject: Re: shwordsplit: final non-whitespace IFS character problem
- Date: Fri, 4 Aug 2017 11:56:01 +0100
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=u3WzSvKdG7lUqsW0E4V2OQ9JKmlwdfqpaWlce+zvgDs=; b=GHm5zcaONnA6dPU/sHiCNf0j4nNDyDjKyM4Re0+N8Y+uYDvnFnryUZPCqpZrSZnKeT qSYX/OPtCg5P8dTa5UxZy98S8q91qwHJLURSz/wm/HiUiQU01BDEuhgIMEDRqcZATZP7 nO0VMuBi3bN7bB0r0ZhTUSZYX6f/y7SuFwJUPpTNgpzMX9r9hK+el7WiM+ce0x8hd0f9 ZYQSgxBQk6fLoqXTz282BDtCTBHBECwHq2Zm3T02xiX4SihOS3+nPM9K4Q3UxLNLd//B akHA+l6HvaQfeZww8btNty9OrfLkdIvx0fMtM/KELix5SS3ZgCcj0T93y7lgGC1Ej1I7 VMzQ==
- In-reply-to: <email@example.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mail-followup-to: Martijn Dekker <martijn@xxxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <firstname.lastname@example.org>
2017-08-04 04:03:19 +0200, Martijn Dekker:
> In field/word splitting, a final non-whitespace IFS delimiter character
> is counted as an empty field. This is unlike every other current shell
> (including current versions of pdksh, i.e. mksh and OpenBSD ksh).
> Test script:
> setopt shwordsplit
> set -- $x
> echo $#
IIRC, it was discussed before, and the concensus at the time was
that it would be silly as the S in IFS stands for *S*eparator, not
terminator nor delimiter. At the time though, a number of shells
(pdksh and ash based ones) still behaved like zsh and not ksh88
and POSIX was even less clear about it.
Note that, it also affects "read", where "IFS=: read var" on an
output that contains "word:" should (as per POSIX) store "word"
into "var" (while it "should" store "word1:word2:" on a line
I can't imagine changing the behaviour in the sh/ksh emulations
would be a problem (though I still think it's silly).
Note that with that semantic, you can no longer do things like:
set -o noglob
for dir in $PATH; do
You need to use some kludge like the "which" POSIX script does
on Debian to account for PATHs like "/bin:/usr/bin:".
Messages sorted by: