Mixing
When is a signal handled and why does some info freeze up?
Open a terminal named "termA", and run the created file
callback.shwith/bin/bash callback.sh.
cat callback.sh
#!/bin/bash
myCallback() {
echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
sleep 20
Open a new terminal named "termB" and run:
pkill -USR1 -f callback.sh
Something as below is shown after 20 seconds in termA; it's never shown in termA instantly:
callback function called at Mon Nov 19 08:21:52 HKT 2018
The conclusion verified that when Bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates (see signal trap).
Make a little change in callback.sh:
cat callback.sh
#!/bin/bash
myCallback() {
echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
while true; do
read -p "please input something for foo: " foo
done
Add an infinite while loop and remove sleep 20.
Open a terminal named "termA" and run the created file
callback.shwith/bin/bash callback.sh; the first time, the info pops up instantly.
please input something for foo:
Open a new terminal named "termB" and run
pkill -USR1 -f callback.sh; the first time, the info pops up instantly in termA.
callback function called at Mon Nov 19 09:07:14 HKT 2018
Issue 1: callback.sh contains an infinite while loop. How does that explain the following?
it does not handle any signals received until the foreground process terminates
In this case, the foreground process never terminates.
Go on in termB, run pkill -USR1 -f callback.sh for the second time.
callback function called at Mon Nov 19 09:07:14 HKT 2018
The info above pops up instantly in termA again.
Issue 2: No please input something for foo: shown in termA,
go to termB, run pkill -USR1 -f callback.sh for the third time,
the following info is shown in termA again.
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no please input something for foo: is shown in termA.
Why does the info please input something for foo: freeze up?
linux bash trap
edited Dec 4 '18 at 20:46
codeforester
17.8k84164
asked Nov 19 '18 at 1:20
scrapyscrapy
173219
add a comment |
Open a terminal named "termA", and run the created file
callback.shwith/bin/bash callback.sh.
cat callback.sh
#!/bin/bash
myCallback() {
echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
sleep 20
Open a new terminal named "termB" and run:
pkill -USR1 -f callback.sh
Something as below is shown after 20 seconds in termA; it's never shown in termA instantly:
callback function called at Mon Nov 19 08:21:52 HKT 2018
The conclusion verified that when Bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates (see signal trap).
Make a little change in callback.sh:
cat callback.sh
#!/bin/bash
myCallback() {
echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
while true; do
read -p "please input something for foo: " foo
done
Add an infinite while loop and remove sleep 20.
Open a terminal named "termA" and run the created file
callback.shwith/bin/bash callback.sh; the first time, the info pops up instantly.
please input something for foo:
Open a new terminal named "termB" and run
pkill -USR1 -f callback.sh; the first time, the info pops up instantly in termA.
callback function called at Mon Nov 19 09:07:14 HKT 2018
Issue 1: callback.sh contains an infinite while loop. How does that explain the following?
it does not handle any signals received until the foreground process terminates
In this case, the foreground process never terminates.
Go on in termB, run pkill -USR1 -f callback.sh for the second time.
callback function called at Mon Nov 19 09:07:14 HKT 2018
The info above pops up instantly in termA again.
Issue 2: No please input something for foo: shown in termA,
go to termB, run pkill -USR1 -f callback.sh for the third time,
the following info is shown in termA again.
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no please input something for foo: is shown in termA.
Why does the info please input something for foo: freeze up?
linux bash trap
edited Dec 4 '18 at 20:46
codeforester
17.8k84164
asked Nov 19 '18 at 1:20
scrapyscrapy
173219
Note it is bad practice to name scripts ending with a.sh. It makes the caller dependant on the implementation language ( a rewrite, will affect all callers). And you don't need to run with/bin/bash(just make the script executable), that is what the#!…is for.
– ctrl-alt-delor
Nov 27 '18 at 18:49
Read also signal(7) and signal-safety(7)
– Basile Starynkevitch
Dec 4 '18 at 20:51
add a comment |
Open a terminal named "termA", and run the created file
callback.shwith/bin/bash callback.sh.
cat callback.sh
#!/bin/bash
myCallback() {
echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
sleep 20
Open a new terminal named "termB" and run:
pkill -USR1 -f callback.sh
Something as below is shown after 20 seconds in termA; it's never shown in termA instantly:
callback function called at Mon Nov 19 08:21:52 HKT 2018
The conclusion verified that when Bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates (see signal trap).
Make a little change in callback.sh:
cat callback.sh
#!/bin/bash
myCallback() {
echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
while true; do
read -p "please input something for foo: " foo
done
Add an infinite while loop and remove sleep 20.
Open a terminal named "termA" and run the created file
callback.shwith/bin/bash callback.sh; the first time, the info pops up instantly.
please input something for foo:
Open a new terminal named "termB" and run
pkill -USR1 -f callback.sh; the first time, the info pops up instantly in termA.
callback function called at Mon Nov 19 09:07:14 HKT 2018
Issue 1: callback.sh contains an infinite while loop. How does that explain the following?
it does not handle any signals received until the foreground process terminates
In this case, the foreground process never terminates.
Go on in termB, run pkill -USR1 -f callback.sh for the second time.
callback function called at Mon Nov 19 09:07:14 HKT 2018
The info above pops up instantly in termA again.
Issue 2: No please input something for foo: shown in termA,
go to termB, run pkill -USR1 -f callback.sh for the third time,
the following info is shown in termA again.
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no please input something for foo: is shown in termA.
Why does the info please input something for foo: freeze up?
linux bash trap
edited Dec 4 '18 at 20:46
codeforester
17.8k84164
asked Nov 19 '18 at 1:20
scrapyscrapy
173219
Open a terminal named "termA", and run the created file
callback.shwith/bin/bash callback.sh.
cat callback.sh
#!/bin/bash
myCallback() {
echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
sleep 20
Open a new terminal named "termB" and run:
pkill -USR1 -f callback.sh
Something as below is shown after 20 seconds in termA; it's never shown in termA instantly:
callback function called at Mon Nov 19 08:21:52 HKT 2018
The conclusion verified that when Bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates (see signal trap).
Make a little change in callback.sh:
cat callback.sh
#!/bin/bash
myCallback() {
echo "callback function called at $(date)"
}
trap myCallback SIGUSR1
while true; do
read -p "please input something for foo: " foo
done
Add an infinite while loop and remove sleep 20.
Open a terminal named "termA" and run the created file
callback.shwith/bin/bash callback.sh; the first time, the info pops up instantly.
please input something for foo:
Open a new terminal named "termB" and run
pkill -USR1 -f callback.sh; the first time, the info pops up instantly in termA.
callback function called at Mon Nov 19 09:07:14 HKT 2018
Issue 1: callback.sh contains an infinite while loop. How does that explain the following?
it does not handle any signals received until the foreground process terminates
In this case, the foreground process never terminates.
Go on in termB, run pkill -USR1 -f callback.sh for the second time.
callback function called at Mon Nov 19 09:07:14 HKT 2018
The info above pops up instantly in termA again.
Issue 2: No please input something for foo: shown in termA,
go to termB, run pkill -USR1 -f callback.sh for the third time,
the following info is shown in termA again.
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no please input something for foo: is shown in termA.
Why does the info please input something for foo: freeze up?
linux bash trap
linux bash trap
edited Dec 4 '18 at 20:46
codeforester
17.8k84164
asked Nov 19 '18 at 1:20
scrapyscrapy
173219
edited Dec 4 '18 at 20:46
codeforester
17.8k84164
asked Nov 19 '18 at 1:20
scrapyscrapy
173219
edited Dec 4 '18 at 20:46
codeforester
17.8k84164
edited Dec 4 '18 at 20:46
codeforester
17.8k84164
edited Dec 4 '18 at 20:46
codeforester
17.8k84164
17.8k84164
asked Nov 19 '18 at 1:20
scrapyscrapy
173219
asked Nov 19 '18 at 1:20
scrapyscrapy
173219
asked Nov 19 '18 at 1:20
scrapyscrapy
173219
173219
Note it is bad practice to name scripts ending with a.sh. It makes the caller dependant on the implementation language ( a rewrite, will affect all callers). And you don't need to run with/bin/bash(just make the script executable), that is what the#!…is for.
– ctrl-alt-delor
Nov 27 '18 at 18:49
Read also signal(7) and signal-safety(7)
– Basile Starynkevitch
Dec 4 '18 at 20:51
add a comment |
Note it is bad practice to name scripts ending with a.sh. It makes the caller dependant on the implementation language ( a rewrite, will affect all callers). And you don't need to run with/bin/bash(just make the script executable), that is what the#!…is for.
– ctrl-alt-delor
Nov 27 '18 at 18:49
Read also signal(7) and signal-safety(7)
– Basile Starynkevitch
Dec 4 '18 at 20:51
Note it is bad practice to name scripts ending with a
.sh. It makes the caller dependant on the implementation language ( a rewrite, will affect all callers). And you don't need to run with /bin/bash (just make the script executable), that is what the #!… is for.– ctrl-alt-delor
Nov 27 '18 at 18:49
Note it is bad practice to name scripts ending with a
.sh. It makes the caller dependant on the implementation language ( a rewrite, will affect all callers). And you don't need to run with /bin/bash (just make the script executable), that is what the #!… is for.– ctrl-alt-delor
Nov 27 '18 at 18:49
Read also signal(7) and signal-safety(7)
– Basile Starynkevitch
Dec 4 '18 at 20:51
Read also signal(7) and signal-safety(7)
– Basile Starynkevitch
Dec 4 '18 at 20:51
add a comment |
3 Answers
3
active
oldest
votes
Before explaining out your problem, a bit of context on how read command works. It reads in input data from stdin until EOF is encountered. It is safe to say the call to read command is non-blocking when it comes to reading from on-disk files. But when stdin is connected to the terminal, the command will block until the user types something.
How signal handlers work?
A simple explanation on how signal handling works. See the below snippet in C which just acts on SIGINT ( aka. CTRL+C)
#include <stdio.h>
#include <signal.h>
/* signal handler definition */
void signal_handler(int signum){
printf("Hello World!n");
}
int main(){
//Handle SIGINT with a signal handler
signal(SIGINT, signal_handler);
//loop forever!
while(1);
}
It will register the signal handler and then will enter the infinite loop. When we hit Ctrl-C, we can all agree that the signal handler signal_handler() should execute and "Hello World!" prints to the screen, but the program was in an infinite loop. In order to print "Hello World!" it must have been the case that it broke the loop to execute the signal handler, right? So it should exit the loop as well as the program. Let's see:
gcc -Wall -o sighdl.o signal.c
./sighdl.o
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
As the output indicates, every time we issued Ctrl-C, "Hello World!" prints, but the program returns to the infinite loop. It is only after issuing a SIGQUIT signal with Ctrl- did the program actually exit. Depending on your ulimit settings, it would dump a core or print out the signal number received.
While the interpretation that the loop would exit is reasonable, it doesn't consider the primary reason for signal handling, that is, asynchronous event handling. That means the signal handler acts out of the standard flow of the control of the program; in fact, the whole program is saved within a context, and a new context is created just for the signal handler to execute in. Once the signal handler has completed its actions, the context is switched back and the normal execution flow starts (i.e. the while(1)).
To answer your questions,
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates
The key thing to note here is the external command part. In the first case, where sleep is an external process but in the second case, read is a built-in from the shell itself. So the propagation of the signal to these two differs in both these cases
type read
read is a shell builtin
type sleep
sleep is /usr/bin/sleep
1.Open a terminal,named termA ,and run the created file callback.sh with /bin/bash callback.sh for first time,the info pop up instantly.
Yes, this behavior is expected. Because at this time only the function is defined and the trap handler is registered to the function myCallback and the signal is not yet received in the script. As the execution sequence goes, the message from the read prompt is thrown for the first time.
2.Open a new terminal ,named termB and run
pkill -USR1 -f callback.shfirst time,the info pop up instantly in termA
Yes, while the read command is waiting for string followed by the Enter key pres which signals the EOF, it receives a signal SIGUSR1 from the other terminal, the current execution context is saved and the control is switched the signal handler which prints the string with the current date.
As soon as the handler finishes executing, the context resumes to the while loop in which the read command is still waiting for an input string. Until the read command is successful, all subsequent signal traps would just print the string inside the signal handler.
Go on in termB,run
pkill -USR1 -f callback.shthe second time.
Same as explained previously, the read command is not complete for once in your while loop, only if it is successful reading a string, the next iteration of the loop would start and a new prompt message would be thrown.
Image source: The Linux Programming Interface by Michael KerrisK
answered Nov 21 '18 at 10:53
InianInian
39.4k63971
1
I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler, which means your program has undefined behaviour. So we can't all agree that"Hello World!"will be printed, or that you'll remain untormented by those infamous nasal demons...
– Toby Speight
Nov 21 '18 at 11:43
@TobySpeight I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler There's no doubt about it - strictly speaking,printf()can't be called from a signal handler. Per the C standard: "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration." Footnote 188 adds: "Thus, a signal handler cannot, in general, call standard library functions."
– Andrew Henle
Nov 21 '18 at 12:30
@TobySpeight (cont) POSIX, however, specifies a list of functions that can be called from a signal handler: "The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions." Note thatprintf()is not on that list. (Note thatfork()is on that list, butfork()is broken on Linux)
– Andrew Henle
Nov 21 '18 at 12:35
add a comment |
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates.
bash does handle the signals at C / implementation level, but will not run the handlers set with trap until the foreground process has terminated. That's required by the standard:
When a signal for which a trap has been set is received while the shell
is waiting for the completion of a utility executing a foreground
command, the trap associated with that signal shall not be executed
until after the foreground command has completed.
Notice that the standard makes no difference between builtins and external commands; in the case of a "utility" like read, which is not executed in a separate process, it's not obvious whether a signal occurs in its "context" or in that of the main shell, and whether a handler set with trap should be run before or after the read returns.
issue 1:callback.sh contains a infinite while loop,how to explain it does not handle any signals received until the foreground process terminates.,in this case the foreground process never terminates.
That's wrong. bash is not executing the while loop in a separate process. Since there's no foreground process bash is waiting on, it can run any handler set with trap immediately. If read were an external command, that and not while would be the foreground process.
issue2: No
please input something for foo: shownin termA;
go to termB, run
pkill -USR1 -f callback.shthe third time.
The following info shown in termA again:
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no
please input something for foo:shown in termA.
Why the infoplease input something for foo:freeze up?
It doesn't freeze up. Just press Enter and it will show up again.
It's simply that
a) bash will restart the read builtin in place when interrupted by a signal -- it won't return and go again through the while loop
b) it will not re-display the prompt set with -p in that case.
Notice that bash won't even show the prompt again in the case where a SIGINT from the keyboard was handled, even if it does discard the string read so far from the user:
$ cat goo
trap 'echo INT' INT
echo $$
read -p 'enter something: ' var
echo "you entered '$var'"
$ bash goo
24035
enter something: foo<Ctrl-C>^CINT
<Ctrl-C>^CINT
<Ctrl-C>^CINT
bar<Enter>
you entered 'bar'
That will print you entered 'foobar' if the signal was sent from another window with kill -INT <pid> instead of with Ctrl-C from the terminal.
All the stuff in this last part (how read is interrupted, etc) is very bash specific. In other shells like ksh or dash, and even in bash when run in POSIX mode (bash --posix), any handled signal will actually interrupt the read builtin. In the example above, the shell will print you entered '' and exit after the first ^C, and if the read is called from a loop, the loop will be restarted.
answered Nov 22 '18 at 6:09
mosvymosvy
53914
add a comment |
termA does not freeze up. It is just displaying the callback in the input box. Simply push the Enter key to continue with the input.
answered Nov 21 '18 at 2:47
RotsRots
4,74323346
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53367146%2fwhen-is-a-signal-handled-and-why-does-some-info-freeze-up%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Before explaining out your problem, a bit of context on how read command works. It reads in input data from stdin until EOF is encountered. It is safe to say the call to read command is non-blocking when it comes to reading from on-disk files. But when stdin is connected to the terminal, the command will block until the user types something.
How signal handlers work?
A simple explanation on how signal handling works. See the below snippet in C which just acts on SIGINT ( aka. CTRL+C)
#include <stdio.h>
#include <signal.h>
/* signal handler definition */
void signal_handler(int signum){
printf("Hello World!n");
}
int main(){
//Handle SIGINT with a signal handler
signal(SIGINT, signal_handler);
//loop forever!
while(1);
}
It will register the signal handler and then will enter the infinite loop. When we hit Ctrl-C, we can all agree that the signal handler signal_handler() should execute and "Hello World!" prints to the screen, but the program was in an infinite loop. In order to print "Hello World!" it must have been the case that it broke the loop to execute the signal handler, right? So it should exit the loop as well as the program. Let's see:
gcc -Wall -o sighdl.o signal.c
./sighdl.o
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
As the output indicates, every time we issued Ctrl-C, "Hello World!" prints, but the program returns to the infinite loop. It is only after issuing a SIGQUIT signal with Ctrl- did the program actually exit. Depending on your ulimit settings, it would dump a core or print out the signal number received.
While the interpretation that the loop would exit is reasonable, it doesn't consider the primary reason for signal handling, that is, asynchronous event handling. That means the signal handler acts out of the standard flow of the control of the program; in fact, the whole program is saved within a context, and a new context is created just for the signal handler to execute in. Once the signal handler has completed its actions, the context is switched back and the normal execution flow starts (i.e. the while(1)).
To answer your questions,
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates
The key thing to note here is the external command part. In the first case, where sleep is an external process but in the second case, read is a built-in from the shell itself. So the propagation of the signal to these two differs in both these cases
type read
read is a shell builtin
type sleep
sleep is /usr/bin/sleep
1.Open a terminal,named termA ,and run the created file callback.sh with /bin/bash callback.sh for first time,the info pop up instantly.
Yes, this behavior is expected. Because at this time only the function is defined and the trap handler is registered to the function myCallback and the signal is not yet received in the script. As the execution sequence goes, the message from the read prompt is thrown for the first time.
2.Open a new terminal ,named termB and run
pkill -USR1 -f callback.shfirst time,the info pop up instantly in termA
Yes, while the read command is waiting for string followed by the Enter key pres which signals the EOF, it receives a signal SIGUSR1 from the other terminal, the current execution context is saved and the control is switched the signal handler which prints the string with the current date.
As soon as the handler finishes executing, the context resumes to the while loop in which the read command is still waiting for an input string. Until the read command is successful, all subsequent signal traps would just print the string inside the signal handler.
Go on in termB,run
pkill -USR1 -f callback.shthe second time.
Same as explained previously, the read command is not complete for once in your while loop, only if it is successful reading a string, the next iteration of the loop would start and a new prompt message would be thrown.
Image source: The Linux Programming Interface by Michael KerrisK
answered Nov 21 '18 at 10:53
InianInian
39.4k63971
1
I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler, which means your program has undefined behaviour. So we can't all agree that"Hello World!"will be printed, or that you'll remain untormented by those infamous nasal demons...
– Toby Speight
Nov 21 '18 at 11:43
@TobySpeight I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler There's no doubt about it - strictly speaking,printf()can't be called from a signal handler. Per the C standard: "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration." Footnote 188 adds: "Thus, a signal handler cannot, in general, call standard library functions."
– Andrew Henle
Nov 21 '18 at 12:30
@TobySpeight (cont) POSIX, however, specifies a list of functions that can be called from a signal handler: "The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions." Note thatprintf()is not on that list. (Note thatfork()is on that list, butfork()is broken on Linux)
– Andrew Henle
Nov 21 '18 at 12:35
add a comment |
Before explaining out your problem, a bit of context on how read command works. It reads in input data from stdin until EOF is encountered. It is safe to say the call to read command is non-blocking when it comes to reading from on-disk files. But when stdin is connected to the terminal, the command will block until the user types something.
How signal handlers work?
A simple explanation on how signal handling works. See the below snippet in C which just acts on SIGINT ( aka. CTRL+C)
#include <stdio.h>
#include <signal.h>
/* signal handler definition */
void signal_handler(int signum){
printf("Hello World!n");
}
int main(){
//Handle SIGINT with a signal handler
signal(SIGINT, signal_handler);
//loop forever!
while(1);
}
It will register the signal handler and then will enter the infinite loop. When we hit Ctrl-C, we can all agree that the signal handler signal_handler() should execute and "Hello World!" prints to the screen, but the program was in an infinite loop. In order to print "Hello World!" it must have been the case that it broke the loop to execute the signal handler, right? So it should exit the loop as well as the program. Let's see:
gcc -Wall -o sighdl.o signal.c
./sighdl.o
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
As the output indicates, every time we issued Ctrl-C, "Hello World!" prints, but the program returns to the infinite loop. It is only after issuing a SIGQUIT signal with Ctrl- did the program actually exit. Depending on your ulimit settings, it would dump a core or print out the signal number received.
While the interpretation that the loop would exit is reasonable, it doesn't consider the primary reason for signal handling, that is, asynchronous event handling. That means the signal handler acts out of the standard flow of the control of the program; in fact, the whole program is saved within a context, and a new context is created just for the signal handler to execute in. Once the signal handler has completed its actions, the context is switched back and the normal execution flow starts (i.e. the while(1)).
To answer your questions,
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates
The key thing to note here is the external command part. In the first case, where sleep is an external process but in the second case, read is a built-in from the shell itself. So the propagation of the signal to these two differs in both these cases
type read
read is a shell builtin
type sleep
sleep is /usr/bin/sleep
1.Open a terminal,named termA ,and run the created file callback.sh with /bin/bash callback.sh for first time,the info pop up instantly.
Yes, this behavior is expected. Because at this time only the function is defined and the trap handler is registered to the function myCallback and the signal is not yet received in the script. As the execution sequence goes, the message from the read prompt is thrown for the first time.
2.Open a new terminal ,named termB and run
pkill -USR1 -f callback.shfirst time,the info pop up instantly in termA
Yes, while the read command is waiting for string followed by the Enter key pres which signals the EOF, it receives a signal SIGUSR1 from the other terminal, the current execution context is saved and the control is switched the signal handler which prints the string with the current date.
As soon as the handler finishes executing, the context resumes to the while loop in which the read command is still waiting for an input string. Until the read command is successful, all subsequent signal traps would just print the string inside the signal handler.
Go on in termB,run
pkill -USR1 -f callback.shthe second time.
Same as explained previously, the read command is not complete for once in your while loop, only if it is successful reading a string, the next iteration of the loop would start and a new prompt message would be thrown.
Image source: The Linux Programming Interface by Michael KerrisK
answered Nov 21 '18 at 10:53
InianInian
39.4k63971
1
I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler, which means your program has undefined behaviour. So we can't all agree that"Hello World!"will be printed, or that you'll remain untormented by those infamous nasal demons...
– Toby Speight
Nov 21 '18 at 11:43
@TobySpeight I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler There's no doubt about it - strictly speaking,printf()can't be called from a signal handler. Per the C standard: "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration." Footnote 188 adds: "Thus, a signal handler cannot, in general, call standard library functions."
– Andrew Henle
Nov 21 '18 at 12:30
@TobySpeight (cont) POSIX, however, specifies a list of functions that can be called from a signal handler: "The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions." Note thatprintf()is not on that list. (Note thatfork()is on that list, butfork()is broken on Linux)
– Andrew Henle
Nov 21 '18 at 12:35
add a comment |
Before explaining out your problem, a bit of context on how read command works. It reads in input data from stdin until EOF is encountered. It is safe to say the call to read command is non-blocking when it comes to reading from on-disk files. But when stdin is connected to the terminal, the command will block until the user types something.
How signal handlers work?
A simple explanation on how signal handling works. See the below snippet in C which just acts on SIGINT ( aka. CTRL+C)
#include <stdio.h>
#include <signal.h>
/* signal handler definition */
void signal_handler(int signum){
printf("Hello World!n");
}
int main(){
//Handle SIGINT with a signal handler
signal(SIGINT, signal_handler);
//loop forever!
while(1);
}
It will register the signal handler and then will enter the infinite loop. When we hit Ctrl-C, we can all agree that the signal handler signal_handler() should execute and "Hello World!" prints to the screen, but the program was in an infinite loop. In order to print "Hello World!" it must have been the case that it broke the loop to execute the signal handler, right? So it should exit the loop as well as the program. Let's see:
gcc -Wall -o sighdl.o signal.c
./sighdl.o
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
As the output indicates, every time we issued Ctrl-C, "Hello World!" prints, but the program returns to the infinite loop. It is only after issuing a SIGQUIT signal with Ctrl- did the program actually exit. Depending on your ulimit settings, it would dump a core or print out the signal number received.
While the interpretation that the loop would exit is reasonable, it doesn't consider the primary reason for signal handling, that is, asynchronous event handling. That means the signal handler acts out of the standard flow of the control of the program; in fact, the whole program is saved within a context, and a new context is created just for the signal handler to execute in. Once the signal handler has completed its actions, the context is switched back and the normal execution flow starts (i.e. the while(1)).
To answer your questions,
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates
The key thing to note here is the external command part. In the first case, where sleep is an external process but in the second case, read is a built-in from the shell itself. So the propagation of the signal to these two differs in both these cases
type read
read is a shell builtin
type sleep
sleep is /usr/bin/sleep
1.Open a terminal,named termA ,and run the created file callback.sh with /bin/bash callback.sh for first time,the info pop up instantly.
Yes, this behavior is expected. Because at this time only the function is defined and the trap handler is registered to the function myCallback and the signal is not yet received in the script. As the execution sequence goes, the message from the read prompt is thrown for the first time.
2.Open a new terminal ,named termB and run
pkill -USR1 -f callback.shfirst time,the info pop up instantly in termA
Yes, while the read command is waiting for string followed by the Enter key pres which signals the EOF, it receives a signal SIGUSR1 from the other terminal, the current execution context is saved and the control is switched the signal handler which prints the string with the current date.
As soon as the handler finishes executing, the context resumes to the while loop in which the read command is still waiting for an input string. Until the read command is successful, all subsequent signal traps would just print the string inside the signal handler.
Go on in termB,run
pkill -USR1 -f callback.shthe second time.
Same as explained previously, the read command is not complete for once in your while loop, only if it is successful reading a string, the next iteration of the loop would start and a new prompt message would be thrown.
Image source: The Linux Programming Interface by Michael KerrisK
answered Nov 21 '18 at 10:53
InianInian
39.4k63971
Before explaining out your problem, a bit of context on how read command works. It reads in input data from stdin until EOF is encountered. It is safe to say the call to read command is non-blocking when it comes to reading from on-disk files. But when stdin is connected to the terminal, the command will block until the user types something.
How signal handlers work?
A simple explanation on how signal handling works. See the below snippet in C which just acts on SIGINT ( aka. CTRL+C)
#include <stdio.h>
#include <signal.h>
/* signal handler definition */
void signal_handler(int signum){
printf("Hello World!n");
}
int main(){
//Handle SIGINT with a signal handler
signal(SIGINT, signal_handler);
//loop forever!
while(1);
}
It will register the signal handler and then will enter the infinite loop. When we hit Ctrl-C, we can all agree that the signal handler signal_handler() should execute and "Hello World!" prints to the screen, but the program was in an infinite loop. In order to print "Hello World!" it must have been the case that it broke the loop to execute the signal handler, right? So it should exit the loop as well as the program. Let's see:
gcc -Wall -o sighdl.o signal.c
./sighdl.o
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
As the output indicates, every time we issued Ctrl-C, "Hello World!" prints, but the program returns to the infinite loop. It is only after issuing a SIGQUIT signal with Ctrl- did the program actually exit. Depending on your ulimit settings, it would dump a core or print out the signal number received.
While the interpretation that the loop would exit is reasonable, it doesn't consider the primary reason for signal handling, that is, asynchronous event handling. That means the signal handler acts out of the standard flow of the control of the program; in fact, the whole program is saved within a context, and a new context is created just for the signal handler to execute in. Once the signal handler has completed its actions, the context is switched back and the normal execution flow starts (i.e. the while(1)).
To answer your questions,
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates
The key thing to note here is the external command part. In the first case, where sleep is an external process but in the second case, read is a built-in from the shell itself. So the propagation of the signal to these two differs in both these cases
type read
read is a shell builtin
type sleep
sleep is /usr/bin/sleep
1.Open a terminal,named termA ,and run the created file callback.sh with /bin/bash callback.sh for first time,the info pop up instantly.
Yes, this behavior is expected. Because at this time only the function is defined and the trap handler is registered to the function myCallback and the signal is not yet received in the script. As the execution sequence goes, the message from the read prompt is thrown for the first time.
2.Open a new terminal ,named termB and run
pkill -USR1 -f callback.shfirst time,the info pop up instantly in termA
Yes, while the read command is waiting for string followed by the Enter key pres which signals the EOF, it receives a signal SIGUSR1 from the other terminal, the current execution context is saved and the control is switched the signal handler which prints the string with the current date.
As soon as the handler finishes executing, the context resumes to the while loop in which the read command is still waiting for an input string. Until the read command is successful, all subsequent signal traps would just print the string inside the signal handler.
Go on in termB,run
pkill -USR1 -f callback.shthe second time.
Same as explained previously, the read command is not complete for once in your while loop, only if it is successful reading a string, the next iteration of the loop would start and a new prompt message would be thrown.
Image source: The Linux Programming Interface by Michael KerrisK
answered Nov 21 '18 at 10:53
InianInian
39.4k63971
edited Nov 23 '18 at 8:27
answered Nov 21 '18 at 10:53
InianInian
39.4k63971
answered Nov 21 '18 at 10:53
InianInian
39.4k63971
answered Nov 21 '18 at 10:53
InianInian
39.4k63971
39.4k63971
1
I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler, which means your program has undefined behaviour. So we can't all agree that"Hello World!"will be printed, or that you'll remain untormented by those infamous nasal demons...
– Toby Speight
Nov 21 '18 at 11:43
@TobySpeight I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler There's no doubt about it - strictly speaking,printf()can't be called from a signal handler. Per the C standard: "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration." Footnote 188 adds: "Thus, a signal handler cannot, in general, call standard library functions."
– Andrew Henle
Nov 21 '18 at 12:30
@TobySpeight (cont) POSIX, however, specifies a list of functions that can be called from a signal handler: "The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions." Note thatprintf()is not on that list. (Note thatfork()is on that list, butfork()is broken on Linux)
– Andrew Henle
Nov 21 '18 at 12:35
add a comment |
1
I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler, which means your program has undefined behaviour. So we can't all agree that"Hello World!"will be printed, or that you'll remain untormented by those infamous nasal demons...
– Toby Speight
Nov 21 '18 at 11:43
@TobySpeight I'm pretty sureprintf()isn't one of the functions that can be safely called in a signal handler There's no doubt about it - strictly speaking,printf()can't be called from a signal handler. Per the C standard: "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration." Footnote 188 adds: "Thus, a signal handler cannot, in general, call standard library functions."
– Andrew Henle
Nov 21 '18 at 12:30
@TobySpeight (cont) POSIX, however, specifies a list of functions that can be called from a signal handler: "The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions." Note thatprintf()is not on that list. (Note thatfork()is on that list, butfork()is broken on Linux)
– Andrew Henle
Nov 21 '18 at 12:35
1
1
I'm pretty sure
printf() isn't one of the functions that can be safely called in a signal handler, which means your program has undefined behaviour. So we can't all agree that "Hello World!" will be printed, or that you'll remain untormented by those infamous nasal demons...– Toby Speight
Nov 21 '18 at 11:43
I'm pretty sure
printf() isn't one of the functions that can be safely called in a signal handler, which means your program has undefined behaviour. So we can't all agree that "Hello World!" will be printed, or that you'll remain untormented by those infamous nasal demons...– Toby Speight
Nov 21 '18 at 11:43
@TobySpeight I'm pretty sure
printf() isn't one of the functions that can be safely called in a signal handler There's no doubt about it - strictly speaking, printf() can't be called from a signal handler. Per the C standard: "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration." Footnote 188 adds: "Thus, a signal handler cannot, in general, call standard library functions."– Andrew Henle
Nov 21 '18 at 12:30
@TobySpeight I'm pretty sure
printf() isn't one of the functions that can be safely called in a signal handler There's no doubt about it - strictly speaking, printf() can't be called from a signal handler. Per the C standard: "The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration." Footnote 188 adds: "Thus, a signal handler cannot, in general, call standard library functions."– Andrew Henle
Nov 21 '18 at 12:30
@TobySpeight (cont) POSIX, however, specifies a list of functions that can be called from a signal handler: "The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions." Note that
printf() is not on that list. (Note that fork() is on that list, but fork() is broken on Linux)– Andrew Henle
Nov 21 '18 at 12:35
@TobySpeight (cont) POSIX, however, specifies a list of functions that can be called from a signal handler: "The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions." Note that
printf() is not on that list. (Note that fork() is on that list, but fork() is broken on Linux)– Andrew Henle
Nov 21 '18 at 12:35
add a comment |
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates.
bash does handle the signals at C / implementation level, but will not run the handlers set with trap until the foreground process has terminated. That's required by the standard:
When a signal for which a trap has been set is received while the shell
is waiting for the completion of a utility executing a foreground
command, the trap associated with that signal shall not be executed
until after the foreground command has completed.
Notice that the standard makes no difference between builtins and external commands; in the case of a "utility" like read, which is not executed in a separate process, it's not obvious whether a signal occurs in its "context" or in that of the main shell, and whether a handler set with trap should be run before or after the read returns.
issue 1:callback.sh contains a infinite while loop,how to explain it does not handle any signals received until the foreground process terminates.,in this case the foreground process never terminates.
That's wrong. bash is not executing the while loop in a separate process. Since there's no foreground process bash is waiting on, it can run any handler set with trap immediately. If read were an external command, that and not while would be the foreground process.
issue2: No
please input something for foo: shownin termA;
go to termB, run
pkill -USR1 -f callback.shthe third time.
The following info shown in termA again:
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no
please input something for foo:shown in termA.
Why the infoplease input something for foo:freeze up?
It doesn't freeze up. Just press Enter and it will show up again.
It's simply that
a) bash will restart the read builtin in place when interrupted by a signal -- it won't return and go again through the while loop
b) it will not re-display the prompt set with -p in that case.
Notice that bash won't even show the prompt again in the case where a SIGINT from the keyboard was handled, even if it does discard the string read so far from the user:
$ cat goo
trap 'echo INT' INT
echo $$
read -p 'enter something: ' var
echo "you entered '$var'"
$ bash goo
24035
enter something: foo<Ctrl-C>^CINT
<Ctrl-C>^CINT
<Ctrl-C>^CINT
bar<Enter>
you entered 'bar'
That will print you entered 'foobar' if the signal was sent from another window with kill -INT <pid> instead of with Ctrl-C from the terminal.
All the stuff in this last part (how read is interrupted, etc) is very bash specific. In other shells like ksh or dash, and even in bash when run in POSIX mode (bash --posix), any handled signal will actually interrupt the read builtin. In the example above, the shell will print you entered '' and exit after the first ^C, and if the read is called from a loop, the loop will be restarted.
answered Nov 22 '18 at 6:09
mosvymosvy
53914
add a comment |
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates.
bash does handle the signals at C / implementation level, but will not run the handlers set with trap until the foreground process has terminated. That's required by the standard:
When a signal for which a trap has been set is received while the shell
is waiting for the completion of a utility executing a foreground
command, the trap associated with that signal shall not be executed
until after the foreground command has completed.
Notice that the standard makes no difference between builtins and external commands; in the case of a "utility" like read, which is not executed in a separate process, it's not obvious whether a signal occurs in its "context" or in that of the main shell, and whether a handler set with trap should be run before or after the read returns.
issue 1:callback.sh contains a infinite while loop,how to explain it does not handle any signals received until the foreground process terminates.,in this case the foreground process never terminates.
That's wrong. bash is not executing the while loop in a separate process. Since there's no foreground process bash is waiting on, it can run any handler set with trap immediately. If read were an external command, that and not while would be the foreground process.
issue2: No
please input something for foo: shownin termA;
go to termB, run
pkill -USR1 -f callback.shthe third time.
The following info shown in termA again:
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no
please input something for foo:shown in termA.
Why the infoplease input something for foo:freeze up?
It doesn't freeze up. Just press Enter and it will show up again.
It's simply that
a) bash will restart the read builtin in place when interrupted by a signal -- it won't return and go again through the while loop
b) it will not re-display the prompt set with -p in that case.
Notice that bash won't even show the prompt again in the case where a SIGINT from the keyboard was handled, even if it does discard the string read so far from the user:
$ cat goo
trap 'echo INT' INT
echo $$
read -p 'enter something: ' var
echo "you entered '$var'"
$ bash goo
24035
enter something: foo<Ctrl-C>^CINT
<Ctrl-C>^CINT
<Ctrl-C>^CINT
bar<Enter>
you entered 'bar'
That will print you entered 'foobar' if the signal was sent from another window with kill -INT <pid> instead of with Ctrl-C from the terminal.
All the stuff in this last part (how read is interrupted, etc) is very bash specific. In other shells like ksh or dash, and even in bash when run in POSIX mode (bash --posix), any handled signal will actually interrupt the read builtin. In the example above, the shell will print you entered '' and exit after the first ^C, and if the read is called from a loop, the loop will be restarted.
answered Nov 22 '18 at 6:09
mosvymosvy
53914
add a comment |
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates.
bash does handle the signals at C / implementation level, but will not run the handlers set with trap until the foreground process has terminated. That's required by the standard:
When a signal for which a trap has been set is received while the shell
is waiting for the completion of a utility executing a foreground
command, the trap associated with that signal shall not be executed
until after the foreground command has completed.
Notice that the standard makes no difference between builtins and external commands; in the case of a "utility" like read, which is not executed in a separate process, it's not obvious whether a signal occurs in its "context" or in that of the main shell, and whether a handler set with trap should be run before or after the read returns.
issue 1:callback.sh contains a infinite while loop,how to explain it does not handle any signals received until the foreground process terminates.,in this case the foreground process never terminates.
That's wrong. bash is not executing the while loop in a separate process. Since there's no foreground process bash is waiting on, it can run any handler set with trap immediately. If read were an external command, that and not while would be the foreground process.
issue2: No
please input something for foo: shownin termA;
go to termB, run
pkill -USR1 -f callback.shthe third time.
The following info shown in termA again:
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no
please input something for foo:shown in termA.
Why the infoplease input something for foo:freeze up?
It doesn't freeze up. Just press Enter and it will show up again.
It's simply that
a) bash will restart the read builtin in place when interrupted by a signal -- it won't return and go again through the while loop
b) it will not re-display the prompt set with -p in that case.
Notice that bash won't even show the prompt again in the case where a SIGINT from the keyboard was handled, even if it does discard the string read so far from the user:
$ cat goo
trap 'echo INT' INT
echo $$
read -p 'enter something: ' var
echo "you entered '$var'"
$ bash goo
24035
enter something: foo<Ctrl-C>^CINT
<Ctrl-C>^CINT
<Ctrl-C>^CINT
bar<Enter>
you entered 'bar'
That will print you entered 'foobar' if the signal was sent from another window with kill -INT <pid> instead of with Ctrl-C from the terminal.
All the stuff in this last part (how read is interrupted, etc) is very bash specific. In other shells like ksh or dash, and even in bash when run in POSIX mode (bash --posix), any handled signal will actually interrupt the read builtin. In the example above, the shell will print you entered '' and exit after the first ^C, and if the read is called from a loop, the loop will be restarted.
answered Nov 22 '18 at 6:09
mosvymosvy
53914
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates.
bash does handle the signals at C / implementation level, but will not run the handlers set with trap until the foreground process has terminated. That's required by the standard:
When a signal for which a trap has been set is received while the shell
is waiting for the completion of a utility executing a foreground
command, the trap associated with that signal shall not be executed
until after the foreground command has completed.
Notice that the standard makes no difference between builtins and external commands; in the case of a "utility" like read, which is not executed in a separate process, it's not obvious whether a signal occurs in its "context" or in that of the main shell, and whether a handler set with trap should be run before or after the read returns.
issue 1:callback.sh contains a infinite while loop,how to explain it does not handle any signals received until the foreground process terminates.,in this case the foreground process never terminates.
That's wrong. bash is not executing the while loop in a separate process. Since there's no foreground process bash is waiting on, it can run any handler set with trap immediately. If read were an external command, that and not while would be the foreground process.
issue2: No
please input something for foo: shownin termA;
go to termB, run
pkill -USR1 -f callback.shthe third time.
The following info shown in termA again:
callback function called at Mon Nov 19 09:07:24 HKT 2018
Still no
please input something for foo:shown in termA.
Why the infoplease input something for foo:freeze up?
It doesn't freeze up. Just press Enter and it will show up again.
It's simply that
a) bash will restart the read builtin in place when interrupted by a signal -- it won't return and go again through the while loop
b) it will not re-display the prompt set with -p in that case.
Notice that bash won't even show the prompt again in the case where a SIGINT from the keyboard was handled, even if it does discard the string read so far from the user:
$ cat goo
trap 'echo INT' INT
echo $$
read -p 'enter something: ' var
echo "you entered '$var'"
$ bash goo
24035
enter something: foo<Ctrl-C>^CINT
<Ctrl-C>^CINT
<Ctrl-C>^CINT
bar<Enter>
you entered 'bar'
That will print you entered 'foobar' if the signal was sent from another window with kill -INT <pid> instead of with Ctrl-C from the terminal.
All the stuff in this last part (how read is interrupted, etc) is very bash specific. In other shells like ksh or dash, and even in bash when run in POSIX mode (bash --posix), any handled signal will actually interrupt the read builtin. In the example above, the shell will print you entered '' and exit after the first ^C, and if the read is called from a loop, the loop will be restarted.
answered Nov 22 '18 at 6:09
mosvymosvy
53914
edited Nov 28 '18 at 5:14
answered Nov 22 '18 at 6:09
mosvymosvy
53914
answered Nov 22 '18 at 6:09
mosvymosvy
53914
answered Nov 22 '18 at 6:09
mosvymosvy
53914
53914
add a comment |
add a comment |
termA does not freeze up. It is just displaying the callback in the input box. Simply push the Enter key to continue with the input.
answered Nov 21 '18 at 2:47
RotsRots
4,74323346
add a comment |
termA does not freeze up. It is just displaying the callback in the input box. Simply push the Enter key to continue with the input.
answered Nov 21 '18 at 2:47
RotsRots
4,74323346
add a comment |
termA does not freeze up. It is just displaying the callback in the input box. Simply push the Enter key to continue with the input.
answered Nov 21 '18 at 2:47
RotsRots
4,74323346
termA does not freeze up. It is just displaying the callback in the input box. Simply push the Enter key to continue with the input.
answered Nov 21 '18 at 2:47
RotsRots
4,74323346
answered Nov 21 '18 at 2:47
RotsRots
4,74323346
answered Nov 21 '18 at 2:47
RotsRots
4,74323346
answered Nov 21 '18 at 2:47
RotsRots
4,74323346
4,74323346
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53367146%2fwhen-is-a-signal-handled-and-why-does-some-info-freeze-up%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Note it is bad practice to name scripts ending with a
.sh. It makes the caller dependant on the implementation language ( a rewrite, will affect all callers). And you don't need to run with/bin/bash(just make the script executable), that is what the#!…is for.– ctrl-alt-delor
Nov 27 '18 at 18:49
Read also signal(7) and signal-safety(7)
– Basile Starynkevitch
Dec 4 '18 at 20:51