Re: function definition with & operator

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Fri, 1 Sep 2017 14:09:55 -0400
Eric Cook <llua@xxxxxxx> 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--;