Re: curjob in sub-shells?

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

 On 20/05/2026 07:06 BST dana <dana@xxxxxxx> wrote:
> i was writing some job tests and i noticed this:
> 
>   % zsh -fc '( sleep 3 &; disown; jobs ); :'
>   zsh:disown:1: no current job
>   [2]    running    sleep 3
> 
> this is because disown without an argument operates on curjob, and
> spawnjob() doesn't update curjob in sub-shells. (for the same reason,
> you can't use `kill %%` etc. but `disown %2` or `kill %2` would work)
> 
> i tried changing that and it seemed mostly ok, but it caused a test in
> W03 to fail. it has this comment:
> 
>   # $jobstates refers to a job started in the main shell unless
>   # one has been started in the subshell.  In the latter case,
>   # the subshell has no job control so the job is not marked as current.
> 
> i don't understand. what would be the negative consequences of marking
> the job as current in a sub-shell?

From what I remember about fiddling with this ages aog, it's governed by
the principle of least surprise: I think the point was that if you're in
a subshell and reporting the current job the user probably wants to see
what's in the parent shell.  (Ages ago the shell's notion of current job
got wiped out in the subshell, if I remember correctly, which was
inconvenient if you ad a pipeline reporting job status, so we had to
work out how to put it back in.)

But in the case you show it seems pretty clear the intention is to
create a new current job regardless of what's in the parent shell, so I
think what you suggest is sane.

pws