On 11/03/20 06:25, Robert Elz wrote:
... The standard by [referring to 'subshell environment'] is trying ...
to avoid constraining the implementation, things that an implementation
can work out how to do without forking it can do (which will make it
faster, and less expensive to run) - but it
to accomplish?
I refer you to this excerpt:
> On 3/11/20 9:12 AM, Dirk Fieldhouse wrote:>...>
>> a)the wording of the standard about 'return' doesn't say this (or
>> as you said,
>>> what [I] believe it appears to say, and what it
>>> actually means, are
On 11/03/20 06:31, Stephane Chazelas wrote:
IMO,
the best and only reasonable way to address it is to specify
what all shells do: return works like exit when called in a
subshell.
But behaving like 'exit' is not the same as exiting the function and
resuming at the next command, which is
On 12/03/20 20:21, Harald van Dijk wrote:
On 11/03/2020 17:44, Don Cragun wrote:
Would this issue be resolved if we change the last sentence of the
description section of the return Special Built-In Utility ...
If the shell is not currently executing a function
or dot script running
On 14/03/20 01:26, Robert Elz wrote:
Date:Fri, 13 Mar 2020 16:49:14 +
From:Dirk Fieldhouse
Message-ID:
| But as 'return' is behaving like 'exit', and not actually returning (ie,
| setting $?=7 in the invoking shell and not printing no or 7
On 11/03/20 15:01, Joerg Schilling wrote:
> Dirk Fieldhouse wrote:
>
>> As to "baffling semantics", I suggest that these are two examples
>> where 'return' is meaningful (and far from baffling) and that "foo"
>> and not "bar" should be printe
On 11/03/20 15:23, Chet Ramey wrote:
...>
What does a `return from the execution environment' mean, exactly? ...
To clarify, what I wrote was shorthand for "return from the function if
the 'return' is executed in the same execution environment as" the
function's defining command, or otherwise
1 Summary
XCU Ch2.14 states that 'return' shall cause the shell to leave the
current function or dot script, if any. Ch2.95 says that execution shall
continue with the next command after the function call. Implementations
that claim conformance consistently contradict this specification,
On 11/03/20 17:32, Don Cragun wrote:
... notice that I said "in the same shell execution environment as the command that invoked
..."; not "in the same shell execution environment as the function's defining
command". If a function is invoked in a subshell of the environment that defined the
On 12/03/20 20:59, Dirk Fieldhouse wrote:
...>
If Harald's suggestion is accepted, the handling of functions (defined
by a compound-command) and dot scripts (not so defined) would be
different and the DESCRIPTION of 2.14 'return' should probably be split
into two cases to avoid confus
On 15/03/20 07:26, Robert Elz wrote:
>...>
>[I wrote:]>| Is there any suggestion that the 'exit'-like
behaviour of any shell that
| implements it for 'return' in such contexts is subtly different from
'exit'?
Not that I am aware of. exit is kind of blunt, it is quite hard to
be subtly
ree on EXIT traps]
Another test relevant to the HvD option below is
f() ( trap "echo FOO" EXIT; return 5; echo BAR ); f
which doesn't run the EXIT trap in bash-4.3 and dash-0.5.8.2, and so
indicates that this case should be considered as return-like rather than
exit-like.
And on 13/03/2
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
On 15/03/20 16:43, Harald van Dijk wrote:
...> >
"Before the shell terminates" is not limited to "before the top level
shell terminates". If a shell terminates, even if it is a subshell that
terminates, any EXIT trap action should be run.
Sure, that is the intended interpretation, but this
On 16/03/20 11:44, Joerg Schilling wrote:
> Dirk Fieldhouse wrote:
>
>...>
>
> Could you explain why you mention Ultrix that comes with a really
ancient shell?
>
>...
>
Given that the original intention of POSIX was to use ksh88 as a boiler plate
for the POSIX shell,
On 16/03/20 14:37, Robert Elz wrote:
Date:Sun, 15 Mar 2020 14:44:51 +
From:Dirk Fieldhouse
Message-ID: <55e0c45a-f13c-fa1d-db22-4c0a1b02d...@gmx.net>
...>
You need to read the whole standard to understand it, you cannot simply
read one sec
On 10/03/20 18:25, shwaresyst wrote:
>
> I basically agree this is an issue - I see return as more for being
interpreted as a lexical scope abort, whatever the execution context,
and exit an execution scope abort, such as a subshell or separate script
utility environment, as their basic intent.
On 09/08/20 00:18, Larry Dwyer via austin-group-l at The Open Group wrote:
How about the "control" side and the "terminal" side (of the paired
device files)?
All good -- until abused partners ("coercive control") or people
imminently expected to die, and their supporters, start a clamour.
In
18 matches
Mail list logo
