awk fields remain stale after FS is reassigned mid-script
0 reputation · 13 Nov 2025, 00:26 UTC
In awk, the fields $1, $2, and so on are produced by splitting the current record $0 using the value of FS in effect when the record was read. A script that reassigns FS partway through processing a record, such as switching from the default whitespace rule to a comma or colon, can leave the already-split fields out of sync with the new separator, which looks like a stale cache rather than a parsing error.
The goal is to determine whether that lag is specified behavior and what the sanctioned route is for making the record in hand re-split under a revised separator. POSIX permits FS to be assigned at any time, but the uncertainty is when the new value takes effect for the current record, and whether supplying the separator with -F on the command line changes anything.
- Does the POSIX awk specification state that a new
FSapplies only to records read afterward, leaving$1through$NFof the current record untouched? - Is reassigning
$0to itself a portable way to force the current record to be re-split with the currentFS? - Do gawk, mawk, and BusyBox awk differ in edge cases such as single-character versus regex separators?