Re: XCU: 'return' from subshell

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, it may be an unwanted break

Re: XCU: 'return' from subshell

Robert Elz wrote: > I was referring to "in the standard". The standard is not static, > things are added (or move from unspecified to specified) as the > implementations converge upon some common definition for something new > or previously unspecified, and things are deleted when they become

Re: XCU: 'return' from subshell

Dirk Fieldhouse wrote: > You're reading too much into "If". I think it's clear that design > decisions from several decades ago take precedence, regardless of what > anyone would prefer. Eg > > where apparently the case

Re: XCU: 'return' from subshell

On 15/03/20 07:26, Robert Elz wrote: >[a test on a range of current shell implementations show that 'return' from a function, when run in an execution environment different from that in which the function's compound-command is run, behaves like 'exit' except that implementations don't agree on

Re: XCU: 'return' from subshell

Date:Sat, 14 Mar 2020 22:43:05 + From:Dirk Fieldhouse Message-ID: <06785188-5da9-1494-2af3-4456759cb...@gmx.net> | The fact that a behaviour exists in a wide range of implementations, in | a context held by many experts to be unspecified by the current |

Re: XCU: 'return' from subshell

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) in this

Re: XCU: 'return' from subshell

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) in this | case, might it not be better to leave such

Re: XCU: 'return' from subshell

Date:Fri, 13 Mar 2020 14:14:24 + From:Harald van Dijk Message-ID: | I don't see how you can allow that without also allowing | |f() { (return 7; echo no); echo $?; }; f | | If that also works in all shells (meaning it doesn't print no, and does

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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 If that also works in all shells (meaning it doesn't print no, and does print 7), then by all means

Re: XCU: 'return' from subshell

On 3/13/20 10:14 AM, Harald van Dijk wrote: >>> Can this instead say "in the same shell execution environment as the >>> compound-list of the compound-command of the function definition", so that >>> >>>    f() (return 1) >>> >>> which is fairly sensible and works in all shells[*] remains

Re: XCU: 'return' from subshell

On 13/03/2020 13:10, Chet Ramey wrote: On 3/12/20 4:21 PM, 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 from: If the shell is not currently

Re: XCU: 'return' from subshell

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 confusion. For

Re: XCU: 'return' from subshell

On 3/12/20 4:21 PM, 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 from: >> If the shell is not currently executing a function >> or dot

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

On 3/11/20 5:24 PM, Dirk Fieldhouse wrote: > Even with this wording, it isn't clear that there is "the function or > dot script, if any" (ie just one, or none) without first applying the > restriction to the same execution environment, depending on whether you > think that asynchronous commands

Re: XCU: 'return' from subshell

On 3/11/20 1:32 PM, 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: >

Re: XCU: 'return' from subshell

On 3/11/20 1:07 PM, Dirk Fieldhouse wrote: > 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

Re: XCU: 'return' from subshell

On 3/11/20 12:15 PM, Dirk Fieldhouse wrote: > >> All shells I am aware of print foo and bar > > The discussion seems to have confirmed that this is the general existing > practice, and not just in the few cases I tested, but IMO only a shell > implementer could see the suggested behaviour of

Re: XCU: 'return' from subshell

On 3/12/20 6:02 AM, Joerg Schilling wrote: > Chet Ramey wrote: > >> I use Mac OS X. I test on Linux. >> >> By far, the biggest difference between older Mac OS X/Linux and current Mac >> OS X is using lldb instead of gdb for debugging. > > OK, I develop on Solaris and like dbx in favor of gxb at

Re: XCU: 'return' from subshell

Chet Ramey wrote: > I use Mac OS X. I test on Linux. > > By far, the biggest difference between older Mac OS X/Linux and current Mac > OS X is using lldb instead of gdb for debugging. OK, I develop on Solaris and like dbx in favor of gxb at al. but it seems to be a pity that the Solaris

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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?

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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. > >

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

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

Re: XCU: 'return' from subshell

After some thought, I believe I'd be in favor more of: a) adding explicitly that '{' and '(' introduce a new lexical scope, balanced by '}' and ')' respectively; b) when such scopes are asynchronous return shall function the same as exit, with, as App Usage, it is up to any trap action for

Re: XCU: 'return' from subshell

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.

RE: XCU: 'return' from subshell

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. Further complicating things, I don't