[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ‘command … &’ creates subshell

From: Robert Elz
Subject: Re: ‘command … &’ creates subshell
Date: Thu, 02 Jul 2020 00:46:33 +0700

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

jinx$ echo $$
jinx$ exec :
bash: exec: :: not found
jinx$ echo $$
jinx$ 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 $$
jinx$ exec :
bash: exec: :: not found
jinx$ echo $$
jinx$ 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]