GNU Awk 5.0
lists.gnu.org
lists.gnu.org
$ ./bin/gawk -V | head -n 1
GNU Awk 5.0.0, API: 2.0
$ ./bin/gawk 'for (i = ) in steve kemp rocks'
gawk: cmd. line:1: for (i = ) in steve kemp rocks
gawk: cmd. line:1: ^ syntax error
gawk: cmd. line:1: for (i = ) in steve kemp rocks
gawk: cmd. line:1: ^ syntax error
gawk: cmd. line:1: fatal error: internal error
Aborted (core dumped)
Nicely found!
https://bugs.debian.org/816277
I appreciate that most of the time reporting directly is the right thing to do, but often there is a good relationship between packager and developer and things flow well in both directions.
I guess I should make sure I chase old reports and reroute if they seem to be orphaned/ignored/overlooked.
Maybe try sending an email? I agree that reporting to the Debian packager often works, but in this case it's possible they just have too many things to triage appropriately.
Edit: Too late I see it was already reported before the release and apparently wasn't regarded as significant:
http://lists.gnu.org/archive/html/bug-gawk/2019-04/msg00015....
I guess that means no fix.
Sometimes I go through things, but its easy to think you've done your part if you submit a bug report, a reproducer, and even a patch.
I'd expect that once a patch is there and it is consistent it would be applied, whereas just reporting what a fuzzer finds is not too helpful.
By the way, we've all seen the XKCD about competing standards before.
From the GNU Awk 5 manual: A qualified name consists of a two simple identifiers joined by a double colon (::). The left-hand identifier represents the namespace and the right-hand identifier is the variable within it.
Namespaces are a big help for writing libraries, especially for clients with systems (e.g. banking, government, education, medical) where awk code is fine yet other kinds of languages (e.g. python, go, perl) are not available and/or require management audit practices.
I've written the previous comment asking "why namespaces based" only on the directly online accessible info. Now having had the time to download and unpack the sources and read the documentation there, it sounds much better than it appeared based on the announcement.
Long term it shouldn't make gawk less compatible than it already is. Gawk already has gawk-specific extensions, and that would be one. It seems that the command-line example is the only "breaking" aspect. And even that could be theoretically modified to be non breaking, but it's hopefully seldom enough used to not affect too much.
And the "namespaces" is in fact a "module" infrastructure extension, introduced specifically to support the construction of module-like libraries (specifically solving the problem of exporting the limited number of variables from the module).
I especially like the writing of the author of Gawk manual, I've really enjoyed it even almost thirty years ago.
If it is Java or C# and already in-use, it is pretty simple. If I wanted to install a Go compiler, it could get complicated. Not having Admin rights really slows down an organization. Especially if you're someone who likes to use multiple technologies (right tool for the right job). IT hates that. Note that I don't write production tools, just things to get my job done quicker (automation scripts, data analysis...etc).
not figuratively
11. Namespaces have been implemented! See the manual. One consequence of this
is that files included with -i, read with -f, and command line program
segments must all be self-contained syntactic units. E.g., you can no
longer do something like this:
gawk -e 'BEGIN {' -e 'print "hello" }'It could be that I have missed a detail and this isn't really the case; I also certainly don't want to discourage progress, but there is something to be said for being able to write an awk program once and be confident it will work on any POSIX-ish system, rather than only those with a GNU userland.
1 - http://pubs.opengroup.org/onlinepubs/9699919799.2018edition/
My port of gawk to MacOS in 1990/91 was my first active involvement in open source. I was rather crushed when told that my patches would not get accepted, because RMS at the time had a Fatwa against accepting MacOS code in GNU projects, and, though the gawk maintainers were quite civil about it, it was clear that they would not go against RMS' wishes.
Shortly afterward I discovered perl, so I never did all that much awk, and when a few years ago, I decided a 5 line awk script was the most elegant way to solve a configuration problem, my coworkers vetoed the plan.
I kind of skipped over it in my journey into the world of Unix... I usually either (bash shell scripting, tools like cut and grep + pipes and redirection) or use python.
The Aho and Kernighan book is amazing.
For gawk, the manual covers the gaps between the language introduced in the book and the latest implementation.
https://9p.io/7thEdMan/v7vol2b.pdf (starting on page 105)
That's my kind of changelog. I, too like to live dangerously.
Will do.
A little slack would be nice.
Sadly it does not rain maintainers everywhere, especially when the role does not pay.
> This is a major new release, with new or improved features, including namespaces. The relevant part of the NEWS file is appended below.
So you would be happier to have the item as number 1 rather than 11 in the list further down?
> 11. Namespaces have been implemented! See the manual. One consequence of this is that files included with -i, read with -f, and command line programsegments must all be self-contained syntactic units. E.g., you can no longer do something like this:
gawk -e 'BEGIN {' -e 'print "hello" }'
Apart from that it would have been nice with a reference to what section of the manual to look at. Especially as https://www.gnu.org/software/gawk/manual/ still references 4.2 (will probably be updated soon).
Who needs that and what’s the point? Any compatibility breakage in awk should start wit “negative points” so what are the positive ones to even qualify it as desired?
Brian Kernighan is also cited there, and also not convinced.
I’m in a good company, at least.