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

Groups > gnu.bash.bug > #16515

Re: ‘command … &’ creates subshell

Show key headers only | View raw

    Date:        Wed, 01 Jul 2020 18:29:46 +0300
    From:        Dmitry Alexandrov <dag@gnui.org>
    Message-ID:  <pn9ffe39.dag@gnui.org>

  | Well, I am not sure whether it's guaranteed, but the "exec"
  | as above does execute an external command in GNU Bash.

Yes, I know, but the way exec works in bash is broken (well, non-standard,
not POSIX compliant).

POSIX says:

	If command is specified, exec shall not return to the shell;

but in bash...

 bash
jinx$ echo $$
23361
jinx$ exec :
bash: exec: :: not found
jinx$ echo $$
23361
jinx$ exit
exit

"command was specified" yet exec returned to the shell.   That should
never happen (that it was unable to find the ':' builtin command to
execute is another problem - but that one is shared by several shells).

Turning on posix mode makes no difference:

bash -o posix
jinx$ echo $$
18742
jinx$ exec :
bash: exec: :: not found
jinx$ echo $$
18742
jinx$ exit
exit

These use 5.0.17(1)-release bash.

What is required of exec (with a "command" arg) is that the current
shell is replaced by the command, and when that exits, the process
that used to be the shell exits.

When not interactive bash seems to do this properly, but not when 
interactive.   The spec makes no variation for that case,

There's nothing in the spec that limits what kind of command can be
exec'd (except to parse, it has to be a simple command, nothing else
fits into the grammar) though many shells treat the exec builtin as
simply a shorthand for a call to one of the exec*() system calls,
and consequently only work properly if there's a command in the filesystem
to run.

kre

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: ‘command … &’ creates subshell Robert Elz <kre@munnari.OZ.AU> - 2020-07-02 00:46 +0700

csiph-web