Re: Odd behaviour when running exec inside a signal handler
On Sun, Jul 25, 2010 at 04:54:53PM -0400, Chet Ramey wrote: > On 7/25/10 8:51 AM, Julien Dessaux wrote: > > I have a script that trap USR1 for reloading purpose. The signal handler > > then does some cleaning, then exec $0. > > With BSD and Posix-style signals, the caught signal is automatically > blocked by the kernel when executing its signal handler. If you exec > a new program out of the signal handler, it's going to be executed > with that signal blocked. From the new program's perspective, it really > is as if you never left the signal handler. I believe the typical workaround for this type of issue is to set a variable in the signal handler, and then (outside the trap, in some sort of main loop) check for that variable and do the real handling. I've never developed a bash script that needed that sort of sophistication, but that's how it's generally done in C.
Re: Odd behaviour when running exec inside a signal handler
On Mon, Jul 26, 2010 at 2:16 PM, Greg Wooledge wrote: > On Sun, Jul 25, 2010 at 04:54:53PM -0400, Chet Ramey wrote: > > On 7/25/10 8:51 AM, Julien Dessaux wrote: > > > I have a script that trap USR1 for reloading purpose. The signal > handler > > > then does some cleaning, then exec $0. > > > > With BSD and Posix-style signals, the caught signal is automatically > > blocked by the kernel when executing its signal handler. If you exec > > a new program out of the signal handler, it's going to be executed > > with that signal blocked. From the new program's perspective, it really > > is as if you never left the signal handler. > > I believe the typical workaround for this type of issue is to set a > variable in the signal handler, and then (outside the trap, in some sort > of main loop) check for that variable and do the real handling. > > I've never developed a bash script that needed that sort of sophistication, > but that's how it's generally done in C. > I really didn't believed it would just appear to be a posix issue! I guess I am trying to do something that is really too ugly... Anyway, thank you both. -- Julien Dessaux
When to use printf instead of echo?
Hi, Although echo is sufficient most of the time, my understanding is that printf may be better for certain situations (for example, formatting the width of a number). The manual doesn't explicitly mention in what situations it is better to use printf than to use echo. I think that this might have been compared before, but I don't find it. Could you please let me know when to use printf instead of echo? In particular, I want to print a string that has single quote, double quote and dollar character. I could use " to enclose such string and add '\' to escape " and $ in the string. But I can't use ' in to enclose the string. It is still inconvenient to have too many escape characters. I'm wondering what is the best way to print such string. echo "\$XX\"'" # this works. echo '$XX"\'' #this doesn't work. -- Regards, Peng
Re: When to use printf instead of echo?
On 07/26/2010 03:27 PM, Peng Yu wrote: > Hi, > > Although echo is sufficient most of the time, my understanding is that > printf may be better for certain situations (for example, formatting > the width of a number). The manual doesn't explicitly mention in what > situations it is better to use printf than to use echo. Anywhere that you might have an argument that has a \ anywhere (in the argument to echo itself, after shell quoting is removed) or a leading -. In short, anywhere where you want to be portable. > In particular, I want to print a string that has single quote, double > quote and dollar character. I could use " to enclose such string and > add '\' to escape " and $ in the string. But I can't use ' in to > enclose the string. It is still inconvenient to have too many escape > characters. I'm wondering what is the best way to print such string. > > echo "\$XX\"'" # this works. Yes, because you are handing the five characters $ X X " ' to echo after you remove the shell quoting. > echo '$XX"\'' #this doesn't work. That's because in shell quoting, '' preserves \, which means you have the five literal characters $ X X " \ followed by an unterminated '. And even if you properly terminated the trailing ', you would then be passing a literal backslash to echo, which is not portable. But if you intended to print the same string as your first example, this works: echo '$XX"'\' (that is, use concatenation of '' quoting for the first four characters, and backslash quoting for the last character). In short, it sounds like you still haven't figured out that there is no way to provide a ' inside '' quoting, but that there doesn't need to be a way, because "" and \ quoting are both sufficient for the task. But that is an independent question from whether to use echo or printf. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RFE -or- Howto?
I don't know if there's an easy way, but if not would you consider an RFE --
Is there a syntax for a mult-var assignment, ala:
(a b c d)=(1 2 3 4)
results would be: a=1, b=2, c=3, d=4
I know I can get the rval into an array, but can't figure out how to move
the array vals to discrete variables.
In *this* particular situation, I'm trying to something like
for (p v1 v2) in "(a 1 2)" "(b 2.0 2.1)" "(c 0.2.2 0.2.2-1)"; do
...
If it's not there, I wonder if it would be a syntactic advantage to use
a lead-in char, like "@" to indicate that a parenthesized list following
it would be a list of vars ?
I'm constantly running into little scriptlets that need multiple vals
assigned/interation,
and it would be so handy to have a simple syntax, than to do the more perverse
thing:
U="$(uname -sno)"
PUB_CONST SYSTEM_KERNEL="${U%% *}"
U="${U##$SYSTEM_KERNEL }"
PUBLIC HOSTNAME="${U%% *}"
U="${U##$HOSTNAME }"
PUB_CONST OSTYPE="${U//\//-}"
unset U
Re: RFE -or- Howto?
On 7/26/10 6:25 PM, Linda Walsh wrote: > I don't know if there's an easy way, but if not would you consider an > RFE -- > > Is there a syntax for a mult-var assignment, ala: > (a b c d)=(1 2 3 4) Yes. read a b c d <<<"1 2 3 4" Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
How use a local variable in for loop?
Hi, The variable f keeps the last value when the for loop is finished. Is there a way to declare it as a local variable, so that it disappears after for-loop is finished? (I could unset it, but I want to know if it can be a local variable) $ for f in a b; do echo $f; done a b $ echo $f b -- Regards, Peng
Re: How use a local variable in for loop?
On 07/26/2010 07:50 PM, Peng Yu wrote:
> Hi,
>
> The variable f keeps the last value when the for loop is finished. Is
> there a way to declare it as a local variable, so that it disappears
> after for-loop is finished? (I could unset it, but I want to know if
> it can be a local variable)
>
> $ for f in a b; do echo $f; done
> a
> b
> $ echo $f
> b
Local variables can only be used in functions - ergo, the answer to your
question is to wrap the for loop in a function:
$ func () {
local f
for f; do
echo $f
done
}
$ f=1; func a b; echo $f
a
b
1
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Strange behavior with job control
Hi,
consider the following script:
#!/bin/bash
sleep 0.5 &
if [[ $1 = a ]]; then
sleep 5 &
else
{ sleep 5; } &
fi
PID=$!
wait %1
kill $PID
ps aux | grep '[s]leep 5'
exit 0
When I run this script with parameter "a" I get the following output:
./foo.sh: line 11: 12132 Terminated sleep 5
When I run the script with the parameter "b" instead, I get two lines of
output:
1000 12117 0.0 0.0 9728 828 pts/1S+ 01:39 0:00 sleep 5
./foo.sh: line 11: 12116 Terminated { sleep 5; }
Why is "sleep 5" still running in the second case even though the job
received SIGTERM and is known to the job control as "terminated"?
What's even more puzzling to me is that removing the "wait %1" call
makes the problem disappear. That is, without the wait call the sleep 5
job properly terminates due to the kill, no matter if it was in curly
braces or not.
How can the wait call affect a job it's not supposed to wait for?
Christoph
(I use "GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)" on
Ubuntu 10.04.)
