function definition with & operator

function definition with & operator

[Eric Cook]

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.

Re: function definition with & operator

[Bart Schaefer]

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.

Re: function definition with & operator

[Eric Cook]

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.

Re: function definition with & operator

[Bart Schaefer]

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.

Re: function definition with & operator

[Peter Stephenson]

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