bug-coreutils
[Top][All Lists]
Advanced

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

Re: POSIX misunderstanding


From: Paul Eggert
Subject: Re: POSIX misunderstanding
Date: Thu, 19 Aug 2004 10:55:50 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Albert Cahalan <address@hidden> writes:

>> Guideline 3 says "Multi-digit options should not be allowed."
>> That's an explicit prohibition.
>
> I meant, where is --lines allowed,

It's a different syntax, that is not addressed by the guidelines.

> "Each option name should be a single alphanumeric character"

That is talking about the standard option syntax, which starts with
"-" followed by the option name.  The long option syntax is a
different syntax, which isn't addressed by the guidelines.  Long
options are a pure extension to POSIX: "-" cannot possibly be an
option name, since "--" is reserved by the standard.

> How likely do you think it is that Sun and HP will drop the "head
> -42 ..." syntax?

Sun doesn't claim POSIX conformance for its default Solaris
environment.  Solaris does have a POSIX environment, but it's rarely
used, and I suspect few people care about what happens in it so long
as it passes the existing validation suites.  I expect HP is similar.

> the important thing is that nobody gets misled into choosing this

The issue is discussed in the top-level README file (in the "These
programs are intended to conform to POSIX" paragraph) and in the
manual (the "Standards conformance" section).  Please feel free to
suggest improved wording to the documentation.

> You could require that POSIXLY_CORRECT....

That's been suggested before, but POSIXLY_CORRECT is for a different
purpose: it's for nitpicky details like whether "ls . -l" treats "-l"
the way that POSIX requires.  The idea is that few ordinary people
would want to set POSIXLY_CORRECT.

The problem we're talking about is a different problem, since it's
affected by the choice of POSIX version, and people might reasonably
want either the old or the new behavior.

> Perhaps a correction to the standard is in order,

I've suggested that to others.  See:
<http://lists.gnu.org/archive/html/bug-coreutils/2003-11/msg00023.html>.
However, nobody has bothered, and personally I don't think it's
important enough to bother.




reply via email to

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