Which signal does ctrl-x send when used in a terminal?

Question

On Linux/Unix there are signals. The CtrlC one (SIGINT) is obvious to me. Now, in some other applications there are signals via CtrlX?! Is that even a signal or does it generate an escape sequence? Is there anything else I can use as something similar to CtrlC ( CtrlV, CtrlX ...)?

If anyone has a clue, im familiar with C more than bash, but answers in both languages are appreciated!

Foley

Perhaps not a complete list: http://www.cdrinfo.com/Sections/Reviews/Specific.aspx?ArticleId=19672 – Rejoin

Answer 1

To get all the terminal control character assignments:

stty -a

Islas

Remember these are only the control-character assignments (where the character is converted into a signal?). As indicated, other functions may exist, such as the helpful ^X, * for expansion mentioned below. – Edom

For instance, see the information about (bash) command line editing here. – Edom

Answer 2

There is possibly a misunderstanding. CtrlC does not generate a signal. It is perfectly possible to press CtrlC anywhere, and no bad things will happen (for example in every text editor or word processor, that's the de-facto-standard for "copy").

However, when you run a program in the shell, then your keypresses really go into the shell, not into your program. The shell will forward (almost) everything to your program's stdin, and forward anything coming from stdout to either the terminal or another process or a file (if you used a pipe or redirection).

If the shell sees you press CtrlC, then the shell sends the interrupt signal. But that's really just something the shell does, not something that magically happens because of the key combination.

About CtrlX, you probably meant CtrlZ. This stops a process, and the shell outputs a number which you can use with fg to make it run again.

Guthrie

Ctrl-C causes SIGINT to be sent, not SIGTERM. Also, it's the terminal, not the shell, that sends SIGINT when the break combination is pressed (see the BRKINT flag). I think you're right about Ctrl-C being translated by the shell. – Wulfila

My bad, of course... if it was SIGTERM, you could not block (or handle) it, which you can, obviously. – Guthrie

I am aware of the fact that ctrl-C is not the signal. If i'd write that out there nobody could understand the question, and its too simple to write about a lot of fancy things. – Foley

@Ben Voigt: To me, this comment reads as if it's really bash getting the Ctrl-C, but I might of course be wrong. Not like it really matters. :-) – Guthrie

@Damon: SIGTERM can be handled. Perhaps you're thinking of SIGKILL? There are two key combinations which raise SIGINT: Ctrl-C is processed by the shell, and Ctrl+Break is processed by the terminal. – Wulfila

@imacake: What I wanted to point out is that the signal is merely a shell/terminal feature. The keypress is a shorthand for typing kill followed by the PID of the foreground process. It is in some way similar to when you type rm *. This looks like and works like the rm program calls a library function with a wildcard that just works on "all files" (and, note that some functions under Windows indeed work that way). In reality, the shell secretly works out the names of all files and passes them to your program one by one on the commandline. – Guthrie

@Ben Voigt: Yep, thinking of SIGKILL (numeric value 9). It's time to stop working for me today, I'm not able to think straight any more... :-) – Guthrie

@Ben Voigt: I'd assume Ctrl-C is handled by the terminal, Ctrl-Break isn't supported on *nix, and BRKINT controls serial line BREAKs (logical 0 for a certain amount of time IIRC). – Incised

@ninjalj: You're mostly right about that, but please note that BREAK isn't limited just to asynchronous serial lines, most terminals have an encoding for the break character (serial terminal software will convert a UART break condition to the break character, terminal emulators often recognize Ctrl+Break or provide a menu to generate the break character). – Wulfila

Answer 3

From Wikipedia

Ctrlx Ctrle : Edits the current line in the $EDITOR program, or vi if undefined.

Ctrlx Ctrlr : Read in the contents of the inputrc file, and incorporate any bindings or variable assignments found there.

Ctrlx Ctrlu : Incremental undo, separately remembered for each line.

Ctrlx Ctrlv : Display version information about the current instance of bash.

Ctrlx Ctrlx : Alternates the cursor with its old position. (C-x, because x has a crossing shape).

One additional usage of Ctrlx is to expand the * when typing a command in the shell.

Say you have:

$ ls *

Pressing Ctrlx and then * will expand * to all items in the current directory to something like this:

$ ls dir1 dir2 file1 file2 file3`

You can also refer to this topic on SuperUser for the usage I described above.

Tier

Huh?! I've been using bash for many years now but I have never heard of the Ctrl+X asterisk trick before, that's crazy! – Fosse

Answer 4

The terminal assigns special meaning to certain key sequences. This include deleting a character, deleting to the start of line ( CtrlU ), ...

Specifically, when the terminal ISIG local mode is enabled:

• VINTR (usually CtrlC) generates a SIGINT (interrupted by user).
• VQUIT (usually Ctrl\) generates a SIGQUIT (like SIGINT, but also dump core).
• VSUSP (usually CtrlZ) generates a SIGTSTP (stop by terminal I/O).
• VDSUSP (on some systems, not on Linux) generates a SIGTSTP when the program tries to read it.

The above are configurable. This is documented on the termios(3) manpage.

Incised

Answer 5

On Linux/Unix there are signals. The Ctrl+C one (SIGINT) is obvious to me...

If you need a list of signals available on your system, then signum.h can be helpful. Below is from Debian 7.3:

/* Signals.  */
#define SIGHUP      1   /* Hangup (POSIX).  */
#define SIGINT      2   /* Interrupt (ANSI).  */
#define SIGQUIT     3   /* Quit (POSIX).  */
#define SIGILL      4   /* Illegal instruction (ANSI).  */
#define SIGTRAP     5   /* Trace trap (POSIX).  */
#define SIGABRT     6   /* Abort (ANSI).  */
#define SIGIOT      6   /* IOT trap (4.2 BSD).  */
#define SIGBUS      7   /* BUS error (4.2 BSD).  */
#define SIGFPE      8   /* Floating-point exception (ANSI).  */
#define SIGKILL     9   /* Kill, unblockable (POSIX).  */
#define SIGUSR1     10  /* User-defined signal 1 (POSIX).  */
#define SIGSEGV     11  /* Segmentation violation (ANSI).  */
#define SIGUSR2     12  /* User-defined signal 2 (POSIX).  */
#define SIGPIPE     13  /* Broken pipe (POSIX).  */
#define SIGALRM     14  /* Alarm clock (POSIX).  */
#define SIGTERM     15  /* Termination (ANSI).  */
#define SIGSTKFLT   16  /* Stack fault.  */
#define SIGCLD      SIGCHLD /* Same as SIGCHLD (System V).  */
#define SIGCHLD     17  /* Child status has changed (POSIX).  */
#define SIGCONT     18  /* Continue (POSIX).  */
#define SIGSTOP     19  /* Stop, unblockable (POSIX).  */
#define SIGTSTP     20  /* Keyboard stop (POSIX).  */
#define SIGTTIN     21  /* Background read from tty (POSIX).  */
#define SIGTTOU     22  /* Background write to tty (POSIX).  */
#define SIGURG      23  /* Urgent condition on socket (4.2 BSD).  */
#define SIGXCPU     24  /* CPU limit exceeded (4.2 BSD).  */
#define SIGXFSZ     25  /* File size limit exceeded (4.2 BSD).  */
#define SIGVTALRM   26  /* Virtual alarm clock (4.2 BSD).  */
#define SIGPROF     27  /* Profiling alarm clock (4.2 BSD).  */
#define SIGWINCH    28  /* Window size change (4.3 BSD, Sun).  */
#define SIGPOLL     SIGIO   /* Pollable event occurred (System V).  */
#define SIGIO       29  /* I/O now possible (4.2 BSD).  */
#define SIGPWR      30  /* Power failure restart (System V).  */
#define SIGSYS      31  /* Bad system call.  */
#define SIGUNUSED   31

#define _NSIG       65  /* Biggest signal number + 1
                   (including real-time signals).  */

#define SIGRTMIN        (__libc_current_sigrtmin ())
#define SIGRTMAX        (__libc_current_sigrtmax ())

Munition