Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #211444 > unrolled thread

dash/bash: exec behaviour change on Buster

Back to article view | Back to linux.debian.user

Contents

  dash/bash: exec behaviour change on Buster John Crawley <john@bunsenlabs.org> - 2019-07-17 09:50 +0200
    Re: dash/bash: exec behaviour change on Buster <tomas@tuxteam.de> - 2019-07-17 10:20 +0200
      Re: dash/bash: exec behaviour change on Buster "Thomas Schmitt" <scdbackup@gmx.net> - 2019-07-17 10:40 +0200
        Re: dash/bash: exec behaviour change on Buster John Crawley <john@bunsenlabs.org> - 2019-07-18 03:40 +0200
          Re: terminal window returns prompt (was: dash/bash: exec behaviour  change on Buster) John Crawley <john@bunsenlabs.org> - 2019-07-18 05:40 +0200
          Re: dash/bash: exec behaviour change on Buster Richard Hector <richard@walnut.gen.nz> - 2019-07-18 08:00 +0200
            Re: dash/bash: exec behaviour change on Buster John Crawley <john@bunsenlabs.org> - 2019-07-18 09:50 +0200

#211444 — dash/bash: exec behaviour change on Buster

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...

-- 
John

[toc] | [next] | [standalone]

#211446

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#211447

Hi,

John Crawley wrote:
> > In Buster, the launching dash shell dies *immediately* and the bash
> > prompt returns, even while the new window is still open.

tomas wrote:
> that most probably is due to a change
> in behaviour of "x-terminal-emulator".

My suspicion too. If the x-terminal-emulator puts itself into background,
then the starting terminal ends immediately.

test_script:

  #!/bin/sh
  xterm &

Executed by

  chmod u+x ./test_script
  exec ./test_script

kills the terminal.

(Combining "exec" and "&" in the interactive shell does not kill the
 shell and the terminal:
  exec xterm &
)


What happens if you run

  x-terminal-emulator

without "exec". Does the shell prompt come back immediately ?


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#211491

Hi tomas and Thomas, thanks for your input.
I think I have a basic idea of what exec does.
However, try running in a terminal:
echo $$
exec <someterminal>
#Then, in the new terminal:
echo $$

The two PIDs are different! (or were here)

On 2019-07-17 17:37, Thomas Schmitt wrote:
> John Crawley wrote:
>>> In Buster, the launching dash shell dies *immediately* and the bash
>>> prompt returns, even while the new window is still open.
> tomas wrote:
>> that most probably is due to a change
>> in behaviour of "x-terminal-emulator".
> My suspicion too. If the x-terminal-emulator puts itself into background,
> then the starting terminal ends immediately.

The Debian alternative system is just a series of symlinks.
/usr/bin/x-terminal-emulator points to 
/etc/alternatives/x-terminal-emulator which in turn points to (on my 
system) /usr/bin/urxvt.
It's hard to imagine a stretch>buster change in behaviour, really.

> What happens if you run
>    x-terminal-emulator
> without "exec". Does the shell prompt come back immediately ?

No. Not on Stretch. x-terminal-emulator, or a specific terminal call, in 
every case the prompt waits till the called window is closed.
---
But... on Buster it depends on exactly what terminal it's currently 
pointing to. I've tried a few that were on my test system and:

gnome-terminal or gnome-terminal.wrapper and lxterminal both return the 
prompt immediately. (*.wrapper scripts are for x-terminal-emulator 
compatibility, but don't seem to affect this issue.)

urxvt, xterm, mate-terminal{,.wrapper}, xfce4-terminal{,.wrapper} and 
terminator all hold the prompt till the window is closed.
---

On my test system, at the time, x-terminal-emulator pointed to 
lxterminal, so it looks as if "exec" has nothing to do with this.

I'll have to do a bit of googling about why lxterminal and 
gnome-terminal's behaviour has changed like this, though. Unless you 
folks have any ideas?

I'd like my scripts to work the same regardless of what terminal a user 
has set as x-terminal-emulator.

-- 
John

[toc] | [prev] | [next] | [standalone]

#211492 — Re: terminal window returns prompt (was: dash/bash: exec behaviour change on Buster)

On 2019-07-18 10:29, John Crawley wrote:
> Hi tomas and Thomas, thanks for your input.
> I think I have a basic idea of what exec does.
> However, try running in a terminal:
> echo $$
> exec <someterminal>
> #Then, in the new terminal:
> echo $$
> 
> The two PIDs are different! (or were here)
> 
> On 2019-07-17 17:37, Thomas Schmitt wrote:
>> John Crawley wrote:
>>>> In Buster, the launching dash shell dies *immediately* and the bash
>>>> prompt returns, even while the new window is still open.
>> tomas wrote:
>>> that most probably is due to a change
>>> in behaviour of "x-terminal-emulator".
>> My suspicion too. If the x-terminal-emulator puts itself into background,
>> then the starting terminal ends immediately.
> 
> The Debian alternative system is just a series of symlinks.
> /usr/bin/x-terminal-emulator points to 
> /etc/alternatives/x-terminal-emulator which in turn points to (on my 
> system) /usr/bin/urxvt.
> It's hard to imagine a stretch>buster change in behaviour, really.
> 
>> What happens if you run
>>    x-terminal-emulator
>> without "exec". Does the shell prompt come back immediately ?
> 
> No. Not on Stretch. x-terminal-emulator, or a specific terminal call, in 
> every case the prompt waits till the called window is closed.
> ---
> But... on Buster it depends on exactly what terminal it's currently 
> pointing to. I've tried a few that were on my test system and:
> 
> gnome-terminal or gnome-terminal.wrapper and lxterminal both return the 
> prompt immediately. (*.wrapper scripts are for x-terminal-emulator 
> compatibility, but don't seem to affect this issue.)
> 
> urxvt, xterm, mate-terminal{,.wrapper}, xfce4-terminal{,.wrapper} and 
> terminator all hold the prompt till the window is closed.
> ---
> 
> On my test system, at the time, x-terminal-emulator pointed to 
> lxterminal, so it looks as if "exec" has nothing to do with this.
> 
> I'll have to do a bit of googling about why lxterminal and 
> gnome-terminal's behaviour has changed like this, though. Unless you 
> folks have any ideas?
> 
> I'd like my scripts to work the same regardless of what terminal a user 
> has set as x-terminal-emulator.
> 

It seems gnome-terminal has a complicated server-client setup, but the 
immediate prompt return can be avoided with 'gnome-terminal --wait':
https://bugzilla.gnome.org/show_bug.cgi?id=707899

Lxterminal (which I was more interested in) says "all instances of the 
terminal are sharing a single process" which explains that, but it can 
be bypassed with '--no-remote'.

So a check if x-terminal-emulator points to lxterminal and if so adding 
'--no-remote' should cover my needs. Sorry for the noise.

-- 
John

[toc] | [prev] | [next] | [standalone]

#211495

[Multipart message — attachments visible in raw view] — view raw

On 18/07/19 1:29 PM, John Crawley wrote:
> Hi tomas and Thomas, thanks for your input.
> I think I have a basic idea of what exec does.
> However, try running in a terminal:
> echo $$
> exec <someterminal>
> #Then, in the new terminal:
> echo $$
> 
> The two PIDs are different! (or were here)

Yes. You exec'd a terminal, which then started a shell. You'll probably
find (I did) that the first pid you got is now the pid of the terminal:

richard@zircon:~$ echo $$
18626
richard@zircon:~$ exec xterm

[new terminal]
richard@zircon:~$ echo $$
19317

[trimmed output of ps f]
  PID TTY      STAT   TIME COMMAND
18626 pts/7    Ss+    0:00 xterm
19317 pts/10   Ss     0:00  \_ bash
19449 pts/10   R+     0:00      \_ ps f

Richard

[toc] | [prev] | [next] | [standalone]

#211502

On 2019-07-18 14:53, Richard Hector wrote:
> On 18/07/19 1:29 PM, John Crawley wrote:
>> However, try running in a terminal:
>> echo $$
>> exec <someterminal>
>> #Then, in the new terminal:
>> echo $$
>> The two PIDs are different! (or were here)
> 
> Yes. You exec'd a terminal, which then started a shell. You'll probably
> find (I did) that the first pid you got is now the pid of the terminal:

Ah, that makes sense. Thanks.
-- 
John

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web