Subject: Re: Awk change in 1.3.2
To: Terry Moore <tmm@mcci.com>
From: Klaus Klein <kleink@ira.uka.de>
List: tech-userlevel
Date: 08/05/1998 19:17:33
tmm@mcci.com (Terry Moore) writes:

> We've upgraded from (i386) 1.0, and I am putting the first machine 
> into production use.
> 
> We have a number of awk scripts with the construct
> 
> 	' { blah blah } END {print}'
> 
> in them.  The intent is to get an extra newline at the end of the
> output file.  (For example, '{ printf("%s\\\n", $1) } END {print}' 
> extracts the first field, puts backslashes at the end of each line,
> and prints an extra newline.  Good for building makefiles, which is
> what I'm doing.
> 
> This works great in SunOS 4.1.3 (awk/nawk) and in 1.0 (which has
> gawk 2.15 pl 5).
> 
> For example,
> 	echo foo | awk 'END {print}'
> prints nothing.
> [...]
> 1.3.2 has upgraded to 2.15 pl 6.  This version has a different behavior,
> which may or may not be intended:
> 
> 	echo foo | awk 'END {print}'
> 
> prints 'foo'.
> 
> [...]
> 
> I think this is a bug; it's certainly an annoying compatibility problem.
> It looks like it was on purpose:  
> 
> In usr.gnu/gawk/NEWS, toward the end of the list of enhancements for 2.15.6:
> 
> 	Major enhancement: $0 and NF for last record read are now preserved
> 	into the END rule (io.c).
> 
> This, of course, is what I'm seeing.  Unfortunately, it breaks a lot of our 
> scripts.

Wearing my standards hat, I've done a bit of research on this issue,
which has also been subject to previous discussion outside the NetBSD
project.  It effectively boils down to the following quotation, taken
from the IEEE response to 1003.2-1992 Interpretation Request #107:

  " ... [the standard] does not place any requirements on $0 within an
   END action, therefore, the standard allows both behaviors provided
   by gnu awk, and unix awk."


I don't know about the project's current roadmap with respect to the
awk implementation shipped (GNU awk might be replaced with AT&T/Lucent
awk, which would probably fix your particular problem), but in your
case the culprit is that your scripts contain non-portable (within the
limitations of POSIX) assumptions.


-- Get your official NetBSD-1.3.2 CDROM set today! http://www.netbsd.com/ --