-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
wait does not return on signal with handler #10193
Comments
Out of curiosity I made a test of trap behavior for bash, zsh, and fish at https://github.com/stevenpelley/shell-wait-trap-test If I decide to take this any further I'll post elsewhere first (mailing list?) |
The mailing list is pretty inactive and not where we tend to discuss bugs or enhancements. And speaking for myself I barely use |
Thanks @faho My take is that bash/zsh/sh wait is itself "incomplete" and has become confusing as it evolved. In https://github.com/stevenpelley/bash-playground?tab=readme-ov-file#proposed-new-options I list my desired behavior. Since fish isn't aiming to be posix compliant there's an opportunity to rethink wait's behavior. Of course, you want some out of the box familiarity for those coming from other shells. If fish provided my desired behavior it would be a strong reason for me to use it over other shells. I've also seen a number of confused and frustrated posts on HN, reddit, and stack overflow by people trying to solve similar problems with traditional shells. Some related details that I find confusing: Fish has TRAP, and allows disabling signals with an empty string (TRAP "" SIGTERM), but it's not clear how/if this interacts with event handlers for signals. Does this disable event handlers for the same signal, or does it only ignore default signal handling and undo previous calls to TRAP? ignored traps are also ignored in subshells (I know there are none in fish) and any child processes (https://pubs.opengroup.org/onlinepubs/007904875/functions/exec.html -- paragraph starts Signals set to the default action; also discussed in https://pubs.opengroup.org/onlinepubs/009695399/utilities/trap.html). I haven't tested this, it's just something I ran into with bash, is related to this discussion, and the behavior should be defined whether it follows sh or not. |
I'm interested in moving this forward and might be willing to contribute depending on how messy it gets. In the short term I believe this is solved in signals.rs::fish_signal_handler in "match sig" SIGTERM case by adding Simply doing this leaves some confusion (or contributes to it, posting to a signal-named topic that doesn't include "term") and additionally does nothing for all of the other signals that might be observed/trapped but do not post to a topic monitor.
Reference: wait and trap behavior. I want to aim for POSIX-compatible sh semantics, and deviate from that when there's a good reason to. Or at least there are useful aspects of POSIX sh that I'm aiming for with this improvement.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/wait.html for general wait semantics. I'm going to skip advanced features like Rust implementation details: to check my understanding and document. In fish_signal_handler there are then a number of per-signal actions in a match block. These contain: |
the "wait" command does not return when receiving a signal for which a handler is defined. Consider the following script:
If I
kill -SIGTERM <PID>
with the script's PID nothing happens. When I uncomment the "sleep 5" and comment out the "wait" I see the output of "jobs" every 5 seconds, and when I againkill -SIGTERM <PID>
it will execute the handler and subsequently terminate once the "sleep" completes.Changing "set sig SIGTERM" to "set sig SIGINT" results in different behavior: With "wait" (not "sleep") a SIGTERM sent to the fish script (kill -SIGINT, not ctrl-c) does cause wait to return and then execute the handler. It correctly returns 130 (128 + SIGINT's 2) according to POSIX sh's wait semantics (not documented in fish). However, the SIGINT does not kill the child fish process and so the loop continues. It appears that even a manual
kill -SIGINT <PID>
fails to kill it. But this is a different problem or undocumented intended behavior (couldn't find anything, sorry if it is documented).The documentation doesn't actually specify that wait will return immediately on any signal with a defined hander/trap, but the syntax so closely matches POSIX and related shells' wait command that I assume the intent is to match those semantics. Ideally I want something akin to https://www.gnu.org/software/bash/manual/html_node/Signals.html to list the intricacies of various signals, handlers, and interaction with commands/builtins
The text was updated successfully, but these errors were encountered: