Re: awk problem

[Simon Burge <simonb%wasabisystems.com@localhost>]

Frederick Bruckman wrote:

> On Thu, 25 Mar 2004, Shin'ichiro TAYA wrote:
> 
> > In the script above, awk uses following expression.
> >
> >    awk 'BEGIN { printf "\x00\x52\x50\x4f" }
> >
> > It seems that nawk doesn't support this but gawk does.
> >
> >    % awk 'BEGIN { printf "\x00\x52\x50\x4f" }' | hexdump -C
> >    %
> >
> >    % gawk 'BEGIN { printf "\x00\x52\x50\x4f" }' | hexdump -C
> >    00000000  00 52 50 4f                                       |.RPO|
> >    00000004
> >    %
> >
> > Is this a problem of nawk ?
> > Or is this a GNU awk specific extention?
> 
> Actually, the hex escapes are a non-POSIX extension, but it does work
> as long as you leave out the "\x00". POSIX says the behaviour is
> undefined if you try to output an ASCII NUL via a backslash escape
> followed by all zeroes (e.g. "\000"). POSIX doesn't have anything to
> say about "\x" escapes. Gawk does what you seem to expect anyhow, but
> nawk does not.
> 
> To get a NUL in the output stream, you could use a placeholder, then
> transform it using "${TR}". E.g.:
> 
> awk 'BEGIN { printf "\177\122\120\117" }' \
> | tr '\177' '\000' | hexdump -C
> 00000000  00 52 50 4f                                       |.RPO|
> 00000004

First, some background.

The goal here was to use something in the tree do produce some output so
that we didn't need yet another host tool.  IBM's OpenBIOS requires the
following struct at the start of a boot image:

        typedef struct boot_block {
                unsigned long   magic;
                unsigned long   dest;
                unsigned long   num_512blocks;
                unsigned long   debug_flag;
                unsigned long   entry_point;
                unsigned long   reserved[3];
        }

where:

        magic:          must be 0x0052504f
        dest:           target address for image
        num_512blocks:  number of blocks
        debug_flag:     zero to run image, non-zero to go to debugger
        entry_point:    address where the image will receive control

I've just committed a fix to this, and another problem I found using
nawk.  Probably easier to just include the commit message here:

  Pass the OpenBIOS magic number to the awk script just like the other 
  numbers passed in instead of using a BEGIN construct.  nawk didn't like
  the hex escapes used there.
  Fixes a problem reported by Shin'ichiro TAYA on port-powerpc.

  Use "int(NUMBER)%256" instead of just "NUMBER" in the printf "%c"
  statements in the awk script.  nawk was appearing to refuse outputing 
  a 0 byte of the low eight bits of the number were 0 but any higher 
  bits were set.

  walnut-mkimg.sh tested using gawk, nawk and mawk.

The walnut-mkimg.sh script still uses printf(1).  Can we assume that
exists on every system used to build netbsd these days?  I'm thinking
of things like cygwin, etc.  Also older BSDs in particular didn't have
printf(1).  The use of printf is not fancy - it could easily be replaced
by multiple echo's.

Simon.
--
Simon Burge                            <simonb%wasabisystems.com@localhost>
NetBSD Support and Service:         http://www.wasabisystems.com/