This problem with awk(1) regexp working incorrectly was reported to NetBSD by Aleksey Cheusov and it was fixed there. http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=39133 FreeBSD version still has this bug: zhuzha:~% echo supertable | awk -Ft '{print $1, $2}' supertable zhuzha:~% echo -e "super\ttable" | awk -Ft '{print $1, $2}' super table Fix: See the attached patch adopted from NetBSD (PR/39133: cheusov at tut dot by: Don't treat -Ft as -F <tab>). Patch attached with submission follows: How-To-Repeat: echo supertable | awk -Ft '{print $1, $2}'
it seems the netbsd folks however didn't report this isse upstream. i'll contact Brian Kernighan and see if he wants to fix this bug in the upstream awk version. if that works out i might try getting the other awk-related patches the netbsd folks came up with committed upstream. cheers. alex -- a13x
Responsible Changed From-To: freebsd-bugs->arundel Over to me. I'll try to get this one committed upstream. Stay tuned. ;)
unfortunately i wasn't able to find Brian Kernighan's current email address. the old atlabs one bounces. can somebody help me out here? cheers. alex -- a13x
Responsible Changed From-To: arundel->freebsd-bugs Back into the pool, since i was not able to contact Brian Kernighan.
for the record: i talked to Brian Kernighan (his current mail address is bwk at CS dot Princeton dot EDU btw). he seems like a nice guy, but quite obviously is more of a thinker and not that much of a do'er. ;) chances this will get fixed upstream are very slim imo. this is what he had to say: Hi -- That behavior is a feature, not a bug, though it's kind of embarrassing in hindsight. It was meant to make it really easy to do the most common exceptional case, but it sure is kludgy. I'm torn. Brian cheers. alex -- a13x
Warner is checking out some awk changes from NetBSD.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
The 20210221 version still behaves this way.
I'll see if I can get upstream interested in this. gawk does as you suggest.
I've created a pull request upstream https://github.com/onetrueawk/awk/pull/123 for this issue.
(In reply to Warner Losh from comment #10) The deltas are tiny enough, though, we could carry them as a local mod.
I just checked NetBSD and they have reverted this change as well and maintain the historic t->\t wart now. I'll wait to see what upstream has to say about my pull request..
https://github.com/onetrueawk/awk/pull/124 is the new pull request: I had to redo it to base it on staging rather than master branch.
Upstream seems poised to accept this change. I believe 12.x and 13.x should accept the wart and warn, while 14 should not accept the wart at all, since that's the direction upstream seems to be headed if I'm reading the tea leaves correctly.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>