* function definition with & operator @ 2017-09-01 18:09 Eric Cook 2017-09-01 20:46 ` Bart Schaefer 2017-09-02 19:37 ` Peter Stephenson 0 siblings, 2 replies; 5+ messages in thread From: Eric Cook @ 2017-09-01 18:09 UTC (permalink / raw) To: zsh-workers The other week when messing around i noticed that you can define an function in (what i thought would be) the background and it will remain in defined. % foo() bar & type -f foo foo () { bar } % unfunction foo % { foo() { bar }; : } & type -f foo [1] 14551 foo not found I don't have an actual use for it, but it is an minor bug. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: function definition with & operator 2017-09-01 18:09 function definition with & operator Eric Cook @ 2017-09-01 20:46 ` Bart Schaefer 2017-09-01 21:23 ` Eric Cook 2017-09-02 19:37 ` Peter Stephenson 1 sibling, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2017-09-01 20:46 UTC (permalink / raw) To: zsh-workers On Fri, Sep 1, 2017 at 11:09 AM, Eric Cook <llua@gmx.com> wrote: > The other week when messing around i noticed that you can define an function > in (what i thought would be) the background and it will remain in defined. Background jobs are always run in a subshell, even if you use the { command } syntax. There is no such thing as a background job in the current shell. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: function definition with & operator 2017-09-01 20:46 ` Bart Schaefer @ 2017-09-01 21:23 ` Eric Cook 2017-09-02 19:23 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Eric Cook @ 2017-09-01 21:23 UTC (permalink / raw) To: zsh-workers On 09/01/2017 04:46 PM, Bart Schaefer wrote: > On Fri, Sep 1, 2017 at 11:09 AM, Eric Cook <llua@gmx.com> wrote: >> The other week when messing around i noticed that you can define an function >> in (what i thought would be) the background and it will remain in defined. > > Background jobs are always run in a subshell, Exactly what i thought, but if that were the case, foo wouldn't be defined after the first example since & was the terminator used instead of ;. The second example behaves like i would expect. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: function definition with & operator 2017-09-01 21:23 ` Eric Cook @ 2017-09-02 19:23 ` Bart Schaefer 0 siblings, 0 replies; 5+ messages in thread From: Bart Schaefer @ 2017-09-02 19:23 UTC (permalink / raw) To: zsh-workers On Fri, Sep 1, 2017 at 2:23 PM, Eric Cook <llua@gmx.com> wrote: > On 09/01/2017 04:46 PM, Bart Schaefer wrote: >> On Fri, Sep 1, 2017 at 11:09 AM, Eric Cook <llua@gmx.com> wrote: >>> The other week when messing around i noticed that you can define an function >>> in (what i thought would be) the background and it will remain in defined. >> >> Background jobs are always run in a subshell, > > Exactly what i thought, but if that were the case, foo wouldn't be defined after > the first example since & was the terminator used instead of ;. Oh, I see. I read "in defined" as a typo or auto-correct-o for "undefined" and thought you were complaining about the "{ ... } &" example. Yes, this is odd, and it appears to have always been this way. However, it's a bit more than a minor bug, because it also affects anonymous functions; compare: zsh -fc '{ sleep 10 } & print $SECONDS' 0 zsh -fc '() { sleep 10 } & print $SECONDS' 10 What's going on here is that a function definition is not actually a command, it's a syntax construct that is special-cased in exec.c. However, I'm not sure how to resolve it. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: function definition with & operator 2017-09-01 18:09 function definition with & operator Eric Cook 2017-09-01 20:46 ` Bart Schaefer @ 2017-09-02 19:37 ` Peter Stephenson 1 sibling, 0 replies; 5+ messages in thread From: Peter Stephenson @ 2017-09-02 19:37 UTC (permalink / raw) To: zsh-workers On Fri, 1 Sep 2017 14:09:55 -0400 Eric Cook <llua@gmx.com> wrote: > The other week when messing around i noticed that you can define an function > in (what i thought would be) the background and it will remain in defined. > > % foo() bar & type -f foo > foo () { > bar > } > % unfunction foo > % { foo() { bar }; : } & type -f foo > [1] 14551 > foo not found > > I don't have an actual use for it, but it is an minor bug. Potentially major with anonymous functions: % () { in_background=1; } & % print $in_background 1 That's definitely not expected. The problem appears to be actually quite general --- we decide a sublist (something up to a || or &&, unless an list terminator comes along first) is simple before we look for a & or relative. If we decide it is simple, we then ignore the effect of the & or |. We keep the effect for the list, which isn't marked simple, but that doesn't help fix it for the sublist. I'm really not sure how we've got away with this but I think it's because execsimple() only does a limited amount locally and if the list is simple enough that the fork happens right down in the lowest levels it will still happen; that doesn't apply in the case of a function definition which execsimple() special cases. I think the following is good enough --- this is at a level below where we decide if the list is backgrounded, but I think the appropriate terminator always has to be the next tokens for this to happen. It does the expected in the cases above. pws diff --git a/Src/parse.c b/Src/parse.c index 2705252..6e0856b 100644 --- a/Src/parse.c +++ b/Src/parse.c @@ -808,8 +808,13 @@ par_sublist(int *cmplx) WC_SUBLIST_END), f, (e - 1 - p), c); cmdpop(); - } else + } else { + if (tok == AMPER || tok == AMPERBANG) { + c = 1; + *cmplx |= c; + } set_sublist_code(p, WC_SUBLIST_END, f, (e - 1 - p), c); + } return 1; } else { ecused--; ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-09-02 19:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-01 18:09 function definition with & operator Eric Cook 2017-09-01 20:46 ` Bart Schaefer 2017-09-01 21:23 ` Eric Cook 2017-09-02 19:23 ` Bart Schaefer 2017-09-02 19:37 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).