option abbreviation exceptions (was: Suggestion for rmdir)

[Eric Blake]

Eric Blake ebb9 at byu.net writes:

  Some of these programs recognize the @option{--help} and @option{--version}
 -options only when one of them is the sole command line argument.
 +options only when one of them is the sole command line argument.  For
 +these programs, abbreviations of the long options are not recognized.

In subsequent testing, I realized this is not entirely true.  Should I work on 
a followup patch that makes this sentence true?

For example,

$ /bin/echo --help --version | head -n1
--help --version
$ /bin/echo --help | head -n1
Usage: /bin/echo [OPTION]... [STRING]...
$ /bin/echo --he | head -n1
Usage: /bin/echo [OPTION]... [STRING]...
$ /bin/echo -n -e hi\\n | head -n1
hi

Certainly some inconsistent behavior.  echo takes multiple arguments, but only 
when they are the short options -[neE] (I guess it's okay that they don't have 
long-option variants?).  But when --help or --version is present, echo acts 
like it takes exactly one argument.  The usage text doesn't really portray 
that.  The other thing that is awkward is that we are recognizing 
abbreviations; it seems like it would make more sense for echo --he to 
output --he rather than the help text.  POSIX isn't much help here, either, 
as it only specifies that portable apps can't use -n (but says nothing about -
e), and we are already violating the (lame) POSIX requirement that -e be on by 
default, thus giving no guidance on whether we are better off requiring the 
user to write /bin/echo -ne instead of /bin/echo -n -e when they want both 
options.

Another case in point:

$ /bin/[ --help me | head -n1
/bin/[: missing `]'
$ /bin/[ --help | head -n1
Usage: test EXPRESSION
$ /bin/[ --hel | head -n1
Usage: test EXPRESSION

Should the last example also complain about missing `]', rather than printing 
help text?

-- 
Eric Blake




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: printf(1) does not support argument swapping

[Eric Blake]

Eric Blake ebb9 at byu.net writes:

 Thanks for the report.  POSIX does not require printf(1) to support
 argument swapping:
 http://www.opengroup.org/onlinepubs/9699919799/utilities/printf.html
 
 So this is technically not a bug.  However, if you would like to submit a
 patch that adds this as an extension, we will probably consider it for
 coreutils' printf.  If you want the bash builtin to also make this
 improvement, then bring that to the attention of the bug-bash list.

It looks like zsh already supports this extension, so there is prior art, which 
makes it all the more justifiable to add this to coreutils:

$ zsh -c 'printf %1\$s hi'
hi

-- 
Eric Blake




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: option abbreviation exceptions

[Eric Blake]

Eric Blake ebb9 at byu.net writes:

 Certainly some inconsistent behavior.  echo takes multiple arguments, but 
only 
 when they are the short options -[neE] (I guess it's okay that they don't 
have 
 long-option variants?).  But when --help or --version is present, echo acts 
 like it takes exactly one argument.  The usage text doesn't really portray 
 that.

Would this usage text be acceptable at better describing the situation?

Usage: /bin/echo [SHORT-OPTION]... [STRING]...
  or:  /bin/echo LONG-OPTION

Using 'git grep  OPTION', I've come up with this additional list of programs 
where I think we are inconsistent:

src/basename.c:  or:  %s OPTION\n\

'basename --help --version' is rejected, but not 'basename --hel'.  Should we 
treat basename --oops as equivalent to basename -- --oops, rather than 
causing an error?


src/chroot.c:  or:  %s OPTION\n\

$ chroot -- --hel
chroot: cannot change root directory to --: No such file or directory

Oops, there's a bug; the message should have mentioned --hel, not --.  
Meanwhile, should we treat chroot --oops like chroot -- --oops?


src/dd.c:  or:  %s OPTION\n\

'dd --help --version' is rejected, but not 'dd --hel'.


src/dirname.c:  or:  %s OPTION\n\

Similar to basename.


src/expr.c:  or:  %s OPTION\n\

'expr --help --version' is rejected (but with a different error than with other 
coreutils), while 'expr --hel' works.


src/factor.c:  or:  %s OPTION\n\

Unlike expr, 'factor --help --version' works.


src/hostid.c:  or:  %s OPTION\n\

'hostid --help --version' is rejected.  But perhaps this usage should be 
written in one line, instead of two:

Usage: hostid [OPTION]


src/hostname.c:  or:  %s OPTION\n\

Like dirname, should 'hostname --oops' be treated as 'hostname -- --oops'?


src/link.c:  or:  %s OPTION\n), program_name, program_name);

'link --help --version' is rejected, but 'link --hel' works.


src/nohup.c:  or:  %s OPTION\n\

'nohup --help --version' is rejected, but 'nohup --hel' works.  Also, 
should 'nohup --oops' behave like 'nohup -- --oops'?


src/printenv.c:  or:  %s OPTION\n\

'printenv --help --version' is rejected, but 'printenv --hel' works.


src/printf.c:  or:  %s OPTION\n\
src/printf.c:Print ARGUMENT(s) according to FORMAT, or execute according to 
OPTION:\n\

$ /bin/printf --help --version
--help/bin/printf: warning: ignoring excess arguments, starting with `--version'

Ouch.  This both printed to stdout, and to stderr.  It would have been nicer to 
keep the error but do nothing on stdout, or to print both strings with no 
error.  But this is one case where we have the extension already in place 
that '/bin/printf --oops' behaves like the intended '/bin/printf -- --oops', 
rather than issuing an error.

I do like the Usage text, though - that is the cleanest way of describing how 
the presence of a single OPTION alters behavior.


src/setuidgid.c:Usage: %s OPTION USER COMMAND [ARGUMENT]...\n\
src/setuidgid.c:  or:  %s OPTION\n\

Not installed.  But this is another case where the Usage could be rendered 
better (the -g is optional, but can be used multiple times):

Usage: %s [SHORT-OPTION]... USER COMMAND [ARGUMENT]...
  or:  %s LONG-OPTION


src/sleep.c:  or:  %s OPTION\n\

'sleep --help --version' is rejected, but not 'sleep --hel'.


src/test.c:  or:  [ OPTION\n\

Discussed in previous email.


src/true.c:  or:  %s OPTION\n\

One of the few utilities where '/bin/true --hel' already treats --hel as 
ignored arguments, rather than an abbreviation for --help.


src/truncate.c:  printf (_(Usage: %s OPTION... FILE...\n), program_name);

Inconsistent formatting.  Do we really want to require either -r or -s, or 
would it make sense to make OPTION optional, in which case the default is -s0?  
Also, would it make sense to extend this such that:

$ echo hi  foo
$ truncate --size=0  foo

resizes foo to 0 bytes, by way of ftruncate on stdin?  If so, maybe it makes 
sense to render this as:

Usage: truncate [OPTION]... [FILE]...


src/unlink.c:  or:  %s OPTION\n), program_name, program_name);

'unlink --help --version' is rejected, but not 'unlink --hel'.  Should we 
treat 'unlink --oops' like 'unlink -- --oops'?


src/yes.c:  or:  %s OPTION\n\

'yes --help --version' is rejected, but 'yes --hel' gives help.  Should we 
treat 'yes --oops' like 'yes -- --oops'?

-- 
Eric Blake




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: option abbreviation exceptions

[Jim Meyering]

Eric Blake e...@byu.net wrote:

 Eric Blake ebb9 at byu.net writes:

  Some of these programs recognize the @option{--help} and @option{--version}
 -options only when one of them is the sole command line argument.
 +options only when one of them is the sole command line argument.  For
 +these programs, abbreviations of the long options are not recognized.

 In subsequent testing, I realized this is not entirely true.  Should I work on
 a followup patch that makes this sentence true?

Simplest might be to change not recognized to not always recognized.

 For example,

 $ /bin/echo --help --version | head -n1
 --help --version
 $ /bin/echo --help | head -n1
 Usage: /bin/echo [OPTION]... [STRING]...
 $ /bin/echo --he | head -n1
 Usage: /bin/echo [OPTION]... [STRING]...
 $ /bin/echo -n -e hi\\n | head -n1
 hi

 Certainly some inconsistent behavior.  echo takes multiple arguments, but only
 when they are the short options -[neE] (I guess it's okay that they don't have
 long-option variants?).

Yes, I think so.  coreutils' echo is so old and rarely used
that it doesn't matter.  People should be using printf instead.

 But when --help or --version is present, echo acts
 like it takes exactly one argument.  The usage text doesn't really portray
 that.  The other thing that is awkward is that we are recognizing
 abbreviations; it seems like it would make more sense for echo --he to
 output --he rather than the help text.  POSIX isn't much help here, either,
 as it only specifies that portable apps can't use -n (but says nothing about -
 e), and we are already violating the (lame) POSIX requirement that -e be on by
 default, thus giving no guidance on whether we are better off requiring the
 user to write /bin/echo -ne instead of /bin/echo -n -e when they want both
 options.

 Another case in point:

 $ /bin/[ --help me | head -n1
 /bin/[: missing `]'
 $ /bin/[ --help | head -n1
 Usage: test EXPRESSION
 $ /bin/[ --hel | head -n1
 Usage: test EXPRESSION

 Should the last example also complain about missing `]', rather than printing
 help text?

test and [ have always had a conflicted relationship
with --help/--version.

Making [ accept no abbreviations does seem like it'd be an improvement.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: option abbreviation exceptions

[Jim Meyering]

Eric Blake e...@byu.net wrote:
 Eric Blake ebb9 at byu.net writes:

 Certainly some inconsistent behavior.  echo takes multiple arguments, but
 only
 when they are the short options -[neE] (I guess it's okay that they don't
 have
 long-option variants?).  But when --help or --version is present, echo acts
 like it takes exactly one argument.  The usage text doesn't really portray
 that.

 Would this usage text be acceptable at better describing the situation?

 Usage: /bin/echo [SHORT-OPTION]... [STRING]...
   or:  /bin/echo LONG-OPTION

Sure.

 Using 'git grep  OPTION', I've come up with this additional list of programs
 where I think we are inconsistent:

 src/basename.c:  or:  %s OPTION\n\

 'basename --help --version' is rejected, but not 'basename --hel'.  Should we
 treat basename --oops as equivalent to basename -- --oops, rather than
 causing an error?

I'd rather not.  Otherwise, basename --h3lp would not give
a diagnostic, and unlink --he would try to unlink an unlikely file.
In each of those cases, the result would be too surprising.

 src/chroot.c:  or:  %s OPTION\n\

 $ chroot -- --hel
 chroot: cannot change root directory to --: No such file or directory

 Oops, there's a bug; the message should have mentioned --hel, not --.

Good catch.

 Meanwhile, should we treat chroot --oops like chroot -- --oops?

Probably not.  Same reasoning as above.

 src/dd.c:  or:  %s OPTION\n\
 src/dirname.c:  or:  %s OPTION\n\
 src/expr.c:  or:  %s OPTION\n\
 src/factor.c:  or:  %s OPTION\n\
 src/hostname.c:  or:  %s OPTION\n\
 src/link.c:  or:  %s OPTION\n), program_name, program_name);
 src/nohup.c:  or:  %s OPTION\n\
 src/printenv.c:  or:  %s OPTION\n\
 src/sleep.c:  or:  %s OPTION\n\
 src/unlink.c:  or:  %s OPTION\n), program_name, program_name);
 src/yes.c:  or:  %s OPTION\n\

same as above.

 Unlike expr, 'factor --help --version' works.

Consistency would be nice.

 src/hostid.c:  or:  %s OPTION\n\

 'hostid --help --version' is rejected.  But perhaps this usage should be
 written in one line, instead of two:

 Usage: hostid [OPTION]

Good idea.

 src/printf.c:  or:  %s OPTION\n\
 src/printf.c:Print ARGUMENT(s) according to FORMAT, or execute according to
 OPTION:\n\

 $ /bin/printf --help --version
 --help/bin/printf: warning: ignoring excess arguments, starting with 
 `--version'

 Ouch.  This both printed to stdout, and to stderr.  It would have been nicer 
 to
 keep the error but do nothing on stdout, or to print both strings with no
 error.  But this is one case where we have the extension already in place
 that '/bin/printf --oops' behaves like the intended '/bin/printf -- --oops',
 rather than issuing an error.

Yes, printf is a special case.

 I do like the Usage text, though - that is the cleanest way of describing how
 the presence of a single OPTION alters behavior.


 src/setuidgid.c:Usage: %s OPTION USER COMMAND [ARGUMENT]...\n\
 src/setuidgid.c:  or:  %s OPTION\n\

 Not installed.  But this is another case where the Usage could be rendered
 better (the -g is optional, but can be used multiple times):

 Usage: %s [SHORT-OPTION]... USER COMMAND [ARGUMENT]...
   or:  %s LONG-OPTION

Yes, that's better.

 src/true.c:  or:  %s OPTION\n\

 One of the few utilities where '/bin/true --hel' already treats --hel as
 ignored arguments, rather than an abbreviation for --help.

yes, this is another beaten-to-death exception ;-)

 src/truncate.c:  printf (_(Usage: %s OPTION... FILE...\n), 
 program_name);

 Inconsistent formatting.  Do we really want to require either -r or -s, or
 would it make sense to make OPTION optional, in which case the default is -s0?
 Also, would it make sense to extend this such that:

 $ echo hi  foo
 $ truncate --size=0  foo

 resizes foo to 0 bytes, by way of ftruncate on stdin?  If so, maybe it makes
 sense to render this as:

 Usage: truncate [OPTION]... [FILE]...

I'll let Pádraig field this one.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

ls -help not accurate

[John Bowling]

ls -d
returns only '.'
Per your faq this is the designed in operation

ls --help
does not reflect that operation:

  -d, --directorylist directory entries instead of contents,
   and do not dereference symbolic links

For that result it should read
  -d, --directorylists base directory entry only instead of
contents,

There is no way to get directory entries  (plural or multiple levels)
with just -d
making that description of -d very inaccurate.

Thanks, John


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: ls -help not accurate

[Philip Rowlands]

On Mon, 29 Dec 2008, John Bowling wrote:


ls -d
returns only '.'
Per your faq this is the designed in operation

ls --help
does not reflect that operation:

 -d, --directorylist directory entries instead of contents,
  and do not dereference symbolic links


. is the directory entry (not the contents) of ., which is the 
default argument to ls.



For that result it should read
 -d, --directorylists base directory entry only instead of
contents,


ls -d is not a useful command on its own, without any arguments. 
Changing the --help text as suggested would mis-describe the intended 
purpose of -d, which is detailed in the referenced FAQ.



There is no way to get directory entries  (plural or multiple levels)
with just -d
making that description of -d very inaccurate.


 From the FAQ:
If you are trying to find files in the directory hierarchy then you 
should look into using the find command.


--help output is intended to be more of a quick reference; the coreutils 
manual contains a longer description of -d.



Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

sort of new branch: next

[Jim Meyering]

I've pushed a few changes to a new next branch.
I expect to rebase it against master.

  $ g shortlog HEAD ^master
build: use dist-xz, not dist-lzma
cleanup/modernize: don't test HAVE_MBRTOWC; now gnulib provides it
portability: accommodate gnulib's getaddrinfo change
maint: move coreutils-specific syntax check rules into cfg.mk
maint: tighten m4 AC_ quoting check
maint: use more sc_-prefixed names
maint: factor out common code; prohibit use of HAVE_MBRTOWC
bootstrap: don't use cmp's -s option when reading from a pipe

The first (dist-xz) will probably wait until the first beta release
of xz (aka next-gen lzma).

The rest should migrate to master pretty quickly.

Feedback welcome.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils