[ On Friday, February 2, 2001 at 10:07:11 (-0500), Todd Vierling wrote: ]
> Subject: Re: README: nawk vs. gawk
>
> Greg, the world of NetBSD users does not consist of just you, so please stop
> assuming it is.  I don't give a damn about your "One True Awk" nonsense;
> what I do care is that we don't cause problems for NetBSD users -- the real
> ones with real production systems who aren't ranting about the purity of a
> tool relative to Unix's history.

If you paid attention to what I wrote you'd have seen that there is a
perfect working solution *NOW* for any NetBSD user who needs GNU Awk
features.  If they can't figure out *when* then need to install and use
GNU Awk then none of us can help them.

As for "purity", well if GNU Awk was as fast, small, and efficient as
the real awk then I probably wouldn't have chosen it as an early
candidate for my own experiments at replacing a base system tool.  I
initially considered 'mawk' because I've always liked it best, even
beyond 'nawk'.  I also wanted an 'awk' statically linked in /bin, but I
wasn't going to get any gain with either gawk or mawk, and ultimately
the decision to go back to "The One True Awk" was obvious and painless.
If it wasn't the best available open-source 'awk' for use in a *BSD base
system then I would have ignored it.

> If we break compatibility in a way that causes misoperation, we are doing a
> massive disservice to our commitment to backwards compatibility.  At the
> very least, we must make a big and loud statement about the change on lists,
> in release notes, as far and wide as it can go.  But it'd be far better if
> we trap the GNU extension cases and cause human-readable errors indicating
> the failure.

If you'd take the time to try some GNU Awk-isms with nawk then I think
you'd find that you're only imagining a problem that does not exist.
How else do you think I found and reported all of the errors I found in
the base system and pkgsrc?

Certainly the change must be highlighted in the new release
announcements, release notes, and the documentation itself, but I would
expect that's a given anyway, and in fact half the announcement has
already effectively been made.

It's not such an important problem as you seem to think it is, and
certainly without any outcry of complaints against the new awk there's
no need to go out of "our" way to cater to problems that don't exist.
Certainly if a larger number of -current users start complaining that
their local awk-using programs are failing to work with the new awk then
this issue needs to be re-addressed, but until then it's just a
pointless waste of time.  The process is presumably under way and the
results are already arriving (though mostly it seems there's been just
silent approval, at least on the public lists).

> The only other alternative is to link /usr/bin/awk to /usr/bin/nawk ONLY IF
> there is no /usr/bin/awk already installed on the machine (for upgrades, of
> course).  This would leave gawk as /usr/bin/awk on upgraded machines, but
> install nawk on freshly installed machines.

What a nightmare mess that would create!  YUCK!

No, the only correct optional choice for upgrades would be to rename
/usr/bin/awk to /usr/bin/gawk and to install the new awk as /usr/bin/awk.

It was probably a mistake to install GNU Awk as awk in the first place.
It should always have been called 'gawk', and 'awk' should always have
been the equivalent of 'gawk --posix'.  But of course hindsight is 20/20.

As I've mentioned, I've moved awk to /bin and linked it statically on my
development systems because I've found it to be extremely useful in
single-user mode (eg. in rc scripts) and with the new awk its size is
not nearly such a problem (on i386 it's only 174672 bytes after
stripping, less than half the size of sh or ksh).  With /bin/awk you
don't need /bin/sed, or really even /bin/fgrep (though I've the latter
now too).  It also seems (and probably is) much faster to use
intensively in a script if it's statically linked....

(BTW, even my choice of moving awk to /bin has only caused problems with
base NetBSD tools -- 99.9% of third-party code that I've encountered
which uses awk, including all my own older code, is just as happy to
find it there....)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>