Re: unset strangely rejects certain function names eg fu~
[EMAIL PROTECTED] wrote: > $ unset fu~ > bash: unset: `fu~': not a valid identifier You can use "unset -f" to unset a function whose name doesn't fit the rules for variable names. paul
unset strangely rejects certain function names eg fu~
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables
uname output: Linux trixbox1.local 2.6.18-8.1.14.el5 #1 SMP Thu Sep 27 18:58:54
EDT 2007 i686 i686 i386 GNU/Linux
Machine Type: i686-redhat-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
unset strangely rejects certain function names eg fu~
Repeat-By:
$ function fun(){ echo running fun;}
$ function fu~(){ echo running fu~;}
$ fun
running fun
$ fu~
running fu~
$ unset fun
$ unset fu~
bash: unset: `fu~': not a valid identifier
Problem with pattern replacing when STRING is an expandable char
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I/tmp/S/bash-3.2 -I/tmp/S/bash-3.2/include
-I/tmp/S/bash-3.2/lib -g -O2
uname output: Linux * 2.6.23.1 #1 SMP PREEMPT Tue Oct 16 16:47:14 CEST
2007 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 25
Release Status: release
Description:
Pattern replacing doesn't work like documented with special
characters "*" and "?" as replacment strings
Repeat-By:
a=111.1
echo ${a//[0-9]/x}
correctly gives "xxx.x", but
echo ${a//[0-9]/*}
gives a listing of files in current directory. Seems that the "*"
is expanded before replacing the pattern.
It workes the right way at least up to bash-3.1.17(1)-release
But if you set
a=111
it doesn't even work in 3.1.17 right.
Kind regards,
H.-A. Arnolds
--
Dipl.-Ing. Heinz-Ado Arnolds
MPI fuer Astrophysik
Karl-Schwarzschild-Strasse 1
D-85748 Garching
Phone: +49/89/3-2217
FAX : +49/89/3-2388
email: arnolds[at]MPA-Garching.MPG.DE
Many FSCTL_PIPE_PEEK operations?
I just installed SysInternals' FileMon utility and have discovered all kinds of unknown activity going on behind the scenes. One that surprised me was Bash. FileMon says that Bash is doing 90-100 FSCTL_PIPE_SEEK operations EVERY SECOND! It does this even if a command is running, so there is no open prompt looking for input. Is it *supposed* to do that?? I'm running 3.2.17(15)-release (i686-pc-cygwin) on XP Pro. Gary
Re: unset strangely rejects certain function names eg fu~
> unset strangely rejects certain function names eg fu~
> $ function fun(){ echo running fun;}
> $ function fu~(){ echo running fu~;}
> $ fun
> running fun
> $ fu~
> running fu~
> $ unset fun
> $ unset fu~
> bash: unset: `fu~': not a valid identifier
Use 'unset -f' to unset function names.
Bob
Please advise on programming tactics/strategy
I was wondering if there is any way I can convince netstat to return
its output to bash variables for processing.
Pretty simple logic:
Do forever:
Call netstat to obtain RX & TX byte counts
Print delta {current .. minus previous .. byte counts}
Save current byte counts
Wait for a second or so ..
I initially thought I could just pipe the "netstat -in" command to the
invocation of a bash function.
The function would have taken care of the gory details of parsing &
formatting the output of the netstat command and would then have stored
the current byte counts where they would be available for the next time
the function is invoked.
The trouble is that I haven't been able to find anything like a "static"
local variable that is not reinitialized every time the function is
invoked.
Is there such a thing?
Or is there any way the function could save the current byte counts to
global variables?
Naturally, I thought of using an array but, at least as I understand it,
the bash doc seems to indicate that even with arrays, function calls
result in the array's contents being copied to a local copy that only
lives for the the duration of the current invocation of the function.
Or is there an altogether better .. more natural way to do the above in
bash?
Hope the above makes sense .. Will clarify if necessary.
:-)
Segmentation fault
GNU bash, version 3.2.25(1)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
#!/bin/sh
fib() {
n=$1
[ $n == 0 -o $n == 1 ] && return $n
fib $(($n-1))
ret1=$?
fib $(($n-2))
ret2=$?
return $(($ret1 + $ret2))
}
for ((i=0;$i<36;i++))
do
fib $i
echo "n=$i=>$?"
done
Re: Problem with pattern replacing when STRING is an expandable char
Heinz-Ado Arnolds <[EMAIL PROTECTED]> wrote:
> a=111.1
> echo ${a//[0-9]/x}
>
> correctly gives "xxx.x", but
>
> echo ${a//[0-9]/*}
>
> gives a listing of files in current directory. Seems that the "*"
> is expanded before replacing the pattern.
No, it's expanded afterward, because the variable expansion isn't
quoted. This does what you want:
echo "${a//[0-9]/*}"
> It workes the right way at least up to bash-3.1.17(1)-release
>
> But if you set
>
> a=111
>
> it doesn't even work in 3.1.17 right.
3.1.17 behaves the same way as 3.2.25. You see a different result
because of a different set of files between the two situations, not
because of the different bash version. If there are no files in the
current directory that match ***.*, then pathname expansion will leave
it unchanged.
paul
Re: Problem with pattern replacing when STRING is an expandable char
>
> Repeat-By:
> a=111.1
> echo ${a//[0-9]/x}
>
> correctly gives "xxx.x", but
>
> echo ${a//[0-9]/*}
>
> gives a listing of files in current directory. Seems that the "*"
> is expanded before replacing the pattern.
>
> It workes the right way at least up to bash-3.1.17(1)-release
>
> But if you set
>
> a=111
>
> it doesn't even work in 3.1.17 right.
The pathname expansion of "*" is not done until after the parameter
expansion substitution. That is the documented behavior. The following
example shows that echo of the "***.*" pattern matches files and
directories that have a "." in their name. Setting a to "111" results
in a pathname pattern of "***" that matches all of the files.
Double quoting the substitution prevents pathname expansion.
$ echo $BASH_VERSION
3.2.25(1)-release
$ touch a b c.d e.f
$ ls
a b c.d e.f
$ a=111.1
$ echo ${a//[0-9]/*}
c.d e.f
$ echo "${a//[0-9]/*}"
***.*
$ a=111
$ echo ${a//[0-9]/*}
a b c.d e.f
$ echo "${a//[0-9]/*}"
***
$
--
Mike Stroyan <[EMAIL PROTECTED]>
Re: unset strangely rejects certain function names eg fu~
[EMAIL PROTECTED] writes:
> Repeat-By:
> $ function fun(){ echo running fun;}
> $ function fu~(){ echo running fu~;}
> $ fun
> running fun
> $ fu~
> running fu~
> $ unset fun
> $ unset fu~
> bash: unset: `fu~': not a valid identifier
Use unset -f. (And don't work as root.)
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Problem with pattern replacing when STRING is an expandable char
Heinz-Ado Arnolds <[EMAIL PROTECTED]> writes:
> Repeat-By:
> a=111.1
> echo ${a//[0-9]/x}
>
> correctly gives "xxx.x", but
>
> echo ${a//[0-9]/*}
>
> gives a listing of files in current directory.
Only those that contain a period.
> Seems that the "*"
> is expanded before replacing the pattern.
No, it is expanded afterwards, since filename expansion is carried out
after parameter expansion. You need to quote it properly.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: Segmentation fault
seba wrote:
> GNU bash, version 3.2.25(1)-release (i686-pc-linux-gnu)
> Copyright (C) 2005 Free Software Foundation, Inc.
>
> #!/bin/sh
>
> fib() {
>n=$1
>[ $n == 0 -o $n == 1 ] && return $n
>fib $(($n-1))
>ret1=$?
>fib $(($n-2))
>ret2=$?
>return $(($ret1 + $ret2))
> }
>
> for ((i=0;$i<36;i++))
> do
>fib $i
>echo "n=$i=>$?"
> done
You managed to write yourself an infinitely-recursive function, and
eventually ran out of stack space. `==' is a string operator, not a
numeric operator, when used with `['.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Many FSCTL_PIPE_PEEK operations?
Gary Fritz wrote: > I just installed SysInternals' FileMon utility and have discovered all > kinds of unknown activity going on behind the scenes. > > One that surprised me was Bash. FileMon says that Bash is doing 90-100 > FSCTL_PIPE_SEEK operations EVERY SECOND! It does this even if a command is > running, so there is no open prompt looking for input. > > Is it *supposed* to do that?? The best place to ask this question is the cygwin mailing list. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Please advise on bash programming tactics/strategy
On Wed, Dec 12, 2007 at 12:31:47AM EST, Bob Proulx wrote:
> cga2000 wrote:
> > I was wondering if there is any way I can convince netstat to return
> > its output to bash variables for additional processing.
>
> Do you mean like this?
>
> rxcnt=$(netstat -ni | awk '/^eth0/{print$4}')
Precisely. Funny I keep forgetting this very powerful feature of bash.
>
> > Pretty simple logic:
> >
> > Do forever:
> >
> > Call netstat to obtain RX & TX byte counts for eth0 Print delta
> > {current .. minus previous .. byte counts} Save current byte
> > counts Wait for a second or so ..
>
> Such as like this?
>
> #!/bin/sh
[..]
> exit 0
Excellent!
I adapted the above and came up with this:
#!/bin/sh
interface=eth0
get_data()
{
netstat -ni | awk '/^'"$interface"'/{print$4,$8}'
}
init_data()
{
netdata=$(get_data)
prevrxcnt=$(echo $netdata | awk '{print$1}')
prevtxcnt=$(echo $netdata | awk '{print$2}')
}
save_data()
{
netdata=$(get_data)
rxcnt=$(echo $netdata | awk '{print$1}')
txcnt=$(echo $netdata | awk '{print$2}')
diffrxcnt=$(($rxcnt - $prevrxcnt))
difftxcnt=$(($txcnt - $prevtxcnt))
prevrxcnt=$rxcnt
prevtxcnt=$txcnt
}
init_data
while sleep 1;
do
save_data
echo $diffrxcnt $difftxcnt |
awk '{printf "%4.1f k/s %4.1f k/s\n",$1*576/1024,$2*567/1024}'
done
exit 0
I provides exactly the output I need .. although bash must provide a
more elegant (and less expensive) way to split a variable that contains
two fields separated by a space than invoking awk.
;-(
I would have liked to take the packets-to-kilobytes conversion out of
the last awk invocation, but then it looks like bash only does integer
arithmetic.
In any event any suggestions how I could improve the above is very
welcome.
> I would not normally use global variables like this but it was
> specifically what you were asking so I used them. Normally I prefer
> to avoid global variables except for global configuration data. Being
> able to trace the flow through the code as you read it is very
> important to the long term maintainability IMNHO. So generally I
> advise to write the code such as to avoid using globals.
Yes, but I don't see how this could be done in bash if you'd rather
have something modular.
Naturally, one way to get rid of global variables would be to rewrite
the above like so:
#!/bin/sh
interface=eth0
get_data()
{
netstat -ni | awk '/^'"$interface"'/{print$4,$8}'
}
netdata=$(get_data)
prevrxcnt=$(echo $netdata | awk '{print$1}')
prevtxcnt=$(echo $netdata | awk '{print$2}')
while sleep 1; do
netdata=$(get_data)
rxcnt=$(echo $netdata | awk '{print$1}')
txcnt=$(echo $netdata | awk '{print$2}')
diffrxcnt=$(($rxcnt - $prevrxcnt))
difftxcnt=$(($txcnt - $prevtxcnt))
prevrxcnt=$rxcnt
prevtxcnt=$txcnt
echo $diffrxcnt $difftxcnt |
awk '{printf "%4.1f k/s %4.1f k/s\n",$1*576/1024,$2*567/1024}'
done
exit 0
But then, this is beginning to look as cryptic as my initial one-liner.
> > I initially thought I could just pipe the "netstat -in" command to
> > the invocation of a bash function.
>
> Yes?
>
> filter_data() { awk '/^'"$interface"'/{print$4}' ;}
>
> get_data() { netstat -ni | filter_data ;}
>
> > The function would have taken care of the gory details of parsing &
> > formatting the output of the netstat command and then stored the
> > current byte counts where they would be available for the next time
> > the function is invoked.
>
> Oh, stored, global variables, blech, but okay.
>
> grab_data() { prevrxcnt=$(awk '/^'"$interface"'/{print$4}') ;}
>
> > The trouble is that I haven't been able to find anything like a
> > "static" local variable -- ie. variables that are not reinitialized
> > every time the function is invoked.
>
> In C static variables are global to the compilation unit. In bash the
> entire script is the compilation unit. In C static variables are not
> visible across compilation units. In bash there is no individual
> compilation with a separate link step.
>
> Traditionally a naming convention such as applying the name of the
> function to the variable name is used to make sure that name
> collisions are avoided.
>
> > Is there such a thing? Or is there any way the function could save
> > the current byte counts to global variables?
>
> See my examples. Or did I miss the point of the question entirely?
Oh, no .. spot on!
After you'd shown me how I could assign the parsed output of netstat to
variables, and since you kindly provided a sample script that worked out
of the box, there was little left for me to do..
Thanks much for your help.
Re: Segmentation fault
Chet Ramey wrote:
> seba wrote:
>> #!/bin/sh
>>
>> fib() {
> You managed to write yourself an infinitely-recursive function, and
> eventually ran out of stack space. `==' is a string operator, not a
> numeric operator, when used with `['.
Most likely. When I test this and it breaks, the stack has over 32000
entries, all execute_command(), execute_command_internal().
J.
