/etc/rc.initial does not trap CTRL-C back to console menu but rather to # prompt.
I found a problem with trap mechanism in /etc/rc.initial that does not trap CTRL-C back to ssh/cli console menu.
Instead it ends up in # prompt. If I then do exit, it goes back to menu as it should.
I could see that the existing /etc/rc.initial has the trap 2 , 3 and 4 commented.
# make sure the user can't kill us by pressing Ctrl-C,# ctrl-z, etc.
#trap : 2#trap : 3
@#trap : 4
I tried to uncomment "trap 2" (which is CTRL-C) and then it worked as it should. Whenever I do CTRL-C it always return to the ssh/cli console menu.
I also had a look in the repository for the /etc/rc.initial and found a commit:
Scott Ullrich committed on 2 Mar 2007
ctrl-c is handy in the shell. Do not lock out.
-trap : 2
-trap : 3
-trap : 4
+#trap : 2
+#trap : 3
+#trap : 4
Scott Ullrich committed on 19 Jun 2005
-# make sure the user can't kill us by pressing Ctrl-C
+# make sure the user can't kill us by pressing Ctrl-C,
+# ctrl-z, etc.
However, I think this is not entirely true as what I found when testing was that with "trap 2" enabled
the CTRL-C does work but the difference is that you will get back to console menu instead of # prompt.
As console menu has a menu "8 Shell" it is possible to get to pure shell even from console menu
so the CTRL-C inside functions like "Filter Logs" will let the user get back to console menu instead of # prompt.
I am not sure though if the "trap 2" will break anything if executed from non Serial / Ssh console.
Updated by Jim Pingle almost 5 years ago
- Status changed from Feedback to Resolved
Works well. I went into several console menu options and confirmed ^C returned to the menu from all of them rather than generating a shell prompt. From inside a shell prompt (option 8), ^C still worked as usual when working interactively as expected.