Re: remove some POSIXLY_CORRECT dependencies from coreutils

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> In a few cases, the default coreutils behavior conforms to POSIX, but
> coreutils changes its behavior if POSIXLY_CORRECT is set.  Here is a
> patch to remove these special cases; this lessens the effect of
> POSIXLY_CORRECT on coreutils behavior.  This patch affects behavior
> only when POSIXLY_CORRECT is set.
>
> 2004-06-09  Paul Eggert  <address@hidden>
>
>       * NEWS: Remove special cases for POSIXLY_CORRECT when POSIX allows
>       the GNU behavior.
>       * doc/coreutils.texi (pr invocation, unlink invocation, false
>       invocation, true invocation): Document this.
>       * src/ls.c (decode_switches): Pay attention to TABSIZE even if
>       POSIXLY_CORRECT is set.  POSIX reserves upper-case environment
>       variables to the implementation, so it's OK for ls to depend on
>       TABSIZE.
>       * src/pr.c: Include "hard-locale.h".
>       (main): When in a non-POSIX locale, ignore POSIXLY_CORRECT, since
>       POSIX specifies the behavior only in the POSIX locale.
>       * src/printf.c (print_esc): Support \x, \u, \U even if POSIXLY_CORRECT,
>       since POSIX says the behavior is unspecified here.
>       * src/tail.c (parse_obsolescent_option): Support multiple file operands
>       even if POSIXLY_CORRECT, since POSIX does not require a diagnostic.
>       * src/printf.c (main): Recognize --help, --version even if
>       POSIXLY_CORRECT.  POSIX does not specify any options, but it
>       does not prohibit options either, so "printf" is like "expr" here.
>       * src/true.c (main): Likewise.
>       * src/unlink.c (main): Likewise.
>       * src/yes.c (main): Likewise.
>       * tests/misc/printf: Adjust to the new semantics for \x if
>       POSIXLY_CORRECT.

Thanks, Paul!

I expect to apply most of those changes.
The only ones I don't like are those to true (and hence false) and yes.
I think true and yes should continue to provide
some mechanism for disabling interpretation of --help and --version.
For true, Peter Seebach made the point back in 1999[*] that one should
be able to use true-with-any-arguments as a no-op.  Sure, it's usually
better to use `:', but sometimes we need a command that can be `exec'd.

As for `yes', shouldn't there be a way to make it print `--h', `--help'
or `--version' repeatedly?  With the current code, setting POSIXLY_CORRECT
in the environment is currently the only way to do that.

I do admit that the name POSIXLY_CORRECT is at best misleading in these
cases, now that I see the behavior it disables is permitted by POSIX.

[*] in a message that I didn't find in public archives:

  Message-Id: <address@hidden>
  From: address@hidden (Peter Seebach)
  To: address@hidden