^C exits osh instead of foreground process about oil

[Wychmire]

Just built 0.6.pre19 and I can no longer replicate the issue. Thanks for the quick reply and fix!

[andychu]

@Wychmire Sorry about that and thanks for testing Oil!

I just committed a fix for this -- it was a build error with the original fix. I plan to make a release shortly and I'll close this bug again once that's done. Let me know if you find any other problems -- they are really useful reports!

[acg]

Same with handling of other terminal signals (^Z).

[andychu]

Thanks good point. Yes OSH isn't doing any signal handling at all right now.

I forget exactly how it works but I think we have to change the session group when starting a process. That way signals only get delivered to cat and not to osh.

I have to implement the trap builtin too so this could be done at the same time.

[acg]

I forget exactly how it works but I think we have to change the session group when starting a process.

Yup pretty sure you need a setsid(2).

[icarroll]

As an aside, if OSH is the login shell for an ssh connection, ^C kills OSH and closes the connection.

[andychu]

Also mentioned here: https://lobste.rs/s/l8r1nw/why_create_new_unix_shell#c_sfmsrv

[andychu]

Hm I fixed the Ctrl-C issue by registering a handler for SIGINT, but it looks like SIGSTOP is special and you can't register a handler for it.

I am not sure exactly how it works.

BTW I'm pretty sure setsid() is supposed to be called by the login program that starts the shell, not the shell itself. I grepped the source code of bash and dash, and strace'd them, and they don't appear to call it.

Let me file a new bug for Ctrl-C.

[andychu]

Ctrl-C now displays ^C instead of exiting.

http://www.oilshell.org/release/0.6.pre16/

The crash was fixed a long time ago, but sorry I didn't get the bash behavior until recently! I thought it required replacing Python's signal module, but it turns out it didn't.

I didn't need to use setsid() -- apparently shells just handle the signal themselves and then change the process state when forking children.

Thanks for the report! Keep them coming.

[Wychmire]

This is still happening on 0.6.pre18. I can replicate it consistently with the commands in the OP and when running yay. I do get a traceback, maybe it can be useful.

Traceback (most recent call last):
  File "/home/andy/git/oilshell/oil/bin/oil.py", line 766, in _cpython_main_hook
  File "/home/andy/git/oilshell/oil/bin/oil.py", line 748, in main
  File "/home/andy/git/oilshell/oil/bin/oil.py", line 722, in AppBundleMain
  File "/home/andy/git/oilshell/oil/bin/oil.py", line 534, in ShellMain
  File "/home/andy/git/oilshell/oil/core/main_loop.py", line 114, in Interactive
  File "/home/andy/git/oilshell/oil/osh/cmd_exec.py", line 1234, in ExecuteAndCatch
  File "/home/andy/git/oilshell/oil/osh/cmd_exec.py", line 1182, in _Execute
  File "/home/andy/git/oilshell/oil/osh/cmd_exec.py", line 1127, in _Dispatch
  File "/home/andy/git/oilshell/oil/osh/cmd_exec.py", line 596, in RunSimpleCommand
  File "/home/andy/git/oilshell/oil/core/process.py", line 621, in Run
  File "/home/andy/git/oilshell/oil/core/process.py", line 593, in WaitUntilDone
  File "/home/andy/git/oilshell/oil/core/process.py", line 865, in Wait
AttributeError: 'module' object has no attribute 'WTERMSIG'
FATAL: couldn't import from app bundle '/usr/local/bin/oil.ovm' (1)
Stripping the oil.ovm binary may cause this error.
See https://github.com/oilshell/oil/issues/47