Question

Today I observed a strange behavior I am hoping I can get some direction on.

Here’s what I’m doing…

With at least one process already running in background, I interrupt (Ctrl + Z) the foreground process and then place it in the background with bg.

Here are the results in zsh:

$ some-long-running-command
^Z
zsh: suspended  some-long-running-command
$ bg
[2]  - continued  some-long-running-command
$ jobs
[1]  + running    other-command-previously-run
[2]  - running    some-long-running-command
$

And here’s what it looks like in bash:

$ other-command-previously-run &
[1] 12345
$ some-long-running-command
^Z
[2]+  Stopped                 some-long-running-command
$ bg
[2]+ some-long-running-command &
$ jobs
[1]-  Running                 other-command-previously-run &
[2]+  Running                 some-long-running-command &
$ 

So why does bash keep the process placed in background with bg as the “current” process (indicated by “+” which will be resumed if fg is run), while zsh sets the “other” process as current? I can’t find any documentation suggesting the behavior would be different… Interestingly if you do several fg + ^Z + bg in zsh, the “current” process selection will “flip flop”.

Has anyone else seen this?

Answer 1

I can reproduce this behaviour in bash and zsh.

My TL;DR answer: the behaviour you see in bash is documented. The behaviour you see in zsh is not (that I’ve found), and I have a theory, which might be wrong.

---

Bash:

The Bash Manual, section 7, "Job Control Basics" describes the behaviour of the builtin bg:

The symbols ‘%%’ and ‘%+’ refer to the shell’s notion of the current job, which is the last job stopped while it was in the foreground or started in the background.

Thus, from the point of view of bash, the current job is the last job either stopped in foreground or started in the background. This explains the behaviour noticed in the question:

So why does bash keep the process placed in background with bg as the "current" process

---

ZSH:
I can’t explain this for zsh. The man zshmisc page, under section JOBS, explains what zsh means by the + and - in jobs:

%% Current job.
%+ Equivalent to ‘%%’.
%- Previous job.

It does not, however, explain what effect bg, fg and ^Z have on the processes in terms of relegating them to previous or current.

My theory, which I’ve yet to verify by pestering the nice folks over in irc.freenode.net#zsh, is that zsh uses a "current-process stack"; bg pushes the current process to the end of the queue. This can be seen when playing with three processes thus:

simont@charmander ~/repositories/SOTesting/bg
  $ one.sh&                                                                                 [1:52:41]
[1] 98369

simont@charmander ~/repositories/SOTesting/bg
  $ two.sh&                                                                                 [1:52:49]
[2] 99293

simont@charmander ~/repositories/SOTesting/bg
  $ three.sh                                                                                [1:52:51]
^Z
[3]  + 973 suspended  three.sh

simont@charmander ~/repositories/SOTesting/bg
  $ jobs                                                                                    [1:52:55]
[1]    running    one.sh
[2]  - running    two.sh
[3]  + suspended  three.sh

simont@charmander ~/repositories/SOTesting/bg
  $ bg                                                                                      [1:52:57]
[3]  - 973 continued  three.sh

simont@charmander ~/repositories/SOTesting/bg
  $ jobs                                                                                    [1:52:59]
[1]    running    one.sh
[2]  + running    two.sh
[3]  - running    three.sh

As we can see here, one and two are pushed down on the theoretical stack. three, being executed last(?) is the current process, denoted by the + from the jobs output.
After three is suspended, it is still the current process, but after bg, it is pushed to the previous process and two, being the "top" process in the "stack" becomes the new current process.

This, however, is conjecture; like I said, I haven’t got documented proof of this, and, honestly, the man zsh* pages are slightly complicated; I may have missed something.