zsh-workers
 help / color / mirror / code / Atom feed
From: Stephane Chazelas <stephane.chazelas@gmail.com>
To: Martijn Dekker <martijn@inlv.org>
Cc: zsh-workers@zsh.org
Subject: Re: [doc] "sh_word_split nothing to do with word splitting"?
Date: Mon, 12 Mar 2018 07:43:29 +0000	[thread overview]
Message-ID: <20180312074329.GA6416@chaz.gmail.com> (raw)
In-Reply-To: <cacccc9e-b727-2091-2422-f71d5ea4ca2f@inlv.org>

2018-03-12 00:41:03 +0100, Martijn Dekker:
> Op 11-03-18 om 21:53 schreef Stephane Chazelas:
> > What about changing it to something like:
> [...]
> > +Causes tt($IFS) field splitting to be performed on unquoted parameter
> > +expansions in addition to command substitutions. Note that contrary to
> > +POSIX shells, field splitting is still not performed on unquoted
> > +arithmetic expansions
> 
> In terms of sh emulation, that's actually a bug. It may be terrible (who
> would ever want to split an arithmetic expansion?), but emulation is
> emulation and SH_WORD_SPLIT should cause splitting as in POSIX sh.

I'd rather zsh keep it that way as a statement of resistance
against silliness, at least until someone complains that his
POSIX script fails when run on zsh because its arithmetic
expansions are not split as expected.

Not doing so would keep fixing scripts where authors omitted to
quote arithmetic expansions in contexts where $IFS contained
dashes (or digits) on the ground that no shell author in their
right mind would ever want to subject arithmetic expansion to
split+glob (note that no shell does split+glob upon tilde
expansion nor process substitution nor $'...' expansions (though
bash used to do globbing upon tilde expansion) where that
wouldn't make sense *either*).

pdksh was not doing word/field splitting there and posh and
OpenBSD sh still don't.

> 
> >                        and contrary to the Bourne shell, not on words
> > +that are not the result of expansions.
> 
> Now that even Solaris finally got rid of it, I think the ancient Bourne
> shell is definitively obsolete and not worth mentioning in current
> documentation. POSIX is the norm now.

Agreed. I suspect the original text was making that point about
"shwordsplit having nothing to do with word splitting" in
reference to the Bourne shell.

> >                                         Like in other Bourne-like shells,
> 
> I'd say "Like in other POSIX shells,".

Except that zsh (like many other Bourne-like shells) is not
strictly speaking fully compliant (though on several aspects is more
compliant in sh emulation than some certified ones like the
/usr/xpg4/bin/sh of Solaris)

> [...]
> > Not sure it's worth mentioning:
> > 
> > $var() function-definition
> > 
> > as a context where shwordsplit happens.
> 
> It might be better if the possibility to define functions by names
> resulting from expansions were disabled completely if SH_WORD_SPLIT is
> active, so the program fails properly instead of producing weird/broken
> behaviour.
> 
> Alternatively, SH_WORD_SPLIT could be ignored in that context.
[...]

AFAIK, that's a feature which is actually used in some of the
functions shipped with zsh to declare several functions at once
with the same body.

It's not a POSIX conformance issue as the behaviour is
unspecified there for:

$var() { ...; }

As $var is not a valid function name.

In any case, I wouldn't expect anyone to use SH_WORD_SPLIT for
anything but to interpret POSIX/ksh scripts (via "emulate sh/ksh")
which wouldn't have such constructs, so I don't expect it would
cause any problem.

On the other hand, one might still want to do:

$=myfunctions() { something; zle .$WIDGET; }

for instance, that is using the explicit word-split operator to
define several functions at once.

-- 
Stephane


  reply	other threads:[~2018-03-12  7:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-11  9:44 Stephane Chazelas
2018-03-11 18:24 ` Bart Schaefer
2018-03-11 20:53   ` Stephane Chazelas
2018-03-11 23:41     ` Martijn Dekker
2018-03-12  7:43       ` Stephane Chazelas [this message]
2018-03-12  8:07         ` Stephane Chazelas
2018-03-16 17:26           ` Stephane Chazelas
2018-03-16 18:28             ` Bart Schaefer
2018-03-16 19:33               ` Stephane Chazelas
2018-03-24 20:17         ` Martijn Dekker
2018-03-25  6:42           ` Stephane Chazelas
2018-03-26 18:11             ` Martijn Dekker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180312074329.GA6416@chaz.gmail.com \
    --to=stephane.chazelas@gmail.com \
    --cc=martijn@inlv.org \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).