Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: Robert Elz Newsgroups: gnu.bash.bug Subject: Re: =?utf-8?B?4oCYY29tbWFuZCDigKYgJuKAmQ==?= creates subshell Date: Wed, 01 Jul 2020 17:24:52 +0700 Lines: 38 Approved: bug-bash@gnu.org Message-ID: References: <7dvoi92p.dag@gnui.org> <09ea84b2-4fb1-6b05-7c0b-fe6b2ab00c6f@archlinux.org> <2643.1593599092@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 1593599161 25922 209.51.188.17 (1 Jul 2020 10:26:01 GMT) X-Complaints-To: action@cs.stanford.edu Cc: Eli Schwartz , bug-bash@gnu.org To: Dmitry Alexandrov Envelope-to: bug-bash@gnu.org In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <2643.1593599092@jinx.noi.kre.to> X-Mailman-Original-References: <7dvoi92p.dag@gnui.org> <09ea84b2-4fb1-6b05-7c0b-fe6b2ab00c6f@archlinux.org> Xref: csiph.com gnu.bash.bug:16505 Date: Wed, 01 Jul 2020 00:43:14 +0300 From: Dmitry Alexandrov Message-ID: | > If you need to ensure a disk executable is used, | Of course. Why "command" otherwise? That doesn't actually work, "command" can run built-ins, there is actually no method (not even via use of "env") which guarantees execution of an executable from an external file, other than by using the complete path name (containing at least one '/') of the desired file. command avoids executing functions. That's its purpose (so you can write cd() { test "$1" = "-b" && set -- whatever command cd "$@" } (probably not quite that) without getting recursive "cd' invocation. It also changes the rules for what happens with errors encountered with special builtins (but unless in posix mode, bash tends to ignore those anyway). When given no options (just args) or with just -p (and args), there's no reason at all for "command" to ever invoke a subshell for itself, all it does is alter the search strategy for the command name that follows. I'd actually call bash's behaviour a bug, and if not strictly that, then certainly "extraordinarily non-intuitive" - rather than just an "untaken (yet) opportunity for optimisation". kre