Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils