zsh-workers
 help / color / Atom feed
* RFC: &&/|| vs. & operator precedence
@ 2019-08-24 20:16 Martijn Dekker
  2019-08-24 21:20 ` Archives (was: RFC: &&/|| vs. & operator precedence) Daniel Shahaf
  0 siblings, 1 reply; 2+ messages in thread
From: Martijn Dekker @ 2019-08-24 20:16 UTC (permalink / raw)
  To: Zsh hackers list

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Archives (was: RFC: &&/|| vs. & operator precedence)
  2019-08-24 20:16 RFC: &&/|| vs. & operator precedence Martijn Dekker
@ 2019-08-24 21:20 ` Daniel Shahaf
  0 siblings, 0 replies; 2+ messages in thread
From: Daniel Shahaf @ 2019-08-24 21:20 UTC (permalink / raw)
  To: Martijn Dekker, Zsh hackers list

Martijn Dekker wrote on Sat, 24 Aug 2019 20:17 +00:00:
> Sorry if this has been discussed before -- it's hard to search for '&' 
> in the archives.

No comment on the rest of your question, but mbox format archives are available here:

http://www.zsh.org/mla/zsh-workers/

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-24 20:16 RFC: &&/|| vs. & operator precedence Martijn Dekker
2019-08-24 21:20 ` Archives (was: RFC: &&/|| vs. & operator precedence) Daniel Shahaf

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git