Re: another gawk 3.1.2 bug

[Paul Eggert]

Aharon Robbins <address@hidden> writes:

> 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.

Sorry, I don't follow.  gawk 3.1.2 already conforms to POSIX here, as
did gawk 3.1.1 (in a different way).  So I don't see why
POSIXLY_CORRECT should affect gawk's behavior here, unless you're
thinking of having gawk behave a third way by default, a
non-POSIX-compliant way that is different from both 3.1.2's way and
3.1.1's way.  But surely you're not thinking of doing that.

> 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.

I tend to think that Kernighan's awk (which is the original, and which
is still a live implementation) should outweigh mawk (which seems to
be dying if not dead).

One possibility would be to give gawk users the whole WEXITSTATUS /
WIFEXITED / etc. set of macros.  This sounds a bit extreme, though.

If we had to do it over again, I'd say that system() should return the
full 16 bits too, for consistency with close().  I suppose it's too
late for that, though.