Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Why doesnt ^Z work on bash?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
dE_logics
Advocate
Advocate


Joined: 02 Jan 2009
Posts: 2253
Location: $TERM

PostPosted: Sun Aug 09, 2015 4:35 pm    Post subject: Why doesnt ^Z work on bash? Reply with quote

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
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10342
Location: Somewhere over Atlanta, Georgia

PostPosted: Tue Aug 11, 2015 11:10 pm    Post subject: Reply with quote

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
View user's profile Send private message
desultory
Administrator
Administrator


Joined: 04 Nov 2005
Posts: 9275

PostPosted: Wed Aug 12, 2015 3:53 am    Post subject: Reply with quote

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
View user's profile Send private message
dE_logics
Advocate
Advocate


Joined: 02 Jan 2009
Posts: 2253
Location: $TERM

PostPosted: Wed Aug 12, 2015 6:20 am    Post subject: Reply with quote

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
View user's profile Send private message
dE_logics
Advocate
Advocate


Joined: 02 Jan 2009
Posts: 2253
Location: $TERM

PostPosted: Wed Aug 12, 2015 6:22 am    Post subject: Reply with quote

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
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10342
Location: Somewhere over Atlanta, Georgia

PostPosted: Wed Aug 12, 2015 1:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
dE_logics
Advocate
Advocate


Joined: 02 Jan 2009
Posts: 2253
Location: $TERM

PostPosted: Wed Aug 12, 2015 1:58 pm    Post subject: Reply with quote

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
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10342
Location: Somewhere over Atlanta, Georgia

PostPosted: Wed Aug 12, 2015 2:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
dE_logics
Advocate
Advocate


Joined: 02 Jan 2009
Posts: 2253
Location: $TERM

PostPosted: Thu Aug 13, 2015 2:39 am    Post subject: Reply with quote

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
View user's profile Send private message
russK
l33t
l33t


Joined: 27 Jun 2006
Posts: 634

PostPosted: Thu Aug 13, 2015 3:02 am    Post subject: Re: Why doesnt ^Z work on bash? Reply with quote

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.

Code:
stty susp "^X"
Back to top
View user's profile Send private message
desultory
Administrator
Administrator


Joined: 04 Nov 2005
Posts: 9275

PostPosted: Thu Aug 13, 2015 3:27 am    Post subject: Reply with quote

dE_logics wrote:
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

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
View user's profile Send private message
dE_logics
Advocate
Advocate


Joined: 02 Jan 2009
Posts: 2253
Location: $TERM

PostPosted: Fri Aug 14, 2015 10:28 am    Post subject: Reply with quote

desultory wrote:
dE_logics wrote:
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

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
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10342
Location: Somewhere over Atlanta, Georgia

PostPosted: Fri Aug 14, 2015 1:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
russK
l33t
l33t


Joined: 27 Jun 2006
Posts: 634

PostPosted: Sat Aug 22, 2015 3:38 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
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