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


Groups > gnu.bash.bug > #16523

Re: ‘command … &’ creates subshell

Path csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From Robert Elz <kre@munnari.OZ.AU>
Newsgroups gnu.bash.bug
Subject Re: ‘command … &’ creates subshell
Date Thu, 02 Jul 2020 04:36:33 +0700
Lines 54
Approved bug-bash@gnu.org
Message-ID <mailman.802.1593639430.2574.bug-bash@gnu.org> (permalink)
References <871rlvcdzc.fsf@igel.home> <pn9ffe39.dag@gnui.org> <tuysgrgt.dag@gnui.org> <pn9hipci.dag@gnui.org> <ac4a98bd-32f4-5c55-3b8f-1306e9758f54@case.edu> <7dvoi92p.dag@gnui.org> <09ea84b2-4fb1-6b05-7c0b-fe6b2ab00c6f@archlinux.org> <2643.1593599092@jinx.noi.kre.to> <14637.1593625593@jinx.noi.kre.to> <7633.1593639393@jinx.noi.kre.to>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
X-Trace usenet.stanford.edu 1593639430 20361 209.51.188.17 (1 Jul 2020 21:37:10 GMT)
X-Complaints-To action@cs.stanford.edu
Cc Dmitry Alexandrov <dag@gnui.org>, bug-bash@gnu.org
To Andreas Schwab <schwab@linux-m68k.org>
Envelope-to bug-bash@gnu.org
In-Reply-To <871rlvcdzc.fsf@igel.home>
Received-SPF permerror client-ip=2001:3c8:9009:181::2; envelope-from=kre@munnari.OZ.AU; helo=munnari.OZ.AU
X-detected-operating-system by eggs.gnu.org: No matching host in p0f cache. That's all we know.
X-Spam_score_int -8
X-Spam_score -0.9
X-Spam_bar /
X-Spam_report (-0.9 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01 autolearn=_AUTOLEARN
X-Spam_action no action
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <7633.1593639393@jinx.noi.kre.to>
X-Mailman-Original-References <871rlvcdzc.fsf@igel.home> <pn9ffe39.dag@gnui.org> <tuysgrgt.dag@gnui.org> <pn9hipci.dag@gnui.org> <ac4a98bd-32f4-5c55-3b8f-1306e9758f54@case.edu> <7dvoi92p.dag@gnui.org> <09ea84b2-4fb1-6b05-7c0b-fe6b2ab00c6f@archlinux.org> <2643.1593599092@jinx.noi.kre.to> <14637.1593625593@jinx.noi.kre.to>
Xref csiph.com gnu.bash.bug:16523

Show key headers only | View raw


    Date:        Wed, 01 Jul 2020 20:00:23 +0200
    From:        Andreas Schwab <schwab@linux-m68k.org>
    Message-ID:  <871rlvcdzc.fsf@igel.home>

  | But it also says:
  |
  |     If command is not found, the exit status shall be 127. If command is
  |     found, but it is not an executable utility, the exit status shall be
  |     126.

If the command is built-in, it can hardly not be found, so the first
half of that doesn't apply.  All that's left is "executable utility".
That isn't actually defined anywhere, but "utility" is, and while it
excludes the special built-ins, everything else that can be run as
a command counts, including those that only make sense when built in
(like say, command).

bash
jinx$ echo $$
10628
jinx$ exec command echo hello
bash: exec: command: not found
jinx$ echo $$
10628
jinx$ exit

NetBSD (deliberately, as it is stupid) ignores the requirement that
all non-special builtns be also provided as commands in the filesystem,
if we had a /usr/bin/command (or something) I assume bash would have
run it (even though XCU 2.9.1.1 1.d says that "command" is one of the
magic builtins which should be run as the built-in without bothering
with a PATH search first).


Having said all this, do be aware that this is all relevant to the
current POSIX standard, the next version [probably] changes the wording to:

   If exec is specified with a utility operand, the shell shall execute
   a non-built-in utility as described in Section 2.9.1.6 with utility
   as the command name [...]

It will also require interactive top level shells not to exit on
exec error,

[None of this is set in stone yet, and changes might still be made].

The first of those changes matches what most shells do (as I said earlier),
the second will require changes in most shells, which currently do exit
as the current standard requires.,

kre


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


Thread

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

csiph-web