Re: Help on bash script?
On Sat, 13 Aug 2005, Giorgos Keramidas wrote: On 2005-08-12 13:38, Benson Wong [EMAIL PROTECTED] wrote: I prefer: for COREFILE in `find / -type f -name core -print` do ... done Wouldn't that accomplish the same thing? More or less. Less, when the filenames are too many. See questions posted on this very same list about ``too many arguments''. True. Of course if you've got that many core files lying around, you probably have other things to worry about :) The ``while read line; do stuff with $line; done'' loop doesn't suffer from the same limitation, but is a bit more expensive in terms of the number of spawned processes and (consequently) the time it takes to run. Maybe measurable. Took me ages to appreciate the difference between say cat tempfile | while read line; do stuff with $line; done and while read line; do stuff with $line; done tempfile when 'stuff' needs to update script-scope variables, despite a slightly icky, impure feeling about using tempfiles .. cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help on bash script?
I prefer:
for COREFILE in `find / -type f -name core -print`
do
...
done
Wouldn't that accomplish the same thing?
On 8/12/05, Ian Smith [EMAIL PROTECTED] wrote:
On Fri 12 Aug 2005 09:33:54 +0800 Xu Qiang [EMAIL PROTECTED] wrote:
find / -type f -name core -print | while read COREFILE ; do
NCOREFILES=$[ $NCOREFILES + 1 ] # a bit strange - xq
echo $NCOREFILES # xq
NEWNAME=${HOSTNAME}esscore${NCOREFILES}_${TIMESTAMP}
# record mapping so people can go back and figure out
# where they came from
echo -e $NEWNAME was `ls -l $COREFILE`
$SAVE_DIR/$CORELOG
mv $COREFILE $SAVE_DIR/$NEWNAME
echo There are $NCOREFILES core files. # xq
done
fi
# What confused me most is the value $NCOREFILES outside
# the do-while loop (but still in this function) reverted
# back to its initial value, which seems contradictory to
# our concept of local variables. - xq
#echo $NCOREFILES
It's been pointed out that the find piped to while runs in a subshell,
and that changes to variables within aren't seen by its parent, but one
way around this is to avoid using a pipe, thus a subshell, for instance:
find / -type f -name *.core -print tempfile
while read COREFILE; do
[.. stuff ..]
NCOREFILES=$(($NCOREFILES + 1))
done tempfile
echo $NCOREFILES
I use sh, not bash, but suspect that this should work in bash too.
cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
blog: http://www.mostlygeek.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help on bash script?
On 2005-08-12 13:38, Benson Wong [EMAIL PROTECTED] wrote: I prefer: for COREFILE in `find / -type f -name core -print` do ... done Wouldn't that accomplish the same thing? More or less. Less, when the filenames are too many. See questions posted on this very same list about ``too many arguments''. The ``while read line; do stuff with $line; done'' loop doesn't suffer from the same limitation, but is a bit more expensive in terms of the number of spawned processes and (consequently) the time it takes to run. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help on bash script?
On Fri, 12 Aug 2005, Xu Qiang wrote: Hi, all: I don't know if this is the right list to ask this question. But since I didn't find a bash script mail list and you guys are always so helpful, then... Here are an excerpt of a bash script: --- #!/bin/bash # saveLogs.sh - Bourne Again Shell script ... find / -type f -name core -print | while read COREFILE ; do NCOREFILES=$[ $NCOREFILES + 1 ] # a bit strange - xq echo $NCOREFILES # xq ... --- ... 1. The way of incrementing the variable NCOREFILES. Why does it use the formula of NCOREFILES=$[ $NCOREFILES + 1 ], and not the direct way of NCOREFILES=$NCOREFILES+1? If that was done, NCOREFILES would end up looking like: +1+1+1+1+1+1+1 as bash does not automatically differentiate between numeric and string variables. What the funky looking construct does is convince bash to treat it as a numeric/arithmetic expression. 2. What confused me most is the value of the variable NCOREFILES ($NCOREFILES). Say there is just 1 core file, then because the initial value of NCOREFILES is 0, it will be incremented to 1. Yes, this is the value in the do-while loop. But outside the loop and if-block, the value of NCOREFILES is reverted back to 0 - its initial value. It is a local variable, so any modification to it should be valid as long as we are still in the scope of the function, right? I am really lossed at this phenomenon. As soon as you used the pipe, to the while, you entered a sub-shell. There's no way (that I'm aware of anyways) to get the sub-shell's variables sent back up to the parent. You could do something along the lines of: for cf in `find -X -type f -name core -print` do # do stuff with $cf NCOREFILES=$[ $NCOREFILES + 1 ] done (the -X helps prevent problems when faced with spaces embedded in the path) By the way, on FreeBSD systems, the default core filename format is %N.core (see man core) where %N is the name of the program that dumped. You'd need to expand your find with -name \*.core . If you wanted to get really fancy, you could parse sysctl kern.corefile to find out the current filename format and use that in your find, but most people leave that sysctl at its default, so it probably wouldn't be necessary. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Help on bash script?
dpk wrote: On Fri, 12 Aug 2005, Xu Qiang wrote: As soon as you used the pipe, to the while, you entered a sub-shell. There's no way (that I'm aware of anyways) to get the sub-shell's variables sent back up to the parent. Thanks for your detailed analysis and a solution. Yes, I didn't notice the pipe's effect. Btw, can we export a value in the sub-shell back to the parent? thanks, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help on bash script?
On 2005-08-12 10:16, Xu Qiang [EMAIL PROTECTED] wrote: Btw, can we export a value in the sub-shell back to the parent? Only through `backquote subtitution', as the child process cannot affect the environment of the parent process. value=`shell command` value=$(shell command) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Help on bash script?
Giorgos Keramidas wrote: On 2005-08-12 10:16, Xu Qiang [EMAIL PROTECTED] wrote: Btw, can we export a value in the sub-shell back to the parent? Only through `backquote subtitution', as the child process cannot affect the environment of the parent process. value=`shell command` value=$(shell command) Ah, yes, I mistakened it. The export mechanism is to preserve the value from the parent to the child, not the other direction, as described in the book The Unix Programming Environment by Brian Kernighan and Rob Pike. Thanks, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Help on bash script?
dpk wrote: On Fri, 12 Aug 2005, Xu Qiang wrote: 1. The way of incrementing the variable NCOREFILES. Why does it use the formula of NCOREFILES=$[ $NCOREFILES + 1 ], and not the direct way of NCOREFILES=$NCOREFILES+1? If that was done, NCOREFILES would end up looking like: +1+1+1+1+1+1+1 as bash does not automatically differentiate between numeric and string variables. What the funky looking construct does is convince bash to treat it as a numeric/arithmetic expression. Strangely, there is no mention of this assignment usage in the book Learning the bash shell, 2nd ed by O'Reilly at my hand. :( And man bash didn't talk of it either. However, it mentioned for arithmetic evaluation, we can use id++ id-- variable post-increment and post-decrement ++id --id variable pre-increment and pre-decrement If it is correct, then I can also increment NCOREFILES by: ++NCOREFILES. But I doubt it... Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Help on bash script?
This is my test script: - #!/bin/bash var=0 var=$[3] vari=0 ++vari echo $var echo $vari - The result is: ./test.sh: ++vari: command not found 3 0 So the manual of bash is incorrect? Regards, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Help on bash script?
On Fri, 12 Aug 2005, Xu Qiang wrote: This is my test script: - #!/bin/bash var=0 var=$[3] vari=0 ++vari echo $var echo $vari - The result is: ./test.sh: ++vari: command not found 3 0 So the manual of bash is incorrect? Regards, Xu Qiang It will work with either 'let' or within an 'arithmetic expansion': $[++var] let ++var By the way, there is another syntax, from the man page, that seems to operate identically: $((++var)) and $((var+1)) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Help on bash script?
dpk wrote: It will work with either 'let' or within an 'arithmetic expansion': $[++var] let ++var By the way, there is another syntax, from the man page, that seems to operate identically: $((++var)) and $((var+1)) With let ++var, the result is still 0, it isn't incremented. With $[++var], the result is 0: command not found. $((++var)) is to the same effect as let ++var. $((var+1)) works. But the value of var can't be incremented. thanks, Xu Qiang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
