Project

General

Profile

Actions

Bug #140

closed

job control weirdness

Added by swildner almost 18 years ago. Updated over 17 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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

Actions #1

Updated by justin about 18 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#

Actions #2

Updated by dillon about 18 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
<>
Actions #3

Updated by corecode about 18 years ago

Do we agree that this is intentional?

Actions #4

Updated by swildner about 18 years ago

I don't. :)

Sascha

Actions #5

Updated by dillon about 18 years ago

:Simon 'corecode' Schubert <> added the comment:
:
:Do we agree that this is intentional?

Yes, I think it is.  
-Matt
Matthew Dillon
&lt;&gt;
Actions

Also available in: Atom PDF