| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 40 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 22:06:08 |
| Calls: | 291 |
| Files: | 910 |
| Messages: | 76,668 |
| Posted today: | 1 |
Job control does not require an interactive shell or a terminal
session. It can be used in scripting. That's the facts.
I'm curious myself. That said, here's something I stumbled across
recently:
background job &
...
kill %1 # clean up
What happens if the background job has already terminated on its
own accord before we reach the kill(1)? Not much, because with job
control, the shell knows that no such job exists. If you do this
with "kill $!", you signal that PID, which no longer refers to the
intended process and may in fact have been reused for a different
process.
The problem of re-used pids is something people frequently worry about, but which is (for all practical purposes) never seen in real life. For one thing, even in the old days of 15 bit pids, it is still basically
impossible for it to cycle all the way through in any sort of reasonable
time frame. Nowadays, we have 22 bit pids, so it is even less likely (*).
1) As far as I know, all "normal" Unixes use the simple cycle method of
allocating pids - i.e., just keep going up by 1 until you reach the max,
then start over again at 1 (or 2). But I think at one point, it was
thought that having "predictable" pids was somehow bad for "security",
so they had a random assignment method.
In article <slrnvg0s5f.1qk1.naddy@lorvorc.mips.inka.de>,
Christian Weisgerber <naddy@mips.inka.de> wrote:
...
Job control does not require an interactive shell or a terminal
session. It can be used in scripting. That's the facts.
True. But as they say, there are none so blind as those that will not see.
On 2024-10-04, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
What? Scripting should not go anywhere near POSIX job control, which is >>>> an interactive feature that requires a terminal session.
Well, there _is_ set -m.
And how will that devaluate what Kaz has said? Please elaborate.
Job control does not require an interactive shell or a terminal
session. It can be used in scripting. That's the facts.
or if you know of any useful and sensible application contexts
for non-interactive usages I'd certainly be curious to know.[*]
I'm curious myself. That said, here's something I stumbled across
recently:
background job &
...
kill %1 # clean up
What happens if the background job has already terminated on its
own accord before we reach the kill(1)? Not much, because with job
control, the shell knows that no such job exists. If you do this
with "kill $!", you signal that PID, which no longer refers to the
intended process and may in fact have been reused for a different
process.
In contrast to '$!' that you get and work
with there's no (no easy?) way to obtain the job number that the
shell assigns!
And (for concerning your question below) you have
alway 'wait' available, for both, PIDs or job numbers (at least
in Kornshell; don't know about Bash or what POSIX says about it).
What annoys me is that (in bash), most, but not all, of the job control related commands take either a pid or a job number. To be clear, what
annoys me is that they don't *all* do. In particular, "fg" only takes a
job number. "disown" takes either, which is a very good thing. Wish they all did.
That said, here's something I stumbled across recently:
background job &
...
kill %1 # clean up
What happens if the background job has already terminated on its
own accord before we reach the kill(1)? Not much, because with job
control, the shell knows that no such job exists. If you do this
with "kill $!", you signal that PID, which no longer refers to the
intended process and may in fact have been reused for a different
process.
I'm curious myself. That said, here's something I stumbled across
recently:
background job &
...
kill %1 # clean up
What happens if the background job has already terminated on its
own accord before we reach the kill(1)? Not much, because with job
control, the shell knows that no such job exists. If you do this
with "kill $!", you signal that PID, which no longer refers to the
intended process and may in fact have been reused for a different
process.
What happens if the background job has already terminated on its
own accord before we reach the kill(1)? Not much, because with job
control, the shell knows that no such job exists.
If you do this
with "kill $!", you signal that PID, which no longer refers to the
intended process and may in fact have been reused for a different
process.
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
On 2024-10-04, Christian Weisgerber <naddy@mips.inka.de> wrote:
On 2024-10-04, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
What? Scripting should not go anywhere near POSIX job control, which is >>>>> an interactive feature that requires a terminal session.
Well, there _is_ set -m.
And how will that devaluate what Kaz has said? Please elaborate.
Job control does not require an interactive shell or a terminal
session.
It can be used in scripting. That's the facts.
An example of what you mean would help.
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.
It must be that Bash has no test cases covering the documented
requirements in this area adequate enough to catch what you have found.
Is this automatically tested at all?
Testing interactive job control features pretty much requires Bash to be >behind a pseudo-tty; driven by expect or something like it.
(Or else at least a unit test is required where the function that
identifies the current job is tested in isolation, with the various >conditions mocked up: suspended job introduced while existing job is
stopped, etc.)
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.
You can't rely on the job you
just launched being 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.
What? Scripting should not go anywhere near POSIX job control, which is
an interactive feature that requires a terminal session.
On 2024-10-04, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
What? Scripting should not go anywhere near POSIX job control, which is
an interactive feature that requires a terminal session.
Well, there _is_ set -m.
What? Scripting should not go anywhere near POSIX job control, which is
an interactive feature that requires a terminal session.
Well, there _is_ set -m.
And how will that devaluate what Kaz has said? Please elaborate.
or if you know of any useful and sensible application contexts
for non-interactive usages I'd certainly be curious to know.[*]
On 2024-10-04, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
What? Scripting should not go anywhere near POSIX job control, which is >>>> an interactive feature that requires a terminal session.
Well, there _is_ set -m.
And how will that devaluate what Kaz has said? Please elaborate.
Job control does not require an interactive shell or a terminal
session.
It can be used in scripting. That's the facts.