Re: Help on bash script?

2005-08-13 Thread Ian Smith
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?

2005-08-12 Thread Giorgos Keramidas
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?

2005-08-12 Thread Benson Wong
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  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?

2005-08-11 Thread Xu Qiang
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]"


RE: Help on bash script?

2005-08-11 Thread dpk
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?

2005-08-11 Thread Xu Qiang
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?

2005-08-11 Thread Xu Qiang
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?

2005-08-11 Thread Xu Qiang
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?

2005-08-11 Thread Giorgos Keramidas
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?

2005-08-11 Thread Xu Qiang
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?

2005-08-11 Thread dpk
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]"