Re: another gawk 3.1.2 bug

[Aharon Robbins]

Greetings. Re this:

> Date: Wed, 16 Apr 2003 00:30:23 -0700
> From: "John H. DuBois III" <address@hidden>
> To: address@hidden
> Subject: another gawk 3.1.2 bug
>
> Under SCO OpenServer 5.0.6a and linux, this program:
>
> BEGIN{cmd = "cat /etc/termcap"; cmd | getline; print close(cmd); }
>
> (where /etc/termcap is any file large enough that it will not fit in pipe
> buffers)
>
> correctly prints 141 (process killed by SIGPIPE) under gawk 3.1.1.
> Under gawk 3.1.2 (built with gcc 2.95.3 & 3.2.2), it prints 13; the high bit
> (indicating that the process exited due to receipt of a signal) is being lost.
>
> Some further problems with the return value from close:
>
> $ gawk-3.1.2 'BEGIN{cmd = "exit 1"; cmd | getline; print close(cmd); }'
> 256
>
> $ gawk-3.1.2 'BEGIN{cmd = "exit 2"; cmd | getline; print close(cmd); }'
> 512
>
>       John
> -- 
> John DuBois  address@hidden  KC6QKZ/AE  http://www.armory.com/~spcecdt/

This whole situation is a mess.  In 3.1.2, I changed close() to return
the full 16-bit exit status from the wait() system call. (I did document
this in the manual.)

Thus the '13' is the value for SIGPIPE, 256 represents `exit 1'
and 512 the `exit 2', as the exit status is in the high 8 bits.

POSIX simply says that the return value is 0 for success, non-zero
otherwise, indicating that there is no way to gain access to the various
bits of info.  I will probably make this the case for POSIXLY_CORRECT,
and leave things as is otherwise.

I made the change because of various portability issues to non-POSIX
systems etc etc etc a-never-ending-headache-you-don't-wanna-know-about-it.
I note that Brian Kernighan's awk acts like the current gawk; mawk acts like
3.1.1.

I don't know what The Right Thing To Do is, nor do I see a clean way
to make everyone happy.

Sorry,

Arnold