On Wed, Jul 17, 2019 at 04:49:28PM +0900, John Crawley wrote: > The behaviour of exec seems to have changed from Stretch to Buster - > whether using bash or "sh" (dash here). > > Simple test, in default bash shell on terminal: > > sh > # now with dash > exec x-terminal-emulator > # close new window > > In Stretch, the launching dash shell is held until the new one is > closed, then exits and returns to bash. > In Buster, the launching dash shell dies *immediately* and the bash > prompt returns, even while the new window is still open. > > If the test is done without switching to sh, the change between > stretch and buster is similar, but the launching terminal is > destroyed, the difference being in whether that's immediate or after > closing the new one. > > Was this a bug in Stretch? I haven't been able to find any references to it. > > As it happens, I was using that behaviour in a script, but I'll hold > that question for a bit...
Perhaps it's your interpretation of what you see what you've to question. What 'exec' does is it substitutes the program the current process is running for another one. So once you run 'exec x-terminal-emulator', your sh "is no more", in the sense that the process which was executing /bin/sh is now executing "whatever x-terminal-emulator" is. Same PID, though [1]. If what you observe changes (I'd describe what I understood from your description as "before, the command line was blocked as long as "x-terminal-emulator" ran, nowadays the command prompt returns right away and the "x-terminal-emulator" keeps running "in the background"), that most probably is due to a change in behaviour of "x-terminal-emulator". Note that "x-terminal-emulator" isn't really a single program, but an "alternatives" thing, pointing to whatever terminal emulator you've declared as your favourite. Try update-alternatives --display x-terminal-emulator to get an idea of what's going on. Cheers -- tomás
signature.asc
Description: Digital signature
