Bug #140
closedjob control weirdness
0%
Description
Hi,
I've noticed the following strange behavior (at least in csh) for some
time now. Anyone know what the cause of this might be?
zoot# yes > /dev/null
^Z
Suspended
zoot# bg
[1] yes > /dev/null &
zoot# fg
fg: No current job.
zoot# ls
account/ caps/ db/ heimdal/ log/
preserve/ spool/
at/ crash/ empty/ lib/ mail/
run/ tmp@
backups/ cron/ games/ lock/ msgs/
rwho/ yp/
zoot# fg
yes > /dev/null
^C
zoot#
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.
Regards,
Sascha
Updated by justin almost 19 years ago
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#
Updated by dillon almost 19 years ago
: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@backplane.com>
Updated by dillon almost 19 years ago
:Simon 'corecode' Schubert <corecode@fs.ei.tum.de> added the comment:
:
:Do we agree that this is intentional?
Yes, I think it is.
-Matt
Matthew Dillon
<dillon@backplane.com>