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

Harald van Dijk harald at gigawatt.nl
Tue Sep 14 17:52:24 UTC 2021


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.

Cheers,
Harald van Dijk


More information about the busybox mailing list