Re: nawk-20230911 problem

[Greg Troxel <gdt%lexort.com@localhost>]

Paolo Vincenzo Olivo <vins%netbsd.org@localhost> writes:

> Apparently nawk 2nd edition (20230911) expects input to be UTF-8
> encoded, and won't parse octal-encoded DER certificates. See the BUGS
> section in the latest nawk(1). 
> I think this represents a major breakage in awk behavior, and probably
> needs to be addressed with regard to the pkgsrc use case, considering
> how critical the package is. 

Indeed; thanks for pointing that out.

> Now, in my opinion the most rational way to work this out - at least for
> pkgsrc-2023Q3 - is to downgrade lang/nawk to 20230909, and package
> 20230911 separately, as lang/nawk2 or lang/awk2 (with distfiles to be
> fetched remotely). Does this look reasonable?

Certainly, I think it makes sense tto change lang/nawk to be a version
compatible with traditional awk.

Whether we add awk2 right now, or we defer for more thought discussion,
is another matter.

What does POSIX say?  Is awk2 non-compliant?  Is awk UB if not on ASCII
only?

pkgsrc needs to define how the awk tool behaves.  I don't see any
approach being reasonable other than defining an awk(1) tool, and then
defining an awk2 tool if packges are going to need awk2.