empty job texts for suspended .zshrc jobs

empty job texts for suspended .zshrc jobs

[Stephane Chazelas]

Version: 5.3.1 and 5.1.1 on Debian, Ubuntu Linux amd64.

$ tail -n 3 .zshrc
sleep 10 | sleep 11 &
jobs
sleep 8 | sleep 9
$ zsh
[1] 10260 10261
[1]  + running    sleep 10 | sleep 11
^Z
zsh: suspended   |
$ printf '<%s> => <%s>\n' "${(@kv)jobtexts}" | cat -vte
<1> => <sleep 10 | sleep 11>$
<2> => < | >$
$ printf '<%s> => <%s>\n' "${(@kv)jobstates}"
<1> => <running:-:10260=running:10261=running>
<2> => <suspended:+:10262=suspended:10263=suspended>

See how the second job (the last line in the zshrc), suspended
with ^Z, has an empty job text for both components of the pipe
line above.

That does not happen for jobs started in background (even if
they're suspended later on).

-- 
Stephane

Re: empty job texts for suspended .zshrc jobs

[Bart Schaefer]

On Mar 27, 11:20am, Stephane Chazelas wrote:
}
} zsh: suspended   |

Hm, this is because what you've actually suspended is the "source"
command; the pipeline is the foreground job of the script file that
"source" is reading.  It's just that "source" doesn't get a slot
in the job table because semantically it's masquerading as the top
level shell.

I suspect this is tangentially related to the gymnastics that zsh
performs when you suspend a loop construct and an implicit fork has
to be performed to add a new job table entry.  It's just incomplete
for the case of "source".

The missing jobtext in this example dates back at least to 4.2.0.
In zsh-2.4 the job state is garbage and the shell crashes when the
sleeps ends.  The last version I can try where it appears to work as
expected is zsh-3.0.5.

Re: empty job texts for suspended .zshrc jobs

[Peter Stephenson]

On Thu, 30 Mar 2017 14:36:36 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Mar 27, 11:20am, Stephane Chazelas wrote:
> }
> } zsh: suspended   |
> 
> Hm, this is because what you've actually suspended is the "source"
> command; the pipeline is the foreground job of the script file that
> "source" is reading.  It's just that "source" doesn't get a slot
> in the job table because semantically it's masquerading as the top
> level shell.

Urm...

Presumably the assumption here was a sourced file wouldn't need the job
text, which presumably is wrong so this fix is reasonable...?

pws

diff --git a/Src/exec.c b/Src/exec.c
index 137130e..f021a08 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -1859,7 +1859,7 @@ execpline2(Estate state, wordcode pcode,
 	lineno = WC_PIPE_LINENO(pcode) - 1;
 
     if (pline_level == 1) {
-	if ((how & Z_ASYNC) || (!sfcontext && !sourcelevel))
+	if ((how & Z_ASYNC) || !sfcontext)
 	    strcpy(list_pipe_text,
 		   getjobtext(state->prog,
 			      state->pc + (WC_PIPE_TYPE(pcode) == WC_PIPE_END ?
@@ -3090,7 +3090,7 @@ execcmd_exec(Estate state, Execcmd_params eparams,
 
     /* Get the text associated with this command. */
     if ((how & Z_ASYNC) ||
-	(!sfcontext && !sourcelevel && (jobbing || (how & Z_TIMED))))
+	(!sfcontext && (jobbing || (how & Z_TIMED))))
 	text = getjobtext(state->prog, eparams->beg);
     else
 	text = NULL;

Re: empty job texts for suspended .zshrc jobs

[Bart Schaefer]

On Apr 4, 10:30am, Peter Stephenson wrote:
}
} Presumably the assumption here was a sourced file wouldn't need the job
} text, which presumably is wrong so this fix is reasonable...?

With reference to your comment in the commit log --

	We'll need to see if this makes start up inefficient.

-- this did not significantly change startup time for my .z* files
(1600 lines / 176kb).

Anybody have a really large startup config they can test?