Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001896 [1003.1(2024)/Issue8] Shell and Utilities Objection Error 2024-12-18 21:33 2025-01-08 19:56
Reporter McDutchie View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Resolved  
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 Note: 0007023
Summary 0001896: 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 exec avoid exiting an interactive shell upon failure, particularly the failure to execute a specified utility, a major improvement from a usability perspective.

But a contradiction now exists between lines 82761-82762:

If exec is specified with no operands, any redirections associated with the exec command shall be made in the current shell execution environment.


and lines 82774-82776:

If the exec command fails and the shell does not exit, any redirections associated with the exec command that were successfully made shall take effect in the current shell execution environment.


The contradiction occurs when a utility 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 exec fails (e.g. to execute a utility) 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 exec cmd >file, they expect the shell to be replaced by cmd with the redirection to file in effect. But if cmd cannot be executed and the shell is not replaced, then it is simply wrong for the redirection to persist, because the user clearly intended and expected it to take effect for cmd 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 is successfully replaced by the utility, 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 utility 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.
Tags tc1-2024
Attached Files

- Relationships

-  Notes
(0007014)
larryv (reporter)
2024-12-18 22:02

 Description:
Bash 5.2 has unfortunately taken interpretation 1, and thus breaks in exactly the dangerous ways described.
This is longstanding behavior in bash, not a response to the new requirement:
zsh-5.9% /bin/bash --norc
bash-3.2$ exec nosuchcmd <<<'echo oh no'
bash: exec: nosuchcmd: not found
bash-3.2$ echo oh no
oh no
bash-3.2$ exit
zsh-5.9%
But I agree that it's not great.
(0007017)
geoffclare (manager)
2024-12-19 11:15

 I think the reason lines 82774-82776 are there is because of this:
$ exec > foo 2> .
-ksh: .: cannot create [Is a directory]
$ echo hello
$ cat foo >&2
hello

The redirection of stdout was successfully made and takes effect in the current shell execution environment.

So I think those lines should not be removed, but altered to say "If an exec command with no operands fails and the shell does not exit, ..."
(0007023)
geoffclare (manager)
2024-12-19 16:37

 On page 2538 line 82774 section exec, change:
If the exec command fails and the shell does not exit, any redirections ...

to:
If an exec command with no operands fails and the shell does not exit, any redirections ...
(0007025)
McDutchie (reporter)
2024-12-19 20:21

 Thanks to @larryv for the correction. I should have tested old bash versions.

Another 'exec' thing, I'm not sure if it's worth opening a separate issue. Lines 82762-82764 state:
If any file descriptors with numbers greater than 2 are opened by those redirections, it is unspecified whether those file descriptors remain open when the shell invokes another utility.
I assume this was to allow for the behaviour of ksh93, which opens file descriptors > 2 close-on-exec when they are redirected with exec. But, in the POSIX mode on ksh 93u+m, I've disabled that behaviour for compatibility with other shells. To the best of my knowledge, ksh93 has always been the only shell with this behaviour. So I think POSIX can now specify that they stay open.
(0007037)
chet_ramey (reporter)
2025-01-08 19:56

 Re: Note 7023

You might want to reconsider those lines. In addition to it being a bad idea, shell behavior with respect to preserving successful redirections is by no means universal.

Shells that undo the successful redirections: bash, mksh, yash, dash, zsh, gwsh

Shells that preserve them: ksh93, NetBSD sh, FreeBSD sh

I suggest making the behavior unspecified: "If an exec command with no operands fails and the shell does not exit, it is unspecified whether any redirections ..."

- 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
2024-12-18 22:02 larryv Note Added: 0007014
2024-12-19 11:15 geoffclare Note Added: 0007017
2024-12-19 16:37 geoffclare Note Added: 0007023
2024-12-19 16:38 geoffclare Interp Status => ---
2024-12-19 16:38 geoffclare Final Accepted Text => Note: 0007023
2024-12-19 16:38 geoffclare Status New => Resolved
2024-12-19 16:38 geoffclare Resolution Open => Accepted As Marked
2024-12-19 16:39 geoffclare Tag Attached: tc1-2024
2024-12-19 17:06 geoffclare Project 1003.1(2016/18)/Issue7+TC2 => 1003.1(2024)/Issue8
2024-12-19 20:21 McDutchie Note Added: 0007025
2025-01-08 19:56 chet_ramey Note Added: 0007037

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker