2 ms·

> It never actually does both at the same time -- it doesn't wait for processes and stream input simultaneously Couldn’t you use a signalfd to receive the SIGC

• chubot 4y ago
  So there was a correction here, zsh and fish do wait for processes in the interactive part, but apparently not bash/dash/mksh: https://lobste.rs/s/om32da/unix_process_api_is_unreliable_unsafe#c_amz4g4 https://lobste.rs/s/om32da/unix_process_api_is_unreliable_un... As far as your question, shells don't use signalfd() because it's Linux-only! Most shells predate not just signalfd(), but Linux itself :) I wouldn't use it in a newer shell for portability. If it ever came up, I probably I would use the self-pipe trick. BTW I think there was some argument awhile ago that signalfd() is actually quite bad in the presence of threads, but a shell doesn't have threads so that doesn't matter.
  • teddyh 4y ago
    > but apparently not bash In bash, try “set -o notify” (same as “set -b”). This will turn on immediate notification of terminations of subjobs. So it’s not that bash lacks support for it, it’s that bash wants to be compatible with old Unix shells, but offers other behavior as an option.