Re: job control weirdness

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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>