#74: add option to run as interactive, so we don't abort() throwing STACK_BUFFER_OVERRUN

[FGeloso]

I'm sending this PR to fix #74.

The issue was that shawl was throwing STACK_BUFFER_OVERRUN error to windows, showing up in the event viewer. It happened randomly during a restart, but then I tried sending CTRL_BREAK_EVENT from the binary being run and it happened there too.

From what I see, there is no need for shawl to do something during events thrown from the console. It's already expected that, if shawl sent the event, it shouldn't do anything. Since these events are only thrown for the console, and the console is only there to send the event to the child program, I believe the rest of the events can be ignored too.

Here I've added a new flag --interactive, so it can be "interacted" through these events, just like it works now, but by default it won't do anything to handle control events.

[mtkennerly]

Hi! Thanks for the PR and investigating the issue here.

Just making sure I understand, if the child process sends its own ctrl+C signal, then that causes Shawl to abort? In #74, you also mentioned that it still happened if you commented out the child process spawning - does that mean Windows itself is also sending some ctrl+C signal to Shawl? I just want to make sure we understand where the signal is coming from before we ignore it.

Out of curiosity, what if we replace std::process::abort(); with std::process::exit(0)? That would silence the error, but then what other side effects do you see? Would Shawl be left in a stopped state when it's supposed to start automatically on system startup?

[FGeloso]

Yeah, it's like you say: either sending ctrl c from the child process, or when the computer is shutting down (where windows sends ctrl break to consoles), the console alloc'd at the start of the shawl process receives it, and gets handled by shawl's control handler.

Since it's not expected by shawl (with the whole part of the code that does the ignore_ctrlc), it goes on and aborts.

I will try with exit tomorrow (and fix the linter issue while am at it), and comment the results

[FGeloso]

I've just tried doing std::process::exit(0) instead of abort() or not doing nothing like in the PR. That doesn't throw the STACK_BUFFER_OVERRUN. However, if the running child program sends ctrl break, then shawl exits and it doesn't restart the child program with the flag on

[mtkennerly]

Thanks for checking!

I did some testing to see if we could use a separate process group to isolate ctrl+C events between Shawl and the wrapped command, but apparently that would require Shawl to send ctrl+break instead of ctrl+C (or for the wrapped command to reinitialize its ctrl+C handling), so I think your solution is the better option.