-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exec: Don't exit after error in interactive shells #803
Conversation
As of POSIX.1-2024, interactive shells are not allowed to exit when exec(1) fails to run a command[*]. This commit amends ksh's implementation to comply with this requirement (in path_exec()). [*]: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_21
Thanks for the PR! One problem:
...and now you have a basically unusable shell: no prompt is displayed and nothing you type is echoed. You're operating blind. This behaviour is actually specified by POSIX 2024: "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." But I think that's worse than it was before; at least when you lost your shell you could log back in or reopen the terminal window, and you didn't have to operate blind. So I do wonder if this highly undesirable side effect in the case of a nonexistent comment was actually intended by the resolution of Austin Group bug 1157. |
Why does the spec say "If the exec command fails and the shell does not exit..."? What's the point of the and?
It failed the |
The point is that the shell, in the new 2024 spec, shall not exit on failure to execute the command if it is interactive. In other words, if it's non-interactive, it still exits. None of this affects scripts, by the way, or even subshells of interactive shells. Nothing changes there compared to the old spec.
It doesn't hang though, it just doesn't show any output. You can blindly type something (e.g. Still, I think this is clearly broken, it's not something I am willing to subject users to, and I will file an Austin Group bug about it. When a user does 'exec cmd >file', they expect the shell to be replaced by
They are still acting according to the pre-2024 spec.
That is sane behaviour, and it's how I would like ksh to act. |
I'll merge this first, then fix the usability issue separately. |
As of POSIX.1-2024, interactive shells are not allowed to exit when exec(1) fails to run a command[*]. This commit amends ksh's implementation to comply with this requirement (in path_exec()). [*]: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_21
As of POSIX.1-2024, interactive shells are not allowed to exit when
exec
fails to run a command*. This commit amends ksh'sexec
implementation to comply with this requirement (inpath_exec()
).