Implementing semantics about traps

[magicant]

• Extend environment for traps #108
• Implement the trap built-in (minimum behavior) #111
• Restore signal handlers not set by current traps before execing #110
• Run traps after reading commands 8169166
• Run trap commands after simple command target #114 Run traps after running command #115
  • Prevent running traps while running another cd9af1c
    • Allow reentrance if in subshell in trap
  • Include the signal name for the label of Source::Trap
    b9aa8606985836413fcbfcef292bb0c68be63f98629261c953f657fbcaba635fR140-R142)
• Remove non-ignore handlers when starting subshells #116
  • Special handling for printing traps in subshells #120 (especially in command substitutions)
• Internal handlers for SIGINT, SIGTERM, SIGQUIT, SIGTTIN, SIGTTOU, and SIGTSTP
• Run EXIT trap #236
  • Introduce yash_env::trap::Condition #234

More trap-related tasks tracked in #260

[magicant]

Run traps while reading commands

POSIX does not precisely specify when the shell should execute trap commands. Some shells (bash, dash, and mksh) do not seem to run them while waiting for command-line input. If their behavior is acceptable, yash-rs's implementation can be simpler than the current yash.

If yash-rs is going to run traps while reading input, we will need a clever trick to make it possible to read input and run commands simultaneously. Especially:

• Running commands requires a mutable reference to the entire Env while the lexer and parser also need a (non-mutable) reference to the alias set.
• The shell must suspend reading when it receives a signal. In other words, the shell must not read input while running traps.
• If line-editing is active, the shell should also suspend it while running traps.