Passing variables to awk
Hi all,
having created a complicated (for me) awk statement previously with the
forums' help I am now amending it and trying to pass variables to it. My
script is as follows with the respective outputs (hash then unhash when
running etc) for:-
1. variable var1 passed containing Framed-IP-Address
and
2. no variable as the Framed-IP-Address part is hardcoded.
#!/bin/bash
set -o xtrace
#
names[0]=smith
ipaddr[0]="Framed-IP-Address = 10\.6\.6\."
#1.
awk -v var1="${ipaddr[0]}" '/*** Received from 10.242.252.20 port 1645
/{ last_acct_status = NR; as = $0 }/Code: Access-Accept/ &&
last_acct_status + 1 == NR {last_user_name = NR; print NR-1 as; print NR $0
}/$var1/ && last_acct_status + 10 == NR { print NR $0 }' /tmp/theout >
/tmp/${names[0]}good
#2.
#awk '/*** Received from 10.242.252.20 port 1645 /{ last_acct_status =
NR; as = $0 }/Code: Access-Accept/ && last_acct_status + 1 == NR
{last_user_name = NR; print NR-1 as; print NR $0 }/Framed-IP-Address =
10\.6\.6\./ && last_acct_status + 10 == NR { print NR $0 }' /tmp/theout >
/tmp/${names[0]}good
cat /tmp/${names[0]}good
exit 1
Outputs:-
1. (broken as not delivering Framed-IP-Address output at end)
+ names[0]=smith
+ ipaddr[0]='Framed-IP-Address = 10\.6\.6\.'
+ awk -v 'var1=Framed-IP-Address = 10\.6\.6\.' '/*** Received from
10.242.252.20 port 1645 /{ last_acct_status = NR; as = $0 }/Code:
Access-Accept/ && last_acct_status + 1 == NR {last_user_name = NR; print
NR-1 as; print NR $0 }/$var1/ && last_acct_status + 10 == NR { print NR $0
}' /tmp/theout
awk: warning: escape sequence `\.' treated as plain `.'
+ cat /tmp/smithgood
106*** Received from 10.242.252.20 port 1645
107Code: Access-Accept
+ exit 1
2. (working as desired but hardcoded Framed-IP-Address string)
+ names[0]=smith
+ ipaddr[0]='Framed-IP-Address = 10\.6\.6\.'
+ awk '/*** Received from 10.242.252.20 port 1645 /{ last_acct_status =
NR; as = $0 }/Code: Access-Accept/ && last_acct_status + 1 == NR
{last_user_name = NR; print NR-1 as; print NR $0 }/Framed-IP-Address =
10\.6\.6\./ && last_acct_status + 10 == NR { print NR $0 }' /tmp/theout
+ cat /tmp/smithgood
106*** Received from 10.242.252.20 port 1645
107Code: Access-Accept
116 Framed-IP-Address = 10.6.6.47
+ exit 1
=
The second output contains the Framed-IP-Address statement which is what I
need.
Although I can see a warning in output 1 about \. being treated as plain . I
have not been able to remove it even though I suspect it would solve the
problem.
Thanks for any help in advance - please tell me if there is a more
appropriate forum.
Cheers Tim
--
View this message in context:
http://www.nabble.com/Passing-variables-to-awk-tf4730133.html#a13525369
Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Passing variables to awk
TimtheEagle <[EMAIL PROTECTED]> writes:
This is actually all unrelated to bash.
> + awk -v 'var1=Framed-IP-Address = 10\.6\.6\.' '/*** Received from
> 10.242.252.20 port 1645 /{ last_acct_status = NR; as = $0 }/Code:
`*' and `.' are special in regexps, you need to quote them to match them
as literals.
> Access-Accept/ && last_acct_status + 1 == NR {last_user_name = NR; print
> NR-1 as; print NR $0 }/$var1/ && last_acct_status + 10 == NR { print NR $0
/.../ is the syntax for a literal regexp. To match against a variable
use `$0 ~ var1' (awk does not use $ to refer to variables).
> }' /tmp/theout
> awk: warning: escape sequence `\.' treated as plain `.'
The value is parsed as a string. To include a backslash in a string
write it as \\.
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."
builtin printf behaves incorrectly with "c and 'c character-value arguments
$ printf %d\\n \'À -61 (expected 192) This should be 192 regardless of locale on any system where wchar_t values are ISO-10646/Unicode. Bash is incorrectly reading the first byte of the UTF-8 which happens to be -61 when interpreted as signed char; on a Latin-1 based locale it will probably give -63 instead. Both POSIX and common sense are clear that the numeric values resulting from 'c should be the wchar_t value of c and not the value of the first byte of the multibyte character; from the SUSv3 printf(1) documentation: Note that in a locale with multi-byte characters, the value of a character is intended to be the value of the equivalent of the wchar_t representation of the character as described in the System Interfaces volume of IEEE Std 1003.1-2001. Language lawyers could argue that on 'single-byte' locales perhaps the byte value should be used; however, strictly speaking a single-byte locale is simply a special case of a multi-byte one, and sanity should win in any case. Fixing the issue should be easy; asciicode() in builtins/printf.def simply needs to be changed to decode the character with mbrtowc rather than reading the byte (and perhaps also should be renamed...). Rich
Why does this kill my box?
vi test.sh $0 = "test"; tail -f /var/log/messages chmod +x test.sh ../test.sh Seems to spawn loads of bash processes. 2.6.22-14-386 Linux GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu)
Re: Why does this kill my box?
Hello, On Thu, Nov 01, 2007 at 11:25:58AM +, Steve P wrote: > $0 = "test"; expands to "../test.sh = test" and recurses (runs itself with parameters "=" and "test"). > tail -f /var/log/messages > > chmod +x test.sh > ../test.sh -- Tomas Janousek, SW Engineer, Red Hat, Inc.
run-fg-editor for bash?
In tcsh the command run-fg-editor bound by default to C-M-z is extremely useful when you have an editor suspended. It makes it very easy to return to the editor, do some editing, then suspend the editor again, and the command line is restored in exactly the same state as it was before doing C-M-z. It would be great if bash also supported this feature.
truncating the path in the bash prompt?
In tcsh %c can be used to only show the last few directory names in a path (also see the ellipsis variable). For example for this directory: /lib/modules/2.6.21-1.3194.fc7/kernel/drivers/char/hw_random/ the prompt can look like this: [EMAIL PROTECTED]:...drivers/char/hw_random> when using: set prompt = "[EMAIL PROTECTED]:%c03%# " Given the tendency of directory hierarchies to get deeper, it is very useful to be able to see some more context, so it would be great if bash also supported something similar. Sure, this can be implemented by using shell commands to set the prompt, but it would be much nicer if it was built in. Thanks --dan
Problem with reading file and executing other stuffs?
I've been struggling with the following code of reading a text file
(test.txt) and counting the number of lines. Well, I know there're simpler
method to count the number of lines of a text file, but that's not the point
of this post.
__
n=0
cat test.txt |
while read line
do
n=$((n+1))
echo "${line}"
done
echo "$n"
__
The result of the last echo is zero, meaning that n is never incremented
inside the while loop. It seems to me that inside this while loop, except
the echo of the lines, nothing else is done.
Pitfall? Bug? Or feature?
I'd appreciate if somebody could shed some light on this.
--
View this message in context:
http://www.nabble.com/Problem-with-reading-file-and-executing-other-stuffs--tf4733602.html#a13535762
Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: run-fg-editor for bash?
On Thu, Nov 01, 2007 at 07:48:13AM -0700, Dan Nicolaescu wrote:
>
> In tcsh the command run-fg-editor bound by default to C-M-z is
> extremely useful when you have an editor suspended.
> It makes it very easy to return to the editor, do some editing, then
> suspend the editor again, and the command line is restored in exactly
> the same state as it was before doing C-M-z.
>
> It would be great if bash also supported this feature.
I don't know about bash, but with zsh (sorry for the off-topic),
you'd do:
zle-fg() {fg || true}
zle -N zle-fg
bindkey '\M-\C-z' zle-fg
zsh is probably a more obvious choice if you want to transition
from tcsh to a Bourne like shell.
--
Stéphane
Re: Problem with reading file and executing other stuffs?
Horinius <[EMAIL PROTECTED]> wrote: > cat test.txt | > while read line Read entry E4 in the bash FAQ: http://tiswww.case.edu/php/chet/bash/FAQ paul
Re: truncating the path in the bash prompt?
On Thu, Nov 01, 2007 at 08:01:58AM -0700, Dan Nicolaescu wrote: > > In tcsh %c can be used to only show the last few directory names in a > path (also see the ellipsis variable). > > For example for this directory: > > /lib/modules/2.6.21-1.3194.fc7/kernel/drivers/char/hw_random/ > > the prompt can look like this: > > [EMAIL PROTECTED]:...drivers/char/hw_random> > > when using: set prompt = "[EMAIL PROTECTED]:%c03%# " > > Given the tendency of directory hierarchies to get deeper, it is very > useful to be able to see some more context, so it would be great if > bash also supported something similar. > Sure, this can be implemented by using shell commands to set the > prompt, but it would be much nicer if it was built in. [...] With bash, you could probably use the PROMPT_COMMAND special variable. With zsh again: PS1='[EMAIL PROTECTED]:%4(~:...:)%3~%# ' You can also truncate the path to a specific width, see info -f zsh -n 'Prompt Expansion' -- Stéphane
Re: truncating the path in the bash prompt?
Stephane Chazelas <[EMAIL PROTECTED]> writes: > On Thu, Nov 01, 2007 at 08:01:58AM -0700, Dan Nicolaescu wrote: > > > > In tcsh %c can be used to only show the last few directory names in a > > path (also see the ellipsis variable). > > > > For example for this directory: > > > > /lib/modules/2.6.21-1.3194.fc7/kernel/drivers/char/hw_random/ > > > > the prompt can look like this: > > > > [EMAIL PROTECTED]:...drivers/char/hw_random> > > > > when using: set prompt = "[EMAIL PROTECTED]:%c03%# " > > > > Given the tendency of directory hierarchies to get deeper, it is very > > useful to be able to see some more context, so it would be great if > > bash also supported something similar. > > Sure, this can be implemented by using shell commands to set the > > prompt, but it would be much nicer if it was built in. > [...] > > With bash, you could probably use the PROMPT_COMMAND special > variable. I am aware of that, and I stated it in the paragraph above. The point of this message is to have something that can be used by default without much hacking by most users.
