option abbreviation exceptions (was: Suggestion for rmdir)

2008-12-29 Thread 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

Re: printf(1) does not support argument swapping

2008-12-29 Thread 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

Re: option abbreviation exceptions

2008-12-29 Thread 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

Re: option abbreviation exceptions

2008-12-29 Thread 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

Re: option abbreviation exceptions

2008-12-29 Thread 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,

ls -help not accurate

2008-12-29 Thread 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,

Re: ls -help not accurate

2008-12-29 Thread 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

sort of new branch: next

2008-12-29 Thread 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