(bash) How (really!) does the "current job" get determined?

Liste des GroupesRevenir à cu shell 
Sujet : (bash) How (really!) does the "current job" get determined?
De : gazelle (at) *nospam* shell.xmission.com (Kenny McCormack)
Groupes : comp.unix.shell
Date : 04. Oct 2024, 00:08:52
Autres entêtes
Organisation : The official candy of the new Millennium
Message-ID : <vdn864$2p69n$1@news.xmission.com>
User-Agent : trn 4.0-test77 (Sep 1, 2010)
Note: This is a "How do things really work - in the real world?", rather
than a "What does the manual say about how things work?" sort of thread.

The manual says the answer is "The job most recently started in the
background or most recently stopped."  This is not always the case.

Observe (this is bash version 5.2.15) (and "j" is aliased to "jobs -l"):

 $ j
[1]+ 20914 Stopped (signal)        sudo bash
 $ sleep 100 & j
[2] 12914
[1]+ 20914 Stopped (signal)        sudo bash
[2]- 12914 Running                 sleep 100 &
 $ fg
sudo bash
 # suspend

[1]+  Stopped                 sudo bash
Status: 147
 $ %2

Note that I start with one background job (the "sudo").  I launch a second
one, but, according to the "jobs" listing, job #1 is still the "current"
job (denoted with the "+").  Further, when I do "fg", I get back to job #1.

Two comments:
    1) You generally would like it to work the way it should work, since
    you generally want to manipulate the most recent job (the sleep in the
    above example, not the sudo).  Getting the job id from the pid ($!) is
    possible and is my chosen workaround, but it is not trivial.
    2) I could not find mention of what exactly the output of the jobs
    command means; i.e., what the + and - mean - in "man bash".

Also note: I googled this question and found something on unix.stackexchange.
There is a post there by our own "Stephan Chaz...", that basically just
quotes the manual.  As I said, this info is incorrect (as seen above).

--
That's the Trump playbook. Every action by Trump or his supporters can
be categorized as one (or more) of:

    outrageous, incompetent, or mentally ill.

Date Sujet#  Auteur
4 Oct 24 * (bash) How (really!) does the "current job" get determined?33Kenny McCormack
4 Oct 24 `* Re: (bash) How (really!) does the "current job" get determined?32Kaz Kylheku
4 Oct 24  `* Re: (bash) How (really!) does the "current job" get determined?31Kenny McCormack
4 Oct 24   `* Re: (bash) How (really!) does the "current job" get determined?30Kaz Kylheku
4 Oct 24    +* Expand your mind (Was: (bash) How (really!) does the "current job" get determined?)2Kenny McCormack
5 Oct 24    i`- Re: Expand your mind (Was: (bash) How (really!) does the "current job" get determined?)1Kaz Kylheku
4 Oct 24    `* Re: (bash) How (really!) does the "current job" get determined?27Christian Weisgerber
4 Oct 24     `* Re: (bash) How (really!) does the "current job" get determined?26Janis Papanagnou
5 Oct 24      `* Re: (bash) How (really!) does the "current job" get determined?25Christian Weisgerber
5 Oct 24       +* Re: (bash) How (really!) does the "current job" get determined?2Kaz Kylheku
10 Oct 24       i`- Re: (bash) How (really!) does the "current job" get determined?1Kaz Kylheku
5 Oct 24       +- Re: (bash) How (really!) does the "current job" get determined?1Keith Thompson
5 Oct 24       +* Re: (bash) How (really!) does the "current job" get determined?13Kenny McCormack
5 Oct 24       i+* Re: (bash) How (really!) does the "current job" get determined?11Christian Weisgerber
5 Oct 24       ii`* pid ranges (Was: (bash) How (really!) does the "current job" get determined?)10Kenny McCormack
7 Oct 24       ii `* Re: pid ranges (Was: (bash) How (really!) does the "current job" get determined?)9Janis Papanagnou
7 Oct 24       ii  +- Re: pid ranges (Was: (bash) How (really!) does the "current job" get determined?)1marrgol
7 Oct 24       ii  `* Re: pid ranges (Was: (bash) How (really!) does the "current job" get determined?)7Kenny McCormack
7 Oct 24       ii   `* Re: pid ranges (Was: (bash) How (really!) does the "current job" get determined?)6Janis Papanagnou
7 Oct 24       ii    `* Re: pid ranges5Richard Kettlewell
7 Oct 24       ii     `* [OT] PIDs for Linux threads (was Re: pid ranges)4Janis Papanagnou
7 Oct 24       ii      +- Re: [OT] PIDs for Linux threads (was Re: pid ranges)1Kenny McCormack
7 Oct 24       ii      +- Re: [OT] PIDs for Linux threads (was Re: pid ranges)1Lew Pitcher
7 Oct 24       ii      `- Re: PIDs for Linux threads (was Re: pid ranges)1Lawrence D'Oliveiro
6 Oct 24       i`- Re: (bash) How (really!) does the "current job" get determined?1Kaz Kylheku
7 Oct 24       +* Re: (bash) How (really!) does the "current job" get determined?5Janis Papanagnou
7 Oct 24       i`* Re: (bash) How (really!) does the "current job" get determined?4Kenny McCormack
7 Oct 24       i `* Re: (bash) How (really!) does the "current job" get determined?3Janis Papanagnou
7 Oct 24       i  `* bash/ksh differences (fg and other job control commands) (Was: (bash) How (really!) does the "current job" get determined?)2Kenny McCormack
7 Oct 24       i   `- Re: bash/ksh differences (fg and other job control commands) (Was: (bash) How (really!) does the "current job" get determined?)1Janis Papanagnou
7 Oct 24       +- Re: (bash) How (really!) does the "current job" get determined?1Helmut Waitzmann
8 Oct 24       +- Re: (bash) How (really!) does the "current job" get determined?1Richard Harnden
8 Oct 24       `- Re: (bash) How (really!) does the "current job" get determined?1Kaz Kylheku

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal