Sujet : Re: Breaking a table of record rows into an array
De : 433-929-6894 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.awkDate : 13. Mar 2024, 19:24:37
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20240313110839.989@kylheku.com>
References : 1 2 3 4 5 6
User-Agent : slrn/pre1.0.4-9 (Linux)
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.
I reproduced the behavior carefully in the awk macro of TXR Lisp:
$ echo '1 2 3 4' | txr -e '(awk (t (set nf 1) (set nf 3) (prn [f 1])))'
$ echo '1 2 3 4' | txr -e '(awk (t (set nf 3) (prn [f 1])))'
2
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.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca