Robert Elz <k...@munnari.oz.au> wrote, on 08 Aug 2019:
>
> | Who says those operations aren't supposed to change the results?
>
> Who says that they are, or are permitted to?
Paragraph 2 of bg description:
Using bg to place a job into the background shall cause its
process ID to become "known in the current shell execution
environment", as if it had been started as an asynchronous list
A natural consequence of moving the job into this new child process is
that it can no longer affect the current shell environment.
If you then use fg to move it back to the foreground, all this means is
that the shell changes the foreground process group of the terminal,
waits for the child process, and removes its process ID from the list
of those "known in the current shell execution environment". If there
was any intention for the shell to somehow magically have the newly
foregrounded job start affecting the current shell environment again,
this would need to have been stated very clearly.
A bigger issue with bg, in shells that treat each pipeline in a
foreground AND-OR list as a separate job, is that if one of those jobs
is stopped and then placed in the background, what happens to the
remainder of the AND-OR list? For example:
sleep 10 && echo foo
This tells the shell to execute "echo foo" after "sleep 10" has
successfully completed. If "sleep 10" is a job and is stopped and
placed into the background, the shell is still required to execute
"echo foo" after successful completion of "sleep 10". This is not
really any different from the shell treating the whole AND-OR list
as one job, except that only "sleep 10" is listed by "jobs" - the
fact that "echo foo" will be executed after it (if it succeeds) is
misleadingly hidden from the user.
Note that I'm not talking about current practice here, but what the
standard requires (and what users would naturally expect). If bash,
and the other shells that behave like it, fix the bug whereby stopping
the "sleep 10" causes the remainder of the AND-OR list to be processed
at that point (while retaining the one-job-per-pipeline design), they
will then have the problem of what to do with the remainder of the
AND-OR list if bg is used to place the "sleep 10" in the background.
It will probably be simpler and easier to fix both problems in one
go by changing to treat the whole AND-OR list as a job. It would
also improve consistency with background jobs where (AFAIK) all
shells treat the whole AND-OR list as one job.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
