I am new to Awk programmin.
Given a text table with the following sample entry:
[ 8] SSID[ [HOME]] BSSID[04:9F:xx:xx:xx:xx] channel[ 6] frequency[2437] numsta[1] rssi[-63] noise[-75] beacon[98] cap[1411]
dtim[0] rate[450] enc[Group-AES-CCMP CCMP PSK2 ]
How do you use Awk to quickly & easily break it into:
bssid="04:9F:xx:xx:xx:xx";
ssid[bssid]="[HOME]";
channel[bssid]="6";
frequency[bssid]="2437";
....
rate[bssid]="450;
enc[bssid]="Group-AES-CCMP CCMP PSK2";
I am new to Awk programming.
Given a text table with the following sample entry:
[ 8] SSID[ [HOME]] BSSID[04:9F:xx:xx:xx:xx] channel[ 6] frequency[2437] numsta[1] rssi[-63] noise[-75] beacon[98] cap[1411]
dtim[0] rate[450] enc[Group-AES-CCMP CCMP PSK2 ]
How do you use Awk to quickly & easily break it into:
bssid="04:9F:xx:xx:xx:xx";
ssid[bssid]="[HOME]";
channel[bssid]="6";
frequency[bssid]="2437";
....
rate[bssid]="450;
enc[bssid]="Group-AES-CCMP CCMP PSK2";
I am new to Awk programming.
Given a text table with the following sample entry:
The nasty thing is the nested '[...]'.
One quick way is to choose an appropriate field separator. For
example
BEGIN { FS="] " }
{ for (i=1; i<=NF; i++)
print $i
}
On 1/3/2024 10:52 pm, Janis Papanagnou wrote:
BEGIN { FS="] " }
{ for (i=1; i<=NF; i++)
print $i
}
Use of `NF` in awk command - Stack Overflow https://stackoverflow.com/questions/47216786/use-of-nf-in-awk-command
On 1/3/2024 10:52 pm, Janis Papanagnou wrote:
BEGIN { FS="] " }
{ for (i=1; i<=NF; i++)
print $i
}
Use of `NF` in awk command - Stack Overflow
On 1/3/2024 10:52 pm, Janis Papanagnou wrote:
BEGIN { FS="] " }
{ for (i=1; i<=NF; i++)
print $i
}
Use of `NF` in awk command - Stack Overflow https://stackoverflow.com/questions/47216786/use-of-nf-in-awk-command
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in
different awk variants and even in 1 awk variant can behave differently >depending on whether you're setting it to a higher or lower than
original value
In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton <mortonspam@gmail.com> wrote:
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in
different awk variants and even in 1 awk variant can behave differently >>depending on whether you're setting it to a higher or lower than
original value
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.
arnold@freefriends.org (Aharon Robbins) writes:
In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton <mortonspam@gmail.com> wrote:
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in >>>different awk variants and even in 1 awk variant can behave differently >>>depending on whether you're setting it to a higher or lower than >>>original value
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.
I don't see that in the POSIX specification.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
"""
NF
The number of fields in the current record. Inside a BEGIN action,
the use of NF is undefined unless a getline function without a var
argument is executed previously. Inside an END action, NF shall
retain the value it had for the last record read, unless a
subsequent, redirected, getline function without a var argument is
performed prior to entering the END action.
On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
arnold@freefriends.org (Aharon Robbins) writes:
In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton <mortonspam@gmail.com> wrote:
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in >>>>different awk variants and even in 1 awk variant can behave differently >>>>depending on whether you're setting it to a higher or lower than >>>>original value
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.
I don't see that in the POSIX specification.
The key is this:
References to nonexistent fields (that is, fields after $NF), shall
evaluate to the uninitialized value.
NF is assignable, and fields after $NF do not exist. Thus if we
have four fields and set NF = 3, then $4 doesn't exist.
That implies it must cease to exist; i.e. be destroyed. If setting NF = 4 were
to restore $4 then that would mean it had continued to exist, but was only hidden.
The behavior is present in GNU Awk, Mawk, BusyBox Awk and others.
--https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
"""
NF
The number of fields in the current record. Inside a BEGIN action,
the use of NF is undefined unless a getline function without a var
argument is executed previously. Inside an END action, NF shall
retain the value it had for the last record read, unless a
subsequent, redirected, getline function without a var argument is
performed prior to entering the END action.
This looks defective. The value of NF observed in END must obviously
be the last stored one, however it was stored, whether by assignment
or getline.
Note that NF is also recalculated if $0 is assigned, which is
explicitly required in the document; it is glaringly defective to
be appearing to be making an exception for getline but not for
assignment to $0.
Kaz Kylheku <433-929-6894@kylheku.com> writes:
On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
arnold@freefriends.org (Aharon Robbins) writes:
In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton <mortonspam@gmail.com> wrote:
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in >>>>>different awk variants and even in 1 awk variant can behave differently >>>>>depending on whether you're setting it to a higher or lower than >>>>>original value
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.
I don't see that in the POSIX specification.
The key is this:
References to nonexistent fields (that is, fields after $NF), shall
evaluate to the uninitialized value.
NF is assignable, and fields after $NF do not exist. Thus if we
have four fields and set NF = 3, then $4 doesn't exist.
That describes what happens if NF is modified by assignment, but I don't
see that it implies that such an assignment is allowed.
But I can imagine a hypothetical awk-like language in which assigning to
NF has undefined behavior. My question is, how does the POSIX
specification not describe that language?
On the other hand, it also implies that `foo = 42` is valid where `foo`
is the name of a user-defined function (gawk disallows it).
In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton <mortonspam@gmail.com> wrote:
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in
different awk variants and even in 1 awk variant can behave differently
depending on whether you're setting it to a higher or lower than
original value
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.
On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Kaz Kylheku <433-929-6894@kylheku.com> writes:
On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
arnold@freefriends.org (Aharon Robbins) writes:
In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton <mortonspam@gmail.com> wrote:
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in
different awk variants and even in 1 awk variant can behave differently >>>>>> depending on whether you're setting it to a higher or lower than
original value
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.
I don't see that in the POSIX specification.
The key is this:
References to nonexistent fields (that is, fields after $NF), shall
evaluate to the uninitialized value.
NF is assignable, and fields after $NF do not exist. Thus if we
have four fields and set NF = 3, then $4 doesn't exist.
That describes what happens if NF is modified by assignment, but I don't
see that it implies that such an assignment is allowed.
"The left-hand side of an assignment and the target of increment and decrement operators can be one of a variable, an array with index, or a
field selector."
NF is described as a variable. Some unique remarks are made about NF,
but none deny that it's assignable like any other variable.
But I can imagine a hypothetical awk-like language in which assigning to
NF has undefined behavior. My question is, how does the POSIX
specification not describe that language?
That language is failing to support an instance of a variable
being the left operand of an assignment, which a variable "can be".
It looks like the violation of a requirement.
On the other hand, it also implies that `foo = 42` is valid where `foo`
is the name of a user-defined function (gawk disallows it).
POSIX does say that "[t]he same name shall not be used as both a
function parameter name and as the name of a function or a special awk variable." So foo = 42 isn't valid if foo is already a function.
Also: "The same name shall not be used both as a variable name with
global scope and as the name of a function. The same name shall not be
used within the same scope both as a scalar variable and as an array."
All that said, the business of the NF tail wagging the $1, $2, ...
legs of the dog should be the target of at least one clarifying remark,
and the other defects should also be corrected:
- In a BEGIN clause NF should be undefined unless any action
whatsoever is executed that sets its value: direct assignment,
use of getline or assignment to $0.
- At the start of the execution of an END clause, NF retains
its current value (or undefined status, if it was never set);
the END clause has no implicit effect on NF.
On 3/13/2024 4:49 PM, Kaz Kylheku wrote:
On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Kaz Kylheku <433-929-6894@kylheku.com> writes:
On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
arnold@freefriends.org (Aharon Robbins) writes:
In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton <mortonspam@gmail.com> wrote:
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in
different awk variants and even in 1 awk variant can behave differently >>>>>>> depending on whether you're setting it to a higher or lower than >>>>>>> original value
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.
I don't see that in the POSIX specification.
The key is this:
References to nonexistent fields (that is, fields after $NF), shall >>>> evaluate to the uninitialized value.
NF is assignable, and fields after $NF do not exist. Thus if we
have four fields and set NF = 3, then $4 doesn't exist.
That's a bit like the argument from an old episode of the comedy TV show "Yes, Prime Minister"
in the UK where his aide says (paraphrased) "Some
country has done X, we must go something. War is something, therefore we must go to war".
Being able to set NF to 3 does not mean you must delete $4.
Why not
delete $1 or $2 instead?
You'd still end up with 3 fields to satisfy the
value of NF.
That describes what happens if NF is modified by assignment, but I don't
see that it implies that such an assignment is allowed.
On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Kaz Kylheku <433-929-6894@kylheku.com> writes:
On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
arnold@freefriends.org (Aharon Robbins) writes:
In article <usqkgn$he7u$2@dont-email.me>,
Ed Morton <mortonspam@gmail.com> wrote:
the effect of setting `NF` is
undefined behavior per POSIX and so will do different things in >>>>>>different awk variants and even in 1 awk variant can behave differently >>>>>>depending on whether you're setting it to a higher or lower than >>>>>>original value
This is not true. The effect of setting NF was well defined
by the original awk book and also in POSIX.
Decreasing NF throws away fields. Increasing NF adds the
intervening fields with the null string as their values
and rebuilds the record.
I don't see that in the POSIX specification.
The key is this:
References to nonexistent fields (that is, fields after $NF), shall
evaluate to the uninitialized value.
NF is assignable, and fields after $NF do not exist. Thus if we
have four fields and set NF = 3, then $4 doesn't exist.
That describes what happens if NF is modified by assignment, but I don't
see that it implies that such an assignment is allowed.
"The left-hand side of an assignment and the target of increment and decrement operators can be one of a variable, an array with index, or a
field selector."
NF is described as a variable. Some unique remarks are made about NF,
but none deny that it's assignable like any other variable.
But I can imagine a hypothetical awk-like language in which assigning to
NF has undefined behavior. My question is, how does the POSIX
specification not describe that language?
That language is failing to support an instance of a variable
being the left operand of an assignment, which a variable "can be".
It looks like the violation of a requirement.
Do you see something in POSIX that defines the behavior of assigning to
NF?
In article <87y1am5cfo.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Do you see something in POSIX that defines the behavior of assigning to
NF?
In the section "Variables and Special Values"
| References to nonexistent fields (that is, fields after $NF), shall
| evaluate to the uninitialized value. Such references shall not create
| new fields. However, assigning to a nonexistent field (for example,
| $(NF+2)=5) shall increase the value of NF; create any intervening fields
| with the uninitialized value; and cause the value of $0 to be
| recomputed, with the fields being separated by the value of OFS. Each
| field variable shall have a string value or an uninitialized value when
| created.
It doesn't say what happens when you do NF -= 2; nonetheless, all
traditional awks throw away fields when you do something like that.
In article <87y1am5cfo.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Do you see something in POSIX that defines the behavior of assigning to
NF?
In the section "Variables and Special Values"
| References to nonexistent fields (that is, fields after $NF), shall
| evaluate to the uninitialized value. Such references shall not create
| new fields. However, assigning to a nonexistent field (for example,
| $(NF+2)=5) shall increase the value of NF; create any intervening fields
| with the uninitialized value; and cause the value of $0 to be
| recomputed, with the fields being separated by the value of OFS. Each
| field variable shall have a string value or an uninitialized value when
| created.
It doesn't say what happens when you do NF -= 2; nonetheless, all
traditional awks throw away fields when you do something like that.
On 3/14/2024 1:19 AM, Aharon Robbins wrote:
In article <87y1am5cfo.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Do you see something in POSIX that defines the behavior of assigning to
NF?
In the section "Variables and Special Values"
| References to nonexistent fields (that is, fields after $NF), shall
| evaluate to the uninitialized value. Such references shall not create
| new fields. However, assigning to a nonexistent field (for example,
| $(NF+2)=5) shall increase the value of NF; create any intervening
fields
| with the uninitialized value; and cause the value of $0 to be
| recomputed, with the fields being separated by the value of OFS. Each
| field variable shall have a string value or an uninitialized value when
| created.
It doesn't say what happens when you do NF -= 2; nonetheless, all
traditional awks throw away fields when you do something like that.
It doesn't say what happens when you do NF += 2 either. All I'm saying
is that changing the value of NF is undefined behavior per POSIX.
I'm not sure which awks would be considered "traditional" vs otherwise
but AFAIK POSIX is descriptive, i.e. describes how X behaves rather than dictates the behavior of X, so if the appropriate set of awk variants
all behave the same way for any behavior such as this that's currently undefined by POSIX (changing the value of NF, the value of $0 in the end section, and field splitting with a null FS being the 3 most commonly
used cases IMO) then maybe the folks who write that spec could/should
update it to describe that behavior but I don't know which awks all
behave the same way for those cases, nor if that's enough of them for
POSIX to make a definition.
Ed.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 920 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 106:52:54 |
| Calls: | 12,190 |
| Calls today: | 2 |
| Files: | 186,527 |
| Messages: | 2,237,555 |