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.
In
f() (
foo || return
bar
)
that return should be guaranteed to exit the function (with
foo's exit status) if foo fails.
It's also important to keep the
2020-03-11 13:25:40 +0700, Robert Elz:
[...]
> What a return (or break or continue) in a subshell environment (but
> not in a function or dot script (or loop for break and continue) in that
> subshell does is unspecified. Some shells make it equivalent to exit,
> others ignore it, and others
Date:Tue, 10 Mar 2020 15:24:02 -0700
From:Donn Terry
Message-ID:
| Yes, I fully recognize that the goal is "standardizing existing practice"
| is a requirement of the standard, but as was pointed out, I believe in the
| Portland OR meeting (or the one after
If there is anything that needs fixing about this (I haven't checked
the whole standard for all the places where there might be relevant
text) it is to make it more clear that a sub-shell environment cannot
affect the parent shell in any way at all - other than via explicit I/O
(the output from a
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
On 3/11/20 10:49 AM, Dirk Fieldhouse wrote:
> On 11/03/20 14:03, Chet Ramey wrote:
>>...>
>> So what's the goal here? That the function continue execution in the
>> subshell so `return' has consistent, if baffling, semantics? That we
>> tighten up the language to make the unspecified specific?
On 3/11/20 11:13 AM, Stephane Chazelas wrote:
> 2020-03-11 09:55:57 -0400, Chet Ramey:
>> On 3/11/20 5:43 AM, Stephane Chazelas wrote:
>>
>>> 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
Chet Ramey wrote:
> > and that "foo" and not
> > "bar" should be printed in each case:
> >
> > f1() {
> > ( echo foo; return )
> > echo bar
> > }
>
> This implies some interprocess communication between the parent and child
> that simply doesn't exist, and nothing in the standard indicates
On 3/11/20 5:43 AM, Stephane Chazelas wrote:
> 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).
You
On 11/03/20 14:03, Chet Ramey wrote:
>...>
> So what's the goal here? That the function continue execution in the
> subshell so `return' has consistent, if baffling, semantics? That we
> tighten up the language to make the unspecified specific? What is this
> discussion intended to accomplish?
I
On 3/11/20 11:30 AM, Joerg Schilling wrote:
> Chet Ramey wrote:
>
>>> and that "foo" and not
>>> "bar" should be printed in each case:
>>>
>>> f1() {
>>> ( echo foo; return )
>>> echo bar
>>> }
>>
>> This implies some interprocess communication between the parent and child
>> that simply
2020-03-11 15:38:10 +0700, Robert Elz:
> Date:Wed, 11 Mar 2020 06:37:41 +
> From:Stephane Chazelas
> Message-ID: <20200311063741.wpkuiffb7jsyv...@chazelas.org>
>
> | What shell implementation "ignores" the return or "treat it as an
> | error" here.
>
>
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 printed in each case:
>
> f1() {
>( echo foo; return )
>echo bar
> }
Dop yo know a single shell that
On 3/11/20 11:13 AM, Stephane Chazelas wrote:
> 2020-03-11 09:55:57 -0400, Chet Ramey:
>> On 3/11/20 5:43 AM, Stephane Chazelas wrote:
>>
>>> 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
On 3/11/20 9:12 AM, Dirk Fieldhouse wrote:
> 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
2020-03-11 09:55:57 -0400, Chet Ramey:
> On 3/11/20 5:43 AM, Stephane Chazelas wrote:
>
> > 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
Date:Wed, 11 Mar 2020 09:43:06 +
From:Stephane Chazelas
Message-ID: <20200311094306.kqqdsjyn7v4ik...@chazelas.org>
| But coding patterns like:
|
| f() (
| foo || return
| ...
| )
|
| are common.
Really? I have only rarely ever seen (aside
2020-03-11 18:42:48 +0700, Robert Elz:
[...]
> | 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 certainly use it and have seen it
Robert Elz wrote:
> Date:Tue, 10 Mar 2020 15:24:02 -0700
> From:Donn Terry
> Message-ID:
>
> | (No, not csh... something closer to Bourne/ksh than that.)
>
> That you'd even mention csh as a possibility in a context like this
> is mind boggling. csh is based
Date:Wed, 11 Mar 2020 06:37:41 +
From:Stephane Chazelas
Message-ID: <20200311063741.wpkuiffb7jsyv...@chazelas.org>
| What shell implementation "ignores" the return or "treat it as an
| error" here.
You're right, I must have been remembering (always dangerous
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 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 printed in each case:
>>
>> f1() {
>> ( echo foo; return
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 from:
> If the shell is not currently executing a function
> or dot script, the results are unspecified.
> to:
> If the shell is
Would this issue be resolved if we change the last sentence of the description
section of the return Special Built-In Utility from:
If the shell is not currently executing a function
or dot script, the results are unspecified.
to:
If the shell is not currently executing a function
On 3/11/20 11:46 AM, Joerg Schilling wrote:
> Since you most likely develop on Linux
I don't; don't make assumptions.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.edu
On 3/11/20 11:52 AM, Joerg Schilling wrote:
> Chet Ramey wrote:
>
>> On 3/11/20 11:46 AM, Joerg Schilling wrote:
>>
>>> Since you most likely develop on Linux
>>
>> I don't; don't make assumptions.
>
> Interesting, where do you develop?
I use Mac OS X. I test on Linux.
By far, the biggest
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
Chet Ramey wrote:
> > I don't see that we should do this, but id you like to be able to reably
> > get a
> >
> > ``NOEXEC'' or ``NOTFOUND''
> >
> > from expanding "$/", there is a need for interprocess communication unless
> > you
> > use vfork() for that specific command.
>
> What is
I agree this is something suitable for a TC type resolution. However, given the
amount of existing practice, I do not see we should leave anything unspecified
for Issue 8, even if some implementations break as a result.
Either it always stops function execution or dot file processing, which
Chet Ramey wrote:
> On 3/11/20 11:46 AM, Joerg Schilling wrote:
>
> > Since you most likely develop on Linux
>
> I don't; don't make assumptions.
Interesting, where do you develop?
Jörg
--
EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
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
31 matches
Mail list logo
