Il giorno dom 12 set 2021 alle ore 13:37 Roberto A. Foglietta <[email protected]> ha scritto: > > Il giorno dom 12 set 2021 alle ore 13:31 Harald van Dijk > <[email protected]> ha scritto: > > > > On 12/09/2021 11:21, Ron Yorston wrote: > > > When the user tries to exit an interactive shell with stopped jobs > > > present the shell issues a warning and only exits if the user > > > insists by trying to exit again. > > > > > > This shouldn't apply to non-interactive shells. > > > > Agreed, but even in interactive shells, the implementation is not what > > it should be. Other shells (bash, ksh, yash, though not zsh) still use > > the exit status that exit would have resulted in to update $?, ash does not. > > > > That is, ash results in: > > > > ~ $ cat & > > ~ $ > > [1]+ Stopped (tty input) cat > > ~ $ exit 1 > > You have stopped jobs. > > ~ $ echo $? > > 0 > > > > In bash, ksh and yash the last command prints 1. > > > > Additionally, the check for stopped jobs happens before the job status > > is updated. I pressed Enter twice after 'cat &' to work around that. If > > I don't, I get: > > > > ~ $ cat & > > ~ $ exit 1 > > > > That is, even though by the time 'exit 1' is run the 'cat' command has > > stopped, the shell does not detect this. bash, ksh, yash do pick up on > > it and prevent the shell from exiting. (zsh is special and notifies that > > cat was suspended as it happens.) > > I suggest this change: >
Sorry for my mistake, the working patch is in attachment. I am going to replace every raise_exception(EXEXIT) with exitshell() and to remove the EXEXIT altogether. It seems to me that EXEXIT does not add any value but complicates things. What's your opinion on that? Do you see any possible regression? Best regards, -- Roberto A. Foglietta +39.349.33.30.697
exit-status-interactive-stopped-job.patch
Description: Binary data
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
