From: Martijn Dekker <martijn@inlv.org>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: RFC: &&/|| vs. & operator precedence
Date: Sat, 24 Aug 2019 22:16:44 +0200 [thread overview]
Message-ID: <b2272b65-b677-b129-a83a-e126d2583989@inlv.org> (raw)
Sorry if this has been discussed before -- it's hard to search for '&'
in the archives.
On all other shells,
true && false || foo &
launches 'true && false || foo' as a background job. On zsh (including
sh mode), only 'foo' is the background job.
IOW, the '&' operator on other POSIX shells takes an entire AND-OR
(&&/||) list as the background job, whereas on zsh, only the last
command is taken as the background job.
POSIX says in 2.9.3:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_03
| A list is a sequence of one or more AND-OR lists separated by the
| operators ';' and '&'.
but later on in 2.9.3.1:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_03_02
| If a command is terminated by the control operator <ampersand> ( '&'
| ), the shell shall execute the command asynchronously in a subshell.
So that is quite ambiguous. The first suggests that '&' should act like
most POSIX shells do, the second suggests it should act like zsh does.
This ambiguity is basically the subject of an Austin Group bug opened by
Stéphane Chazelas:
http://austingroupbugs.net/view.php?id=1254
He is proposing that POSIX should prescribe the behaviour of the
majority, which would make zsh non-compliant as of the next POSIX edition.
An alternative might be to make this unspecified instead, so that both
zsh and other shells are compliant as is, and cross-platform scripters
would be expected to use explicit braces where necessary (as they
already have to do now).
So, in anticipation of this being resolved one way or another in POSIX,
it might be worth discussing what (if anything) should change in zsh. I
think the opinion of the zsh maintainers matters here.
Would it be feasible to make zsh act like other POSIX shells in sh
emulation mode only? I could imagine that being difficult as this
touches on shell grammar, not builtins.
If not, would it be acceptable to change the precedence of these
operators to match other POSIX shells in zsh as a whole? How many old
zsh scripts could that break?
- Martijn
--
modernish -- harness the shell
https://github.com/modernish/modernish
next reply other threads:[~2019-08-24 20:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-24 20:16 Martijn Dekker [this message]
2019-08-24 21:20 ` Archives (was: RFC: &&/|| vs. & operator precedence) Daniel Shahaf
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=b2272b65-b677-b129-a83a-e126d2583989@inlv.org \
--to=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).