Date: Wed, 11 Mar 2020 09:43:06 +0000
From: Stephane Chazelas <steph...@chazelas.org>
Message-ID: <20200311094306.kqqdsjyn7v4ik...@chazelas.org>
| But coding patterns like:
|
| f() (
| foo || return
| ...
| )
|
| are common.
Really? I have only rarely ever seen (aside from the occasional one
I write myself) sub-shell functions like that very rarely. I suspect
that most users don't even know it is legal.
I have occasionally seen
f() {(
# whetever, not usually including return
)}
which is just weird, but fits people's notions of what a sh function
should look like...
| If only for that, I think POSIX should require "return" to
| behave like exit in that case.
Yes, as I said we could do that, since it seems everyone already does.
I just don't think scripts should be written that way, subshells exit,
they don't return, and so it is clearer and more understandable to write
it that way,
| It would make sense for "return" to act as exit even outside of
| functions or sourced files. So you can have a script that can be
| both sourced and executed (or used as autoloadable function
| where supported).
Yes, there are times I would have liked that - but that definitely doesn't
work in general now - it would be new.
| AFAIK, bash and bosh are the only shells that complain when you
| use return outside of functions/sourced scripts (bash also
| doesn't exit upon that failing "return" special builtin in that
| case which could be seen as a conformance bug).
To the NetBSD sh, return in a script (not in a function) is a no-op.
Not an error, just a nothing (I don't think it even sets $? but I might
be mistaken about that.)
You can sit in front of an interactive shell and type return as many
times as you like, and none of them will do a thing.
| They're also
| the only shells that don't support some form or other of
| autoloadable functions (though support has also been removed in
| recent versions of some ash-based shells) which may be linked.
That would be unrelated. I think it is more that the auto-load stuff
was barely documented, and in practice, never used, or almost never.
NetBSD doesn't even bother installing the small handful of scripts
written with the intent to use that (providing pushd .... and a few
more similar things).
kre
