echo $? prints 130 after ^C on a fresh terminal

ychaouche · 11-04-2020, 05:11 AM

Open a terminal, ^C, echo $?. On my system, I get 130. Comments ? (I'm curious to know what happened)

pan64 · 11-04-2020, 05:55 AM

obviously not enough info. But if I need to guess, check PS1.

ychaouche · 11-04-2020, 06:27 AM

Code:

ychaouche#ychaouche-PC 13:26:49 ~ $ ^C
ychaouche#ychaouche-PC 13:26:51 ~ $ echo $?
130
ychaouche#ychaouche-PC 13:26:54 ~ $ echo $PS1
\[\033[01;32m\]\u#\h\[\033[01;37m\] $(date +%T) \w \$\[\033[00m\]
ychaouche#ychaouche-PC 13:26:58 ~ $

teckk · 11-04-2020, 06:34 AM

https://linux.die.net/abs-guide/exitcodes.html
https://linux.die.net/abs-guide/exit-status.html

ychaouche · 11-04-2020, 06:38 AM

What was the process receiving ^C and exiting, was it bash itself ? if so, why do I have another prompt ? does every new line start a new bash process ?

rtmistler · 11-04-2020, 06:57 AM

Code:

void main(void)
{
    printf("String for errno 130 is %s\n", strerror(130));
}


$ ~/testcode
$ ./test-err.exe
String for errno 130 is Too many processes

From my system errno.h file:

Code:

#define EPROCLIM 130

My terminal performs this to.

I'm sure there's some sort of explanation for it, but I'm only concerned when I need to parse the return error value from a bash call or a system call in my programs.

pan64 · 11-04-2020, 06:58 AM

Quote:

Originally Posted by ychaouche

What was the process receiving ^C and exiting, was it bash itself ? if so, why do I have another prompt ?

looks like something was started in the background. Either from .bashrc, from PS1 or whatever....

Quote:

Originally Posted by ychaouche

does every new line start a new bash process ?

in general no, but in some special cases it can happen.

rtmistler · 11-04-2020, 07:01 AM

Quote:

Originally Posted by ychaouche

What was the process receiving ^C and exiting, was it bash itself ? if so, why do I have another prompt ? does every new line start a new bash process ?

CTRL-C is a signal only, you'll have to look up if it is SIG_INTERRUPT (sp) or SIG_KILL and then determine what the signal it causes will do to a normal shell terminal.

Since it is not logoff, your shell is not going to exit. The terminal shell is a program, written to pay attention to signals, or ignore them, or use the default behaviors assigned by the system. Recommend if you consider these to be pressing questions that you determine which shell and version you have, and seek out the source code for it, as well as research what signal CTRL-C gives to a process and determine if the shell program is processing that as part of it's source code or if it is using the system default. Then determine what, if any, system default for that signal is, it may be to ignore it.

rtmistler · 11-04-2020, 07:08 AM

Quote:

Originally Posted by pan64

looks like something was started in the background. Either from .bashrc, from PS1 or whatever....

FWIW I don't think anything's started in the background. A brand new shell terminal on my system does exactly this.

I see this on cygwin, Debian 10, Peppermint, and Mint 19.

You create a new terminal, echo $? you get 0.
Hit CTRL-C, echo $?, you get 130.

Once again I feel this just merits inspecting what the default system behavior is for that signal, and a determination as to what the shell program may do if given that signal.

pan64 · 11-04-2020, 07:13 AM

Quote:

Originally Posted by rtmistler

FWIW I don't think anything's started in the background. A brand new shell terminal on my system does exactly this.

I see this on cygwin, Debian 10, Peppermint, and Mint 19.

You create a new terminal, echo $? you get 0.
Hit CTRL-C, echo $?, you get 130.

Once again I feel this just merits inspecting what the default system behavior is for that signal, and a determination as to what the shell program may do if given that signal.

in that case the interrupt handler itself is that (what was started).

GazL · 11-04-2020, 07:18 AM

An exit-code > 128 is usually the result of a signal. exit-code - 128 gives the signal number, in this case 2 (SIGINT).

ctrl-c from the tty triggers a sigint to be sent to the foreground process-group. If no process is being run at the time, then I would assume that foreground process is bash itself. I would also assume that bash traps the sigint and just sets $? to 130 instead of exiting.

ychaouche · 11-04-2020, 07:27 AM

Quote:

Originally Posted by GazL

An exit-code > 128 is usually the result of a signal. exit-code - 128 gives the signal number, in this case 2 (SIGINT).

ctrl-c from the tty triggers a sigint to be sent to the foreground process-group. If no process is being run at the time, then I would assume that foreground process is bash itself. I would also assume that bash traps the sigint and just sets $? to 130 instead of exiting.

For what it's worth I'm actully doing this via konsole which is a terminal application. I'm guessing it has the same behaviour as if I ran it from a tty ? (i.e ^C is sent to the bash not konsole)

GazL · 11-04-2020, 07:35 AM

As I understand it, it's actually done by the kernel's tty or pty driver (which terminal emulators all use), The terminal emulators only involvement is writing a ^C character to the pty.