On 13/03/20 14:57, Martijn Dekker wrote:
Op 13-03-20 om 15:17 schreef Chet Ramey:
On 3/13/20 10:14 AM, Harald van Dijk wrote:
[...]
I don't see how you can allow that without also allowing
f() { (return 7; echo no); echo $?; }; f
...>
My testing says it acts identically (outputs '7') on the following
shells: ash variants (Busybox ash, dash, FreeBSD sh, gwsh, NetBSD sh),
bash, bosh, ksh88, ksh93, mksh, pdksh, yash, and zsh.
But as 'return' is behaving like 'exit', and not actually returning (ie,
setting $?=7 in the invoking shell and not printing no or 7) in this
case, might it not be better to leave such usage for a commentary in
non-normative text?
If 'return' doesn't return from general subshell contexts, shell
programmers have to live with work-arounds like
f() { (exit 7; echo no); return; }
instead of
f() { (return 7; echo no); }
There's no point encouraging people to use 'return' in a context where
it may not, let alone where it doesn't; they should use 'exit' which
already has specified behaviour in that context.
Therefore I don't think the normative text should cover the case offered
by Chet Ramey on 13/03/20 13:10:
>...>
>
We should be able to do better than that. I don't see why "if not executing
in the same shell execution environment as the compound-list ..." can't
cover the f() { (return 1) } case as well, and seems to work in all shells.
It would be more accurate to say that it fails weirdly in all shells.
/df
--
London SW6
UK
