The following issue has been SUBMITTED. ====================================================================== https://austingroupbugs.net/view.php?id=1896 ====================================================================== Reported By: McDutchie Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1896 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Martijn Dekker Organization: ksh 93u+m: https://github.com/ksh93/ksh User Reference: https://austingroupbugs.net/view.php?id=1157 Section: XCU 2.5: exec Page Number: 2538 Line Number: 82774-82776 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2024-12-18 21:33 UTC Last Modified: 2024-12-18 21:33 UTC ====================================================================== Summary: Harm caused by permanent redirections on failure to 'exec' a utility in the interactive shell Description: In and of itself, I would consider the new requirement that <i>exec</i> avoid exiting an interactive shell upon failure, particularly the failure to execute a specified <i>utility</i>, a major improvement from a usability perspective.
But a contradiction now exists between lines 82761-82762: <blockquote>If <i>exec</i> is specified with no operands, any redirections associated with the exec command shall be made in the current shell execution environment.</blockquote> and lines 82774-82776: <blockquote>If the <i>exec</i> command fails and the shell does not exit, any redirections associated with the <i>exec</i> command that were successfully made shall take effect in the current shell execution environment.</blockquote> The contradiction occurs when a <i>utility</i> is specified for execution and replacing the shell. Lines 82761-82762 state that redirections only apply to the current environment if no operands are specified, but lines 82774-82776 state that they apply to the current environment regardless of whether operands are specified if <i>exec</i> fails (e.g. to execute a <i>utility</i>) and the shell does not exit (as in, the shell is interactive). Two interpretations are possible: either (1) lines 82774-82776 override lines 82761-82762 in that case, or (2) they don't. In interpretation 1, which seems like the most obvious one, the effects are very seriously problematic. For example, the following: $ exec some_command_name_with_a_typo >/dev/null 2>&1 would be required to make the `>/dev/null 2>&1` redirections persist in the current interactive shell environment. So now you have a shell that cannot produce any output -- it can't even echo command input. That shell has become basically inoperable. If standard input is redirected, the effects are much more serious still. For example, the following: $ exec some_command_name_with_a_typo </some/file would require the shell, after throwing the 'command not found' error, to read the contents of /some/file and execute it as commands typed by the user on the interactive command line (and then exit (!) upon reaching end of file as if the user had typed ^D). It should go without saying that, depending on the contents of /some/file, the effects are potentially catastrophic. When a user does <i>exec cmd >file</i>, they expect the shell to be replaced by <i>cmd</i> with the redirection to <i>file</i> in effect. But if <i>cmd</i> cannot be executed and the shell is not replaced, then it is simply <b><u>wrong</u></b> for the redirection to persist, because the user clearly intended and expected it to take effect for <i>cmd</i> only. In interpretation 2, sanity is preserved. The shell throws an error on command not found, the redirection state is restored, and all is well. (If the shell process <b>is</b> successfully replaced by the <i>utility</i>, then any question of persistence or non-persistence of redirections is moot. It does not matter if the shell saves the redirection state or not, because it's not going to be able to restore it before being replaced.) To the best of my knowledge, the current shell situation is: - Bash 5.2 has unfortunately taken interpretation 1, and thus breaks in exactly the dangerous ways described. - Yash 2.57 has wisely taken interpretation 2. - Other shells have not yet implemented the new requirement. - KornShell 93u+m, which I will maintain, will take interpretation 2 in the next release. The desired action is to specify the current behaviour of yash. I believe it should be sufficient simply to remove lines 82774-82776. If a <i>utility</i> is specified, these lines either make no sense or specify dangerous and wrong behaviour, and if no operands but only redirections are specified, they seem redundant (given lines 82761-82762). Desired Action: Remove lines 82774-82776. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2024-12-18 21:33 McDutchie New Issue 2024-12-18 21:33 McDutchie Name => Martijn Dekker 2024-12-18 21:33 McDutchie Organization => ksh 93u+m: https://github.com/ksh93/ksh 2024-12-18 21:33 McDutchie User Reference => https://austingroupbugs.net/view.php?id=1157 2024-12-18 21:33 McDutchie Section => XCU 2.5: exec 2024-12-18 21:33 McDutchie Page Number => 2538 2024-12-18 21:33 McDutchie Line Number => 82774-82776 ======================================================================
