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

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

Re: ls -help not accurate

[Andreas Schwab]

John Bowling  writes:

> There is no way to get directory entries  (plural or multiple levels)
> with just -d

$ ls -d . ..
.  ..

Andreas.

-- 
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


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

Re: Providing pointers to more generic help

[John Sullivan]

"James Youngman"  writes:

> The logical thing to do is put a single web page somewhere on
> www.gnu.org and include in that page things that help users find
> resources to help them.   I've made an outline of such a document
> below.   It would likely be an enhancement to the document currently
> at .
>
> What do you think?   If you think this is a good idea but think the
> outline could be better, please et me know.

Seems like a good idea to me, as an enhancement to gethelp.html.

We get *a lot* of requests for technical assistance with specific
programs sent to i...@fsf.org/g...@gnu.org, so it would also help all of
those people if we had a better page to point them to.

> Support-related Benefits of Free Software
>   

Four :)

>   The Linux Documentation Project

I don't think we can point to this from gnu.org due to the naming
issues. Along the same lines, though, pointing to
http://flossmanuals.net might be good.

> Mailing Lists and Newsgroups
>  How to Find the Right Mailing List
>  

Another helpful thing could be to point toward the Free Software
Directory -- people can find mailing list and other useful support info
on the entry page for the program they are using.

 > Meeting People Who Can Help
 > 

There are free software groups and GLUGs, linked to from
/links/links.html.

Maybe it would also be useful to mention the idea of seeing if anyone
has had the problem before by searching bug/issue trackers and mailing
list archives?

-- 
John Sullivan
Manager of Operations
GPG Key: AE8600B6


___
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: option abbreviation exceptions

[Jim Meyering]

Eric Blake  wrote:
> Eric Blake  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

Re: option abbreviation exceptions

[Jim Meyering]

Eric Blake  wrote:

> Eric Blake  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

[Eric Blake]

Eric Blake  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: printf(1) does not support argument swapping

[Eric Blake]

Eric Blake  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

option abbreviation exceptions (was: Suggestion for rmdir)

[Eric Blake]

Eric Blake  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