Re: job control weirdness

:On Sat, April 8, 2006 9:09 pm, Sascha Wildner wrote:
:
:> Note that the first fg doesn't work but the second does. My feeling is
:> that this is not expected behavior.
:>
:> It occurs in HEAD here but I think it is in 1.4.x as well.
:
:I got the same results on 1.4.2.
:
:justin@dev# yes > /dev/null
:^Z
:Suspended
:justin@dev# bg
:[1] yes > /dev/null &
:justin@dev# fg
:fg: No current job.
:justin@dev# ls
:(dir listing)
:justin@dev# fg
:yes > /dev/null
:^C
:justin@dev#
Well, the shell isn't listing the job with a '+', so the 'fg' won't
select it. After you do the 'ls', if you do another jobs -l, you
will see that the background process is now marked with a '+', so
the next fg you do will select it. This is probably due to the
fact that the 'ls' was the current job and the shell selected another
'current' job when the ls finished.
This kinda sounds like an issue in the shell code itself. I'd hunt
through the code to figure out why the backgrounded job is not
initially marked with a '+'. In fact, it might not even be considered
a bug. I seem to recall that when you explicitly 'bg' a job, the
shell skips over that job when selecting its idea of the next top for
the jobs list.
Here's a similar interesting effect:
apollo:/home/dillon> ( sleep 5 ; cat )
^Z
Suspended
apollo:/home/dillon> bg
[1] ( sleep 5; cat ) &
apollo:/home/dillon> j
[1] 24023 Running ( sleep 5; cat )
apollo:/home/dillon> j
[1] 24023 Running ( sleep 5; cat )
apollo:/home/dillon> j
[1] 24023 Running ( sleep 5; cat )
apollo:/home/dillon> j
[1] 24023 Running ( sleep 5; cat )
apollo:/home/dillon> j
[1] + 24023 Suspended (tty input) ( sleep 5; cat )
apollo:/home/dillon>
Notice that when the job is backgrounded, it is not selected as
the current job, but when the job suspends due to needing tty input,
the shell then selects it as the current job.
I think that may be intentional.
-Matt
Matthew Dillon
<dillon@xxxxxxxxxxxxx>