[PATCH 2/3] ash: stopped jobs should only prevent exit from interactive shell

Roberto A. Foglietta roberto.foglietta at gmail.com
Tue Sep 14 18:01:23 UTC 2021


Il mar 14 set 2021, 19:52 Harald van Dijk <harald at gigawatt.nl> ha scritto:

> On 14/09/2021 17:06, Roberto A. Foglietta wrote:
> > Il giorno mar 14 set 2021 alle ore 18:01 Harald van Dijk
> > <harald at gigawatt.nl> ha scritto:
> >>
> >> On 14/09/2021 11:24, Denys Vlasenko wrote:
> >>> On Tue, Sep 14, 2021 at 10:04 AM Roberto A. Foglietta
> >>> <roberto.foglietta at gmail.com> wrote:
> >>>> Il giorno dom 12 set 2021 alle ore 18:55 Roberto A. Foglietta
> >>>> <roberto.foglietta at gmail.com> ha scritto:
> >>>>
> >>>>>    I am going to replace every raise_exception(EXEXIT) with
> exitshell()
> >>>>> and to remove the EXEXIT altogether.
> >>>
> >>> There is only one: in exitcmd(), the nadler of "exit" builtin.
> >>>
> >>>> 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?
> >>>
> >>> Could work. Can you make this change through dash?
> >>> I do not want to diverge here.
> >>
> >> If you change exitcmd() to no longer unwind before calling an EXIT
> >> handler, this will change the behaviour of EXIT handlers in that they
> >> will run in a different environment than before the change. Whether that
> >> is good or bad is arguable and something I do not want to get into, but
> >> it should be clear that this is not some NFC code cleanup, this will
> >> have an impact on how the shell behaves.
> >>
> >
> > Sorry Harald, I did not got this. There is "nothing" after EXIT: exit
> > terminates the shell execution. So, what kind of environment will be
> > changed between the two ways?
>
> When I wrote "EXIT handlers ... will run in a different environment", I
> meant that EXIT handlers will run in a different environment. That is
> something that happens during exitshell(), before the shell exits. There
> is nothing in there about any "after EXIT", I'm not sure where that came
> from and sure, that wouldn't make any sense. Since I do not see where
> this misunderstanding came from I am not sure how to clear it up.
>

I got what you are saying. The unwind means the code executed after setjmp
returns true and that's the enviroment.

It Is useless to unwind. Nothing significative is done by unwind which
means nothing that is useful for exiting. Unwind means restore variabiles
values and free some of them buy nothig that brings any value. It Is
opposite: the values that are needed for traps are those before the unwind.

To check this affermation, it is enough to verify all the code running
after a setjmp returns true. It happens in about 10 places.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20210914/b45be2db/attachment-0001.html>


More information about the busybox mailing list