How can I signal a trap in “global” bash scope from function?
Clash Royale CLAN TAG#URR8PPP
I want to execute a trap command in "global" scope, but the signal will come from within function. Of course it is possible to declare the variable globally beforehand or use the -g
declare option. But in cases where I want to source on trap that's not very practicable as shown below:
#!/bin/bash
# ./variables
declare say=hello
declare -ri times 3
and the actual script:
#!/bin/bash
# ./trapsource
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; source ./variables' SIGUSR1
sourceVariables ()
kill -SIGUSR1 $$
setTraps
sendSignal
echo I want you to $say "hello" $times times.
printf "$sayn%.0s" $(seq 1 $times)
But without declare -g NAME
, thank you.
EDIT:
Is it possible to detach the kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I tried nohup
and disown
without success so far.
bash signals trap bash-functions
add a comment |
I want to execute a trap command in "global" scope, but the signal will come from within function. Of course it is possible to declare the variable globally beforehand or use the -g
declare option. But in cases where I want to source on trap that's not very practicable as shown below:
#!/bin/bash
# ./variables
declare say=hello
declare -ri times 3
and the actual script:
#!/bin/bash
# ./trapsource
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; source ./variables' SIGUSR1
sourceVariables ()
kill -SIGUSR1 $$
setTraps
sendSignal
echo I want you to $say "hello" $times times.
printf "$sayn%.0s" $(seq 1 $times)
But without declare -g NAME
, thank you.
EDIT:
Is it possible to detach the kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I tried nohup
and disown
without success so far.
bash signals trap bash-functions
add a comment |
I want to execute a trap command in "global" scope, but the signal will come from within function. Of course it is possible to declare the variable globally beforehand or use the -g
declare option. But in cases where I want to source on trap that's not very practicable as shown below:
#!/bin/bash
# ./variables
declare say=hello
declare -ri times 3
and the actual script:
#!/bin/bash
# ./trapsource
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; source ./variables' SIGUSR1
sourceVariables ()
kill -SIGUSR1 $$
setTraps
sendSignal
echo I want you to $say "hello" $times times.
printf "$sayn%.0s" $(seq 1 $times)
But without declare -g NAME
, thank you.
EDIT:
Is it possible to detach the kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I tried nohup
and disown
without success so far.
bash signals trap bash-functions
I want to execute a trap command in "global" scope, but the signal will come from within function. Of course it is possible to declare the variable globally beforehand or use the -g
declare option. But in cases where I want to source on trap that's not very practicable as shown below:
#!/bin/bash
# ./variables
declare say=hello
declare -ri times 3
and the actual script:
#!/bin/bash
# ./trapsource
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; source ./variables' SIGUSR1
sourceVariables ()
kill -SIGUSR1 $$
setTraps
sendSignal
echo I want you to $say "hello" $times times.
printf "$sayn%.0s" $(seq 1 $times)
But without declare -g NAME
, thank you.
EDIT:
Is it possible to detach the kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I tried nohup
and disown
without success so far.
bash signals trap bash-functions
bash signals trap bash-functions
edited Feb 17 at 17:48
Dominik Kummer
asked Feb 15 at 15:06
Dominik KummerDominik Kummer
788
788
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1
Instead of using declare -i
within the trap, do that beforehand, and just assign the new value in the trap:
declare -i times=999
trap 'times=3' USR1
I think you could even use readonly times
within the trap, since readonly
in itself doesn't make the variable local.
E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.
#!/bin/bash
trap 'readonly num=3' USR1
sub()
kill -USR1 $$
echo "$num"
declare -i num=999
num=1
echo "$num"
sub
echo "$num"
num=1234
Then again, if it's the global variable you want to modify, why not use declare -g
?
Is it possible to detach the
kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I don't think there's a difference between a signal sent by (the builtin) kill
from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.
you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.
– Dominik Kummer
Feb 17 at 17:42
@DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't usedeclare -g
, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.
– ilkkachu
Feb 17 at 17:59
@ikkachu I wrote a customSource
function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with-g
option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without-g
option.
– Dominik Kummer
Feb 17 at 18:17
add a comment |
#!/bin/bash
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1
sendSignal ()
kill -s USR1 "$$"
setTraps
sendSignal
printf 'I want you to %s "hello"n' "$say"
If you don't use declare
at all, the trap will set the say
variable to the string in global scope. The trap is still called within the scope of sendSignal
scope though, but I don't think there's a way of changing that.
even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.
– Dominik Kummer
Feb 16 at 12:59
regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach thekill -s USR1 "$$"
completely from the process, so that the signal would come from "outside"?
– Dominik Kummer
Feb 16 at 13:23
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f500894%2fhow-can-i-signal-a-trap-in-global-bash-scope-from-function%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1
Instead of using declare -i
within the trap, do that beforehand, and just assign the new value in the trap:
declare -i times=999
trap 'times=3' USR1
I think you could even use readonly times
within the trap, since readonly
in itself doesn't make the variable local.
E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.
#!/bin/bash
trap 'readonly num=3' USR1
sub()
kill -USR1 $$
echo "$num"
declare -i num=999
num=1
echo "$num"
sub
echo "$num"
num=1234
Then again, if it's the global variable you want to modify, why not use declare -g
?
Is it possible to detach the
kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I don't think there's a difference between a signal sent by (the builtin) kill
from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.
you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.
– Dominik Kummer
Feb 17 at 17:42
@DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't usedeclare -g
, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.
– ilkkachu
Feb 17 at 17:59
@ikkachu I wrote a customSource
function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with-g
option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without-g
option.
– Dominik Kummer
Feb 17 at 18:17
add a comment |
trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1
Instead of using declare -i
within the trap, do that beforehand, and just assign the new value in the trap:
declare -i times=999
trap 'times=3' USR1
I think you could even use readonly times
within the trap, since readonly
in itself doesn't make the variable local.
E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.
#!/bin/bash
trap 'readonly num=3' USR1
sub()
kill -USR1 $$
echo "$num"
declare -i num=999
num=1
echo "$num"
sub
echo "$num"
num=1234
Then again, if it's the global variable you want to modify, why not use declare -g
?
Is it possible to detach the
kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I don't think there's a difference between a signal sent by (the builtin) kill
from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.
you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.
– Dominik Kummer
Feb 17 at 17:42
@DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't usedeclare -g
, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.
– ilkkachu
Feb 17 at 17:59
@ikkachu I wrote a customSource
function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with-g
option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without-g
option.
– Dominik Kummer
Feb 17 at 18:17
add a comment |
trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1
Instead of using declare -i
within the trap, do that beforehand, and just assign the new value in the trap:
declare -i times=999
trap 'times=3' USR1
I think you could even use readonly times
within the trap, since readonly
in itself doesn't make the variable local.
E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.
#!/bin/bash
trap 'readonly num=3' USR1
sub()
kill -USR1 $$
echo "$num"
declare -i num=999
num=1
echo "$num"
sub
echo "$num"
num=1234
Then again, if it's the global variable you want to modify, why not use declare -g
?
Is it possible to detach the
kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I don't think there's a difference between a signal sent by (the builtin) kill
from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.
trap 'echo trap called in scope $FUNCNAME[@]; declare say=hello; declare -ri times=3' SIGUSR1
Instead of using declare -i
within the trap, do that beforehand, and just assign the new value in the trap:
declare -i times=999
trap 'times=3' USR1
I think you could even use readonly times
within the trap, since readonly
in itself doesn't make the variable local.
E.g. this prints 1, 3, 3 and then an error modifying a readonly variable.
#!/bin/bash
trap 'readonly num=3' USR1
sub()
kill -USR1 $$
echo "$num"
declare -i num=999
num=1
echo "$num"
sub
echo "$num"
num=1234
Then again, if it's the global variable you want to modify, why not use declare -g
?
Is it possible to detach the
kill -s USR1 $$
part completely from the current process, so that the signal comes from 'outside'?
I don't think there's a difference between a signal sent by (the builtin) kill
from the script itself, and one sent by another process. As you saw, Bash seems to run the trap code in the context of the running function.
answered Feb 16 at 14:11
ilkkachuilkkachu
60.9k1098174
60.9k1098174
you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.
– Dominik Kummer
Feb 17 at 17:42
@DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't usedeclare -g
, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.
– ilkkachu
Feb 17 at 17:59
@ikkachu I wrote a customSource
function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with-g
option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without-g
option.
– Dominik Kummer
Feb 17 at 18:17
add a comment |
you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.
– Dominik Kummer
Feb 17 at 17:42
@DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't usedeclare -g
, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.
– ilkkachu
Feb 17 at 17:59
@ikkachu I wrote a customSource
function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with-g
option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without-g
option.
– Dominik Kummer
Feb 17 at 18:17
you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.
– Dominik Kummer
Feb 17 at 17:42
you have a good point with declaring the variable beforehand. but there are cases when thats not practicable. For example sourcing a new file on trap. I'll clarify my question of course.
– Dominik Kummer
Feb 17 at 17:42
@DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use
declare -g
, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.– ilkkachu
Feb 17 at 17:59
@DominikKummer, I'm not really sure I see the utility of that, and I can't really see why you wouldn't use
declare -g
, since that appears to do what you want. But then I suppose one possibility would be to just set a flag in the trap, and then do the actual processing in the main level of the script.– ilkkachu
Feb 17 at 17:59
@ikkachu I wrote a custom
Source
function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g
option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g
option.– Dominik Kummer
Feb 17 at 18:17
@ikkachu I wrote a custom
Source
function which does some additional lookups, caches and finally sources the files. But within the sourced files I have to declare all variables global with -g
option. which works of course, you are right. It is actually a syntactical detail to be forced to declare a variable as global which is meant to be global in the first place. I hoped that I can work around with trapping the source mechanism to make the sourced variables global without -g
option.– Dominik Kummer
Feb 17 at 18:17
add a comment |
#!/bin/bash
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1
sendSignal ()
kill -s USR1 "$$"
setTraps
sendSignal
printf 'I want you to %s "hello"n' "$say"
If you don't use declare
at all, the trap will set the say
variable to the string in global scope. The trap is still called within the scope of sendSignal
scope though, but I don't think there's a way of changing that.
even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.
– Dominik Kummer
Feb 16 at 12:59
regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach thekill -s USR1 "$$"
completely from the process, so that the signal would come from "outside"?
– Dominik Kummer
Feb 16 at 13:23
add a comment |
#!/bin/bash
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1
sendSignal ()
kill -s USR1 "$$"
setTraps
sendSignal
printf 'I want you to %s "hello"n' "$say"
If you don't use declare
at all, the trap will set the say
variable to the string in global scope. The trap is still called within the scope of sendSignal
scope though, but I don't think there's a way of changing that.
even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.
– Dominik Kummer
Feb 16 at 12:59
regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach thekill -s USR1 "$$"
completely from the process, so that the signal would come from "outside"?
– Dominik Kummer
Feb 16 at 13:23
add a comment |
#!/bin/bash
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1
sendSignal ()
kill -s USR1 "$$"
setTraps
sendSignal
printf 'I want you to %s "hello"n' "$say"
If you don't use declare
at all, the trap will set the say
variable to the string in global scope. The trap is still called within the scope of sendSignal
scope though, but I don't think there's a way of changing that.
#!/bin/bash
setTraps ()
trap 'echo trap called in scope $FUNCNAME[@]; say=hello' USR1
sendSignal ()
kill -s USR1 "$$"
setTraps
sendSignal
printf 'I want you to %s "hello"n' "$say"
If you don't use declare
at all, the trap will set the say
variable to the string in global scope. The trap is still called within the scope of sendSignal
scope though, but I don't think there's a way of changing that.
answered Feb 16 at 11:21
KusalanandaKusalananda
135k17255420
135k17255420
even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.
– Dominik Kummer
Feb 16 at 12:59
regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach thekill -s USR1 "$$"
completely from the process, so that the signal would come from "outside"?
– Dominik Kummer
Feb 16 at 13:23
add a comment |
even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.
– Dominik Kummer
Feb 16 at 12:59
regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach thekill -s USR1 "$$"
completely from the process, so that the signal would come from "outside"?
– Dominik Kummer
Feb 16 at 13:23
even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.
– Dominik Kummer
Feb 16 at 12:59
even if the best answer is the simplest, I have to admit that I also would like to make use of $ say=hello; declare -i times=3; within the trap.
– Dominik Kummer
Feb 16 at 12:59
regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the
kill -s USR1 "$$"
completely from the process, so that the signal would come from "outside"?– Dominik Kummer
Feb 16 at 13:23
regarding impossibility, that unfortunately forces me into bash source code, because it would be pointless. Is it possible to detach the
kill -s USR1 "$$"
completely from the process, so that the signal would come from "outside"?– Dominik Kummer
Feb 16 at 13:23
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f500894%2fhow-can-i-signal-a-trap-in-global-bash-scope-from-function%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