Path: csiph.com!goblin2!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: Thu, 02 Jul 2020 00:46:33 +0700 Lines: 62 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> <14637.1593625593@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 1593625635 11078 209.51.188.17 (1 Jul 2020 17:47:15 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: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:3c8:9009:181::2 (failed) 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: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, 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: <14637.1593625593@jinx.noi.kre.to> X-Mailman-Original-References: <7dvoi92p.dag@gnui.org> <09ea84b2-4fb1-6b05-7c0b-fe6b2ab00c6f@archlinux.org> <2643.1593599092@jinx.noi.kre.to> Xref: csiph.com gnu.bash.bug:16515 Date: Wed, 01 Jul 2020 18:29:46 +0300 From: Dmitry Alexandrov Message-ID: | 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