From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@zsh.org
Subject: Re: function definition with & operator
Date: Sat, 2 Sep 2017 20:37:20 +0100 [thread overview]
Message-ID: <20170902203720.459f8e0f@ntlworld.com> (raw)
In-Reply-To: <edfcc306-4f5e-63dd-00e0-2481e71ec5cc@gmx.com>
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--;
prev parent reply other threads:[~2017-09-02 19:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-01 18:09 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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170902203720.459f8e0f@ntlworld.com \
--to=p.w.stephenson@ntlworld.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).