Cannot properly trap SIGINT

[Nan0Scho1ar]

I am trying to trap SIGINT in my ahoy cmd to kill a process gracefully, but ahoy dumps me straight back into the shell as soon as I hit Ctrl-C. I have also tried setting a custom bash entrypoint to trap SIGINT then manually call kill -SIGINT $child_process in an attempt to prevent this. Both options seems to receive and trap the interrupt thus calling the clean up code. However, because ahoy has already dropped me back into the shell (and printed the PS1 etc) the cleanup output makes quite a mess of my terminal.

The trap/cleanup functionality works perfectly fine (no mess) when not called using ahoy.

Is is possible for ahoy to pass on the SIGINT to the child process without being immediately dropped back into the shell?

[ocean]

Hi @Nan0Scho1ar and thanks for your issue.

I'm one of the new maintainers that have just been added to the project, I use ahoy daily and am interested in improving its capabilities for other users.

At present we are focusing on some chores such as getting the current code and dependencies updated to recent Go modules, and getting a new release out with those updates.

We can continue the discussion about your issue here, but I'm just letting you know it may not be actioned straight away.

[jackwrfuller]

@ocean @AlexSkrypnyk

From some preliminary research, it looks like this issue is addressed by v2 of urfave/cli: urfave/cli#975.

If we do end up proceeding with migrating ahoy to v2 of urfave/cli, then it I think we solve this one for free.

[AlexSkrypnyk]

This just hit me: any time I'm using watch in the Docker container through Ahoy, Ctrl+C does not send the correct SIGINT and the process remains running in the container.

Would be great to prioritise this.

[ocean]

@AlexSkrypnyk Ok, just describing this back to you so I can be sure I understand what you mean.

So, if you have a long running process that was started by Ahoy, then when you press Ctrl+C, it appears the SIGINT is sent to Ahoy, which then quits itself, but Ahoy doesn't first quit the running process that it started for you?

That does sound annoying, I'll have a bit more of a look.

As Jack said, we're sort of stuck at the moment with upgrading the CLI library (which seems like it might fix this issue), because the library update has quite an annoying breaking change in it.