Sujet : Re: When/why does the shell (bash) (sometimes) not re-cycle job IDs?
De : ldo (at) *nospam* nz.invalid (Lawrence D'Oliveiro)
Groupes : comp.unix.shellDate : 12. May 2024, 04:43:01
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v1pabl$2g5ao$6@dont-email.me>
References : 1 2 3 4
User-Agent : Pan/0.155 (Kherson; fc5a80b8)
On Sun, 12 May 2024 03:38:03 +0200, Janis Papanagnou wrote:
On 12.05.2024 02:14, Lawrence D'Oliveiro wrote:
>
I’ve often wondered why shells don’t use poll/select-based event
loops. Then they can notify you of job termination immediately, instead
of waiting for you to press return.
It may be considered undesired in an interactive shell to unnecessarily
spoil the output of other running processes.
Fair, but it could still do the report while waiting for you to input your
next command.
Bash uses GNU Readline, so it has the partial line you’ve input already,
and can redisplay it after the message, to allow you to continue typing
from where you left off.
DEC’s old VMS OS had a special terminal read operation called “read-with-
prompt”. If your partial input got messed up, it could be redisplayed,
along with the prompt string that was included in the read operation.
If job output would be
written asynchronously then you could also easily miss the output of
the job control system.
That happens anyway. The only thing background processes are blocked from
doing is input from the controlling terminal.