[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tail +16c syntax

From: Paul Eggert
Subject: Re: tail +16c syntax
Date: Thu, 10 Nov 2005 13:59:57 -0800
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Eric Blake <address@hidden> writes:

> http://www.opengroup.org/austin/docs/austin_239.html mention that the
> intent is to 'add to the OPTIONS "except that '+' may be recognized as an
> option delimiter as well as '-'.'

That won't happen for quite some time (my guess is not until 2007),
and in the meantime a conforming POSIX 1003.1-2001 (or later)
implementation is supposed to treat leading "+" as a file name, not as
an option delimiter.  When the next POSIX standard comes out we can
revisit the issue.  Some people use file names beginning with "+", so
we can't make everybody happy here.

In the meantime GCC's scripts should not assume "tail +16c" has the
obsolete meaning, since that usage is not portable in practice.
(There's a similar problem with "tail -1", though this latter problem
is no longer an issue with coreutils 5.93.)

If people can't build GCC due to its maintainers' insistence on using
obsolete syntax, there's a simple workaround: set
_POSIX2_VERSION=199209 in their environment, if that isn't the default

As I understand it the main obstacle in the past to fixing GCC's
scripts was Zack Weinberg's insistence on the old syntax.  However,
Zack no longer does GCC development, no?  Has someone else in the GCC
group taken up the torch of insisting on unportable and obsolete
syntax?  (I was amused at the time that Zack championed the removal of
support for obsolete and unportable syntax from the language that GCC
accepts, while at the same insisting on using obsolete and unportable
syntax when invoking other programs.  :-)

Please feel free to forward this to the bug-gcc thread if you think
that will help explain matters.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]