Re: mktexpk: non-POSIX compliant use of "tail"

[Karl Berry]

    _POSIX2_VERSION in <unistd.h>, in descending order of importance.

One of the great things about GNU software in the past was that it
basically behaved the same (as much as possible) independent of the host
system.  It did not gratuitiously change behavior based on system
settings.

Thus, it seems like this new reliance on _POSIX_VERSION to determine
functionality (installation options are no problem) is a step backwards.
Thomas has coreutils 5.3.0 on a relatively modern (GNU/)Linux system.  I
have coreutils 5.3.0 on a relatively modern (GNU/)Linux system.  Yet
they behave noticeably differently.  This never used to be the case.  I
can't see who it helps to do it this way.

Determining whether something like tail -10 is supported seems like a
choice that could be made by the system builder, eg, someone at Red Hat;
and then, isn't it better if individuals installing
coreutils-5.3.0.tar.gz always get the same behavior, regardless of what
the system builder decided?  I can't think of any other package that
behaves like this.

    A simple portable equivalent to "tail -1" is "sed -n '$p'".

That sounds like an excellent answer for mktexpk.  Thanks.

    (You weren't persistent enough.  :-)

I never even got an automated acknowledgement on any comment I sent on,
let alone any human feedback, so I figured it was a black hole, and
stopped bothering.

    [compromise]

Well, I'm glad to hear it, I guess, although from what you describe the
result is nearly nil.  And tail -1 is just one example.

    It's worth emphasizing that this compromise wouldn't affect portable
    POSIX applications, as they still won't be able to rely on "tail -1".

You don't want to hear this, just ignore me, but I can't stop myself
from saying it one more time.

<flame on>
POSIX was supposed to be about portability and unifying the different
Unix variations.  It did a good job for many years.  Then, IMHO, it
should have disbanded.  But no, it had to go on and start prescribing
new behavior the way Unix "should" have been design, instead of
codifying existing practice of the way Unix *is*.  As a result, these
backward-incompatibilities in recent versions of POSIX have vastly
*decreased* portability and usability.  In the past, tail -10 worked.
It always worked.  It worked on every Unix system anyone cared about (at
least the couple of dozen or so that I used).  Then POSIX comes along,
and, *in the name of portability*, says oh no, you've been doing it
wrong all these years, now you must use tail -n 10.

The result is bad for everyone.  tail -n 10 cannot be used in truly
portable scripts (as opposed to merely "POSIX" portable ones), because
it will not work on older systems.  tail -10 cannot be used because it
won't work on new systems that strictly conform to POSIX's madness.  So
nothing can be used.  And this is an improvement?

Well, nothing can be done about POSIX, but then there's the whole GNU
situation.  GNU is supposed to be about what is best *for users*.  Not
blindly kowtow to standardized stupidity.  The coding standards
explicitly say this.  And yet one of the important packages in GNU is
also one of the most POSIX-submissive.  What harm can there be in *GNU*
tail always accepting tail -10?  I do not buy the "you have to support
only the strictly POSIX way or you encourage unportability" argument;
indeed, it seems to me that if you do it the strictly POSIX way you are
*maximizing* the chance of being unportable.

Oh well, you and Jim have heard all this stuff from me too often
already, and I know you don't agree, and no one else can do anything
about it.  I'll shut up now (I can hear the sigh of relief :) and go crawl
back into my hole.
<flame, and everything else, off>

karl