Sujet : Re: (bash) How (really!) does the "current job" get determined?
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.unix.shellDate : 04. Oct 2024, 15:29:39
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20241004070133.515@kylheku.com>
References : 1 2 3
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2024-10-04, Kenny McCormack <
gazelle@shell.xmission.com> wrote:
In article <20241003170607.397@kylheku.com>,
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-10-03, Kenny McCormack <gazelle@shell.xmission.com> wrote:
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"):
>
It looks buggered.
>
Indeed it does. What this means from a scripting programmer's
point-of-view is that you can't count on it.
What? Scripting should not go anywhere near POSIX job control, which is
an interactive feature that requires a terminal session.
Unless you mean scripting that is peripheral to an interactive session,
for automating some interactive job control use cases? Like making
a more friendly job control system, or whatever?
If you'd like to build some kind of layer over job control, it looks as
if indeed you cannot rely on job control's implicit selection of the
most recent process. If you want your job control layer to have that,
you need your own global variable for it, and always pass down a %n
argument to the job control cruft below you.
Even if the current job variable worked reliably as documented, it would
be unreliable to you because any background can become the current job
at any time, asynchronously to you, due to being suddenly stopped on a
signal.
You can't rely on the job you
just launched being the "current job".
This is what I'm saying: even if it works as documented. There is a race
condition. A fraction of a second after you launch the job, some
existing, executing background job tries to do TTY input and is stopped.
Oops! It is now the "current job".
Note also that the underlying problem here is that while most of the "job
related" commands that take a "job spec" will take either something like %1
or an actual pid, but the "fg" command only takes %n. So, if you want to
fg the most recent job, you need to obtain the job id (via the command line
above), before passing it to "fg". Note that "fg" with no arg at all would
fg the wrong job.
Yes; so if you're writing your own cruft on top of job control, it's
probably a good idea to never call anything below without a %n argument.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca