| View previous topic :: View next topic |
| Author |
Message |
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2253
Location: $TERM
|
 Posted: Sun Aug 09, 2015 4:35 pm Post subject: Why doesnt ^Z work on bash? |
 |
|
Characters starting with unprintable ASCII characters are handed by the kernel; so ^Z must also be handled by the kernel; finally stty report it.
So why is it that Linux does not stop the bash process when the pts/tty receives a ^Z?
_________________
My blog |
|
| Back to top |
|
 |
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10393
Location: Somewhere over Atlanta, Georgia
|
| Posted: Tue Aug 11, 2015 11:10 pm Post subject: |
|
|
Without looking at the source code, I'd assume that Bash registers signal handlers for SIGTSTP (the signal raised when you press Ctrl-Z) and SIGINT (the signal raised when you press Ctrl-C), among others. For more background material, Google "Linux Signals".
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
desultory
Administrator
Joined: 04 Nov 2005
Posts: 9291
|
| Posted: Wed Aug 12, 2015 3:53 am Post subject: |
|
|
Confirmed by man 1 bash:
| Quote: | SIGNALS
When bash is interactive, in the absence of any traps, it ignores SIGTERM (so that kill 0 does not kill an interactive shell), and SIGINT is caught and handled (so
that the wait builtin is interruptible). In all cases, bash ignores SIGQUIT. If job control is in effect, bash ignores SIGTTIN, SIGTTOU, and SIGTSTP.
Non-builtin commands run by bash have signal handlers set to the values inherited by the shell from its parent. When job control is not in effect, asynchronous com-
mands ignore SIGINT and SIGQUIT in addition to these inherited handlers. Commands run as a result of command substitution ignore the keyboard-generated job control
signals SIGTTIN, SIGTTOU, and SIGTSTP.
The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent
SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with the
disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.
If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.
If bash is waiting for a command to complete and receives a signal for which a trap has been set, the trap will not be executed until the command completes. When
bash is waiting for an asynchronous command via the wait builtin, the reception of a signal for which a trap has been set will cause the wait builtin to return imme-
diately with an exit status greater than 128, immediately after which the trap is executed.
|
|
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2253
Location: $TERM
|
| Posted: Wed Aug 12, 2015 6:20 am Post subject: |
|
|
| John R. Graham wrote: | Without looking at the source code, I'd assume that Bash registers signal handlers for SIGTSTP (the signal raised when you press Ctrl-Z) and SIGINT (the signal raised when you press Ctrl-C), among others. For more background material, Google "Linux Signals".
- John |
Having asked this question you must have realized very well that I know what are signs, what is a terminal and what is bash and how they work.
Now I just need clarification based on what I understand.
_________________
My blog |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2253
Location: $TERM
|
| Posted: Wed Aug 12, 2015 6:22 am Post subject: |
|
|
| desultory wrote: | Confirmed by man 1 bash:
| Quote: | SIGNALS
When bash is interactive, in the absence of any traps, it ignores SIGTERM (so that kill 0 does not kill an interactive shell), and SIGINT is caught and handled (so
that the wait builtin is interruptible). In all cases, bash ignores SIGQUIT. If job control is in effect, bash ignores SIGTTIN, SIGTTOU, and SIGTSTP.
Non-builtin commands run by bash have signal handlers set to the values inherited by the shell from its parent. When job control is not in effect, asynchronous com-
mands ignore SIGINT and SIGQUIT in addition to these inherited handlers. Commands run as a result of command substitution ignore the keyboard-generated job control
signals SIGTTIN, SIGTTOU, and SIGTSTP.
The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent
SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with the
disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.
If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.
If bash is waiting for a command to complete and receives a signal for which a trap has been set, the trap will not be executed until the command completes. When
bash is waiting for an asynchronous command via the wait builtin, the reception of a signal for which a trap has been set will cause the wait builtin to return imme-
diately with an exit status greater than 128, immediately after which the trap is executed.
|
|
SIGSTOP Is not mentioned here. Besides it can't be handled. That's the reason why I didn't bother with bash.
Thanks for any response in this un-explored topic.
_________________
My blog |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10393
Location: Somewhere over Atlanta, Georgia
|
| Posted: Wed Aug 12, 2015 1:40 pm Post subject: |
|
|
| dE_logics wrote: | | Having asked this question you must have realized very well that I know what are signs, what is a terminal and what is bash and how they work. |
Sorry; no slight intended. However, from the way you phrased your question, it wasn't obvious to me that you knew those things.
So what is it you don't understand?
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2253
Location: $TERM
|
| Posted: Wed Aug 12, 2015 1:58 pm Post subject: |
|
|
| John R. Graham wrote: | | dE_logics wrote: | | Having asked this question you must have realized very well that I know what are signs, what is a terminal and what is bash and how they work. |
Sorry; no slight intended. However, from the way you phrased your question, it wasn't obvious to me that you knew those things.
So what is it you don't understand?
- John |
Thanks for the interest.
Since sending signals based on character/character sequence encountered on the (p)tty is the job of the kernel, why doesn't it stop bash when it encounters ctrl+z?
_________________
My blog |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10393
Location: Somewhere over Atlanta, Georgia
|
| Posted: Wed Aug 12, 2015 2:02 pm Post subject: |
|
|
A registered signal handler can handle a signal by "doing nothing". Bash registers such a "do nothing" signal handler for SIGTSTP. All of the behavior you normally see when you press Ctrl-Z within an app is from the default SIGTSTP signal handler, which does not "do nothing". So Bash does receive the SIGTSTP signal, but you don't notice because the "do nothing" signal handler effectively causes the signal to be ignored.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2253
Location: $TERM
|
| Posted: Thu Aug 13, 2015 2:39 am Post subject: |
|
|
| dE_logics wrote: | | desultory wrote: | Confirmed by man 1 bash:
| Quote: | SIGNALS
When bash is interactive, in the absence of any traps, it ignores SIGTERM (so that kill 0 does not kill an interactive shell), and SIGINT is caught and handled (so
that the wait builtin is interruptible). In all cases, bash ignores SIGQUIT. If job control is in effect, bash ignores SIGTTIN, SIGTTOU, and SIGTSTP.
Non-builtin commands run by bash have signal handlers set to the values inherited by the shell from its parent. When job control is not in effect, asynchronous com-
mands ignore SIGINT and SIGQUIT in addition to these inherited handlers. Commands run as a result of command substitution ignore the keyboard-generated job control
signals SIGTTIN, SIGTTOU, and SIGTSTP.
The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent
SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with the
disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.
If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.
If bash is waiting for a command to complete and receives a signal for which a trap has been set, the trap will not be executed until the command completes. When
bash is waiting for an asynchronous command via the wait builtin, the reception of a signal for which a trap has been set will cause the wait builtin to return imme-
diately with an exit status greater than 128, immediately after which the trap is executed.
|
|
SIGSTOP Is not mentioned here. Besides it can't be handled. That's the reason why I didn't bother with bash.
Thanks for any response in this un-explored topic. |
| Quote: | | The SIGSTOP signal stops the process. It cannot be handled, ignored, or blocked. |
http://www.gnu.org/s/libc/manual/html_node/Job-Control-Signals.html
_________________
My blog |
|
| Back to top |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 634
|
| Posted: Thu Aug 13, 2015 3:02 am Post subject: Re: Why doesnt ^Z work on bash? |
|
|
| dE_logics wrote: | Characters starting with unprintable ASCII characters are handed by the kernel; so ^Z must also be handled by the kernel; finally stty report it.
So why is it that Linux does not stop the bash process when the pts/tty receives a ^Z? |
By the way, don't confuse ^Z with the STOP signal itself. There is really nothing that connects the ^Z to the STOP signal other than convention. As you know, bash, like many other shells, allows you to have multiple "jobs" either in the foreground or the background. Also bash provides job control commands I am sure you have read about.
Also, I don't believe the kernel necessarily handles the ^Z per se other than providing for the I/O. I would suggest the ^Z is really handled by bash and the terminal, and when it sees the ^Z, it will send a STOP signal a foreground process. Note, the ^Z is typically the suspend character, but you can change it with 'stty'.
Here, literally use the caret "^" and capital "X" together. This will change your suspend character from ^Z to ^X for your current shell.
|
|
| Back to top |
|
|
desultory
Administrator
Joined: 04 Nov 2005
Posts: 9291
|
| Posted: Thu Aug 13, 2015 3:27 am Post subject: |
|
|
You might want to review the very next entry on that same page, especially the final paragraph thereof:
| Quote: | Macro: int SIGTSTP
The SIGTSTP signal is an interactive stop signal. Unlike SIGSTOP, this signal can be handled and ignored.
Your program should handle this signal if you have a special need to leave files or system tables in a secure state when a process is stopped. For example, programs that turn off echoing should handle SIGTSTP so they can turn echoing back on before stopping.
This signal is generated when the user types the SUSP character (normally C-z). For more information about terminal driver support, see Special Characters.
|
|
|
| Back to top |
|
|
dE_logics
Advocate
Joined: 02 Jan 2009
Posts: 2253
Location: $TERM
|
| Posted: Fri Aug 14, 2015 10:28 am Post subject: |
|
|
| desultory wrote: |
You might want to review the very next entry on that same page, especially the final paragraph thereof:
| Quote: | Macro: int SIGTSTP
The SIGTSTP signal is an interactive stop signal. Unlike SIGSTOP, this signal can be handled and ignored.
Your program should handle this signal if you have a special need to leave files or system tables in a secure state when a process is stopped. For example, programs that turn off echoing should handle SIGTSTP so they can turn echoing back on before stopping.
This signal is generated when the user types the SUSP character (normally C-z). For more information about terminal driver support, see Special Characters.
|
|
Got it. Thanks a lot everyone.
So the kernel sends SIGSTP instead of SIGSTOP.
_________________
My blog |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10393
Location: Somewhere over Atlanta, Georgia
|
| Posted: Fri Aug 14, 2015 1:30 pm Post subject: |
|
|
Yes, but you have a small typo above. It's SIGTSTP that's raised when you type Ctrl-Z. 
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 634
|
| Posted: Sat Aug 22, 2015 3:38 pm Post subject: |
|
|
| By the way, if you are using bash and you have a process running in the foreground, ^Z will stop the process, but it's bash that sends the SIGSTP, not the kernel. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
