Re: remove some POSIXLY_CORRECT dependencies from coreutils

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> 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.
>
> That's reasonable, but the current usage is so awkward that I wonder
> whether anybody'd want to do it.  As I understand it, if you want to
> exec a 'true-with-any-arguments' command, you need something like this:
>
>      setenv ("POSIXLY_CORRECT", "", 1);
>      execlp ("true", "true", arg1, ..., argn, (char *) 0);

That's certainly cumbersome.
I was thinking more along the lines of

  POSIXLY_CORRECT=1; export POSIXLY_CORRECT

with

  exec $cmd $args
or
  nice $cmd $args
or
  xargs $cmd $args < input

where $cmd might be set to something functional or to `true'.

But in the absence of arguments to the contrary,
I'll go ahead and make the changes you suggest.

> But that's tricky, and it's not portable code in general, as POSIX
> doesn't promise that "true" does nothing if you pass it arguments.
> How about recommending this instead?
>
>      execlp ("sh", "sh", "-c", ":", arg1, ..., argn, (char *) 0);
>
> This is shorter and simpler, and POSIX says it's portable.
>
>> 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.
>
> If the above argument hasn't convinced you, and you still prefer
> having "true" behave differently based on some environment variable,
> how about using a different environment variable, e.g.,
> IGNORE_HELP_AND_VERSION?  That would remove the misleading bit.....
> But now that I write this, I think I am going off the deep end.  Let's

:-)

> just have "true" either always ignore "--help" and "--version", or
> always obey them.  I don't much care which, but I think an environment
> var is overkill here.
>
>
>> As for `yes', shouldn't there be a way to make it print `--h', `--help'
>> or `--version' repeatedly?
>
> Sure, but that should be "yes -- --help".  Hmm, I see this isn't
> working correctly now, and there are a few other commands that
> mishandle "--" (including chroot, hostid, hostname).  Here's a patch
> to fix this.

For each vendor version of yes that I checked, `yes --' prints `--'.
But with your patch, it'd print `y'.  How about the slightly different
patch below for yes.c?  I haven't looked at the others.

E.g. `yes -- |head -n1' prints `--' on Solaris, NetBSD, OpenBSD and HPUX.
There is less agreement on what `yes -- --' should do.  Solaris and NetBSD
print `-- --' while OpenBSD and HPUX print just `--'.

Index: yes.c
===================================================================
RCS file: /fetish/cu/src/yes.c,v
retrieving revision 1.53
diff -u -p -r1.53 yes.c
--- yes.c       21 Jan 2004 23:50:38 -0000      1.53
+++ yes.c       15 Jun 2004 22:21:41 -0000
@@ -71,10 +71,16 @@ main (int argc, char **argv)
 
   atexit (close_stdout);
 
-  /* Don't recognize --help or --version if POSIXLY_CORRECT is set.  */
-  if (getenv ("POSIXLY_CORRECT") == NULL)
-    parse_long_options (argc, argv, PROGRAM_NAME, GNU_PACKAGE, VERSION,
-                       usage, AUTHORS, (char const *) NULL);
+  parse_long_options (argc, argv, PROGRAM_NAME, GNU_PACKAGE, VERSION,
+                     usage, AUTHORS, (char const *) NULL);
+
+  /* The above handles --help and --version.
+     Since there is no other invocation of getopt, handle `--' here.  */
+  if (2 < argc && STREQ (argv[1], "--"))
+    {
+      --argc;
+      ++argv;
+    }
 
   if (argc == 1)
     {

BTW, does some standard specify how `yes' must behave?

> (My CVS doesn't have any changes to NEWS and
> doc/coreutils.texi so this patch includes the same fixes as before for
> those, along with new changes for the "--" stuff.)

That was an oversight.
I've just checked them in.