Re: Support in sort for human-readable numbers

[Jim Meyering]

"Vitali Lovich"  wrote:
...
>> because I think it's a common enough format and getting
>> more common since it's an IEC defined standard.
>>
>>> and wouldn't be better served by
>>> pre-processing the text before sort & post-processing it after as
>>> necessary?
>>
>> that's a little awkward and inefficient.
>>
>>> Supporting all the various ways the human_readable can be output is
>>> just not practical or even useful
>>
>> just ignore an optional trailing iB is all I'm suggesting.

I agree that ignoring the valid suffixes is worthwhile.
Remember that df and du support the --block-size option,
(or equivalently, via one of the BLOCK_SIZE envvars)
so people may be running "du --block-size=MiB -s /tmp",
which produces output like this:

27MiB   /tmp

As such, I'd like GNU sort to handle input like that.
You could argue that the numbers might have "." or ","
thousands separators:

  $ LC_ALL=en_US du --block-size=\'1 -s /tmp
  27,905,024  /tmp

but I don't think it's worthwhile to parse those.

>> If it's difficult or inefficient then don't worry about it.

> Right, but you have to deal with terminating characters and whatnot.
> I mean it's not super difficult obviously.  I'm just wondering why
> that logic even belongs in sort.  The rule of thumb is - the less code
> you write, the fewer bugs you'll have.

Sure, but usability counts, too.
If we stuck mindlessly to the less-code-is-better mantra,
coreutils would look very different than it does now.
Finding the right balance isn't easy.


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

Re: Support in sort for human-readable numbers

[Vitali Lovich]

On Wed, Jan 7, 2009 at 3:17 AM, Jim Meyering  wrote:
> "Vitali Lovich"  wrote:
> ...
>>> because I think it's a common enough format and getting
>>> more common since it's an IEC defined standard.
>>>
 and wouldn't be better served by
 pre-processing the text before sort & post-processing it after as
 necessary?
>>>
>>> that's a little awkward and inefficient.
>>>
 Supporting all the various ways the human_readable can be output is
 just not practical or even useful
>>>
>>> just ignore an optional trailing iB is all I'm suggesting.
>
> I agree that ignoring the valid suffixes is worthwhile.
> Remember that df and du support the --block-size option,
> (or equivalently, via one of the BLOCK_SIZE envvars)
> so people may be running "du --block-size=MiB -s /tmp",
> which produces output like this:
Well then once this basic implementation is in there, add the
block-size longopt to sort to support this feature if you feel it's
worthwhile.  My reasoning is that without sort -h, achieving that
behaviour is a non-trivial shell script.  With this feature, it's
trivial & straightforward to sort the output from du --block-size=MiB
- pass it through sed before sort to get M, pass the output of sort
into sed again to put back the MiB.  However, it seems like support
for this is being requested, so I'll provide a reference
implementation ifdeffed out so that you can determine if the
additional code really makes it worthwhile.

>
> 27MiB   /tmp
>
> As such, I'd like GNU sort to handle input like that.
> You could argue that the numbers might have "." or ","
> thousands separators:
>
>  $ LC_ALL=en_US du --block-size=\'1 -s /tmp
>  27,905,024  /tmp
>
> but I don't think it's worthwhile to parse those.
Well, in this case, sort -h would parse it the same as sort -n.  So
that is a different discussion.
>
>>> If it's difficult or inefficient then don't worry about it.
>
>> Right, but you have to deal with terminating characters and whatnot.
>> I mean it's not super difficult obviously.  I'm just wondering why
>> that logic even belongs in sort.  The rule of thumb is - the less code
>> you write, the fewer bugs you'll have.
>
> Sure, but usability counts, too.
> If we stuck mindlessly to the less-code-is-better mantra,
> coreutils would look very different than it does now.
> Finding the right balance isn't easy.
Isn't that the beauty (i.e. frustration) of writing a software library
;).  My argument was just that the additional code isn't necessarily
justified because the same feature can be trivially accomplished by
the user through trivial shell scripting, which is arguably much
easier and cheaper to fix.  For instance, if this code turns out to
have a bug, that'll screw every distro that ships it (i.e. egrep on
Ubuntu didn't work for a long time just due to having to maintain
compatability).  However, the additional bit of thinking on the users
part on how to adjust the input & output to get the desired behaviour
has far less costs associated with it.  Nevertheless, I am bowing to
what appears to be popular demand (since I have not heard any support
for my initial position), and will add this when I get the time.


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

Re: Support in sort for human-readable numbers

[Vitali Lovich]

On Wed, Jan 7, 2009 at 2:52 AM, Paul Eggert  wrote:
> I looked at the patch
>  and have a
> few comments:
>
> * There's no documentation, either in the .texi file or in the --help
>  string.  That's often the hardest part to get right.
I agree - that's why I'm waiting to get the implementation stabilized
before trying to write it (along with the necessary test cases).  That
will be done, but there's no point documenting right now since the
behaviour hasn't been finalized.

>
> * The patch slows down "sort -n" a bit, and (worse) complicates the code
>  for "sort -n".  There are a lot of gotos.
Oh no - scary gotos.  Seriously - gotos serve a place, and there is
appropriate usage, especially when it comes to minimizing code
duplication within a function (dont believe me?  go look at the linux
kernel or any significant piece of C code).  In fact, gotos are
actually quite fast (if you know CPUs, you'll realize it's a simple
jmp instruction which does nothing to the CPU pipeline - conditional
jumps are way more problomatic).  Some of those gotos are unnecessary
(not removing code duplication), but I think they make the code easier
to read and I'm quite positive that any decent compiler will optimize
away any unnecessary jumps.  And code readability is far more
important than that last 0.1% improvement.

I challenge you to show me one benchmark where the behaviour is
demonstrably slower by even a significant percentage (let's say 3%)
and is not caused by the branching of which comparison to use.

> Better, I think, would be
>  to (1) search for a trailing suffix character, and compare based on
>  that, and then (2) fall back on numeric comparison only if the
>  trailing suffix characters match.  This will certainly make plain
>  "sort -n" faster and will result in a less-intrusive change to the
>  existing code; arguably it will make the new code faster in many
>  cases, too.
Did you read my explanation above for your exact "optimization"?
Please explain to me, in a somewhat detailed manner, how this improves
behaviour because I'm failing to see the algorithm.

Here's what I think you're suggesting:

for (each character c in string a)
  if (c is not a number)
break

for (each character d in string b)
  if (c is not a number)
break

if (suffix starting at c != suffix starting at d)
   return which one is greater

perform the regular sort -n comparison between a & b

You must be thinking that that last step is somehow magical and free,
cause I see it as once again looping over the string.  You may be
thinking to yourself - yeah, but there's no expensive comparison
between the two strings.  Ok - I'll grant you that.  So you've sped up
the best case where the suffixes don't match (more on this later).
Now let's look at the worst case - the suffixes match.  Thus you have
to scan over the string again but this time performing your numeric
comparison.  So you've made your worst case slower.  I have a feeling
that this worst case is also likely to be the average case.

Also, let's take it that you have managed to speed-up the best-case.
But have you really?  What have you saved - the cost of a subtraction
n times (n is the length of the number) over a span of x comparisons.
Do you honestly believe that n * x will be sufficiently big in any
reasonable test case that this saving will actually be realized? x by
the way will be approximately m log m (where m is the number of
strings).  So your cost savings over the course of your call to sort
will be n * m log m, for m strings of length n.  Let's take a
reasonable n = 3 (after all - higher n on average means you will be
using a different suffix anyways).  Let's saying you are sorting a
million strings.  So you've saved about 3 000 000 log 3 000 000 = 19
431 363 comparisons.  Let's be generous here and say that subtraction
takes 20 clock cycles (I don't feel like digging up my FPGA work to
figure out how many clock cycles my implementation took - let alone
the far better ones used in modern processors).  On a modern 2.0 GHz
machine, that'll be about 40 ns.  So for a million strings, you've
managed to save a whopping 777254520 nanoseconds.  Wait a minute -
that's 0.7 seconds.  So every million strings - your optimization, in
the best case, will shave off 0.7 seconds.  Excellent.  Oh - and m has
a much larger impact, so sorting more strings will be more of a factor
than sorting longer strings.

Now repeat the above analysis for the worst case, and I'm quite
confident you'll see a much larger hit (although probably still not
significant at all) in the worst case (suffixes equal).

Hopefully I didn't emabarass myself with a glaring mistake - it's really late.

>
> * Please don't take the address of an often-used local variable; this
>  hurts optimization, since it often inhibits optimizing that variable
>  into a register.
Could you please provide me with context about where this is happening
(I can't find it in t

Re: Support in sort for human-readable numbers

[Vitali Lovich]

Oh, and if my prior e-mail seems a bit abrupt, I apologize.  I don't
mean to be rude.  It is getting late, and I probably should've waited
until morning to compose my reply.

On Wed, Jan 7, 2009 at 4:21 AM, Vitali Lovich  wrote:
> On Wed, Jan 7, 2009 at 2:52 AM, Paul Eggert  wrote:
>> I looked at the patch
>>  and have a
>> few comments:
>>
>> * There's no documentation, either in the .texi file or in the --help
>>  string.  That's often the hardest part to get right.
> I agree - that's why I'm waiting to get the implementation stabilized
> before trying to write it (along with the necessary test cases).  That
> will be done, but there's no point documenting right now since the
> behaviour hasn't been finalized.
>
>>
>> * The patch slows down "sort -n" a bit, and (worse) complicates the code
>>  for "sort -n".  There are a lot of gotos.
> Oh no - scary gotos.  Seriously - gotos serve a place, and there is
> appropriate usage, especially when it comes to minimizing code
> duplication within a function (dont believe me?  go look at the linux
> kernel or any significant piece of C code).  In fact, gotos are
> actually quite fast (if you know CPUs, you'll realize it's a simple
> jmp instruction which does nothing to the CPU pipeline - conditional
> jumps are way more problomatic).  Some of those gotos are unnecessary
> (not removing code duplication), but I think they make the code easier
> to read and I'm quite positive that any decent compiler will optimize
> away any unnecessary jumps.  And code readability is far more
> important than that last 0.1% improvement.
>
> I challenge you to show me one benchmark where the behaviour is
> demonstrably slower by even a significant percentage (let's say 3%)
> and is not caused by the branching of which comparison to use.
>
>> Better, I think, would be
>>  to (1) search for a trailing suffix character, and compare based on
>>  that, and then (2) fall back on numeric comparison only if the
>>  trailing suffix characters match.  This will certainly make plain
>>  "sort -n" faster and will result in a less-intrusive change to the
>>  existing code; arguably it will make the new code faster in many
>>  cases, too.
> Did you read my explanation above for your exact "optimization"?
> Please explain to me, in a somewhat detailed manner, how this improves
> behaviour because I'm failing to see the algorithm.
>
> Here's what I think you're suggesting:
>
> for (each character c in string a)
>  if (c is not a number)
>break
>
> for (each character d in string b)
>  if (c is not a number)
>break
>
> if (suffix starting at c != suffix starting at d)
>   return which one is greater
>
> perform the regular sort -n comparison between a & b
>
> You must be thinking that that last step is somehow magical and free,
> cause I see it as once again looping over the string.  You may be
> thinking to yourself - yeah, but there's no expensive comparison
> between the two strings.  Ok - I'll grant you that.  So you've sped up
> the best case where the suffixes don't match (more on this later).
> Now let's look at the worst case - the suffixes match.  Thus you have
> to scan over the string again but this time performing your numeric
> comparison.  So you've made your worst case slower.  I have a feeling
> that this worst case is also likely to be the average case.
>
> Also, let's take it that you have managed to speed-up the best-case.
> But have you really?  What have you saved - the cost of a subtraction
> n times (n is the length of the number) over a span of x comparisons.
> Do you honestly believe that n * x will be sufficiently big in any
> reasonable test case that this saving will actually be realized? x by
> the way will be approximately m log m (where m is the number of
> strings).  So your cost savings over the course of your call to sort
> will be n * m log m, for m strings of length n.  Let's take a
> reasonable n = 3 (after all - higher n on average means you will be
> using a different suffix anyways).  Let's saying you are sorting a
> million strings.  So you've saved about 3 000 000 log 3 000 000 = 19
> 431 363 comparisons.  Let's be generous here and say that subtraction
> takes 20 clock cycles (I don't feel like digging up my FPGA work to
> figure out how many clock cycles my implementation took - let alone
> the far better ones used in modern processors).  On a modern 2.0 GHz
> machine, that'll be about 40 ns.  So for a million strings, you've
> managed to save a whopping 777254520 nanoseconds.  Wait a minute -
> that's 0.7 seconds.  So every million strings - your optimization, in
> the best case, will shave off 0.7 seconds.  Excellent.  Oh - and m has
> a much larger impact, so sorting more strings will be more of a factor
> than sorting longer strings.
>
> Now repeat the above analysis for the worst case, and I'm quite
> confident you'll see a much larger hit (although probably still not
> significant at

Re: stat signed/unsigned

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady  wrote:
> ...
>>> That sounds like it could be rather invasive...
>>> >From an aesthetics/readability point of view, I'm not sure
>>> I like the idea of using ST_SIZE (st) in place of "st.st_size".
>> Well it would be more consistent as we already use ST_BLKSIZE etc.
>> There aren't many references to .st_size really.
>>
>>> More importantly, there are places in the code that compare stat.st_size
>>> against negative numbers (at least remove.c).
>> Yuk, so that code assumes that st_size will be always be signed,
> 
> It's guaranteed that st_size's type is signed, since off_t is signed.

What I meant is that it assumes that st_size will never overflow.

> Using a macro to cast away such "known" signedness sounds
> dangerous.

I think it's safer to assume "known" unsignedness in this case?

>>> I've started down this clean-up-Wsign-compare-warnings road
>>> a few times, and inevitably end up concluding it's not worthwhile.
>> The current patch I have is 50 insertions(+), 37 deletions(-)
>> So for 13 new lines of code with no new casts I think it
>> probably is worth addressing.
> 
> show the code ;-)

Current code is attached.
Before I commit though I need to fix also 6 files in lib/
Also I need to test on 64 bit, and with _FILE_OFFSET_BITS=32

cheers,
Pádraig.
>From b373082f939708182f75fa71d8bda813b26d71ef Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= 
Date: Mon, 5 Jan 2009 19:13:24 +
Subject: [PATCH] build: enable and avoid -Wsign-compare warnings

* configure.ac: allow --enable-gcc-warnings to include -Wsign-compare,
which is included as part of -Wextra.
* src/system.h: Assume st_size, st_blksize, st_blocks of stat struct
are always to be interpreted as positive values, so cast to uintmax_t
in the corresponding extraction macros. A new macro ST_SIZE was
added to do this cast for the st_size member.
* src/copy.c: Use ST_SIZE macro to get an unsigned value.
Use already assigned unsigned variable n, rather than signed n_read
in unsigned comparison.
* src/dd.c: Split out ternary conditional to avoid warning about
the use of signed and unsigned in the expression.
Copy lseek return to a uintmax_t as it's compared against unsigned.
* src/du.c: Store st_size in uintmax_t explicitly to avoid warning.
Also add an assert, to check for the improbable overflow condition.
* src/group-list.c: Use int rather than size_t as variable is used
in signed comparisons.
* src/id.c: Likewise.
* src/ls.c: Use unsigned variables for always positive widths.
Refactor common code to a new format_number_width() function.
Remove unsigned_file_size() and use new ST_SIZE macro instead.
* src/od.c: Use unsigned widths as always positive.
Use ST_SIZE macro to remove an existing cast.
* src/pathchk.c: Compare pathconf limits to signed MAX constants,
as pathconf returns signed values.
* src/pr.c: Use unsigned variables in unsigned comparisons.
* src/shuf.c: Likewise.
* src/ptx.c: Removing existing (redundant) casts of st_size,
and use ST_SIZE on all references to st_size.
* src/shred.c: Use already assigned signed variable sizeof_r,
rather than the unsigned sizeof(r). Don't use signed integer
overflow check that contemporary compilers may remove.
* src/sort.c: Use unsigned file_size in unsigned comparisions.
* src/tac.c: Store lseek return in uintmax_t as it's used in
various unsigned comparisions. Cast it to off_t only in error check.
Remove redundant (off_t) casts.
---
 configure.ac |1 -
 src/copy.c   |   16 +-
 src/dd.c |   13 +--
 src/du.c |   13 +--
 src/group-list.c |4 +-
 src/id.c |4 +-
 src/ls.c |   89 +
 src/od.c |   12 
 src/pathchk.c|6 ++--
 src/pr.c |8 ++--
 src/ptx.c|   10 +++---
 src/shred.c  |6 ++--
 src/shuf.c   |4 +-
 src/sort.c   |6 ++--
 src/stat.c   |4 +-
 src/system.h |   18 ++-
 src/tac.c|   10 +++---
 17 files changed, 115 insertions(+), 109 deletions(-)

diff --git a/configure.ac b/configure.ac
index 6163db7..a13e4b5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -61,7 +61,6 @@ if test "$gl_gcc_warnings" = yes; then
   gl_WARN_ADD([-Wall])
   gl_WARN_ADD([-Wextra])
   gl_WARN_ADD([-Wshadow])
-  gl_WARN_ADD([-Wno-sign-compare])
   gl_WARN_ADD([-Wformat])
   gl_WARN_ADD([-Wformat-security])
   gl_WARN_ADD([-Wcast-align])
diff --git a/src/copy.c b/src/copy.c
index c9c79a1..96e1865 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1,5 +1,5 @@
 /* copy.c -- core functions for copying files and directories
-   Copyright (C) 89, 90, 91, 1995-2008 Free Software Foundation, Inc.
+   Copyright (C) 89, 90, 91, 1995-2009 Free Software Foundation, Inc.
 
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -501,7 +501,7 @@ copy_reg (char const *src_name, char const *dst_na

No more "Your first commit: the quick and dirty way"

[jidanni]

In the file HACKING, please remove the
"Your first commit: the quick and dirty way".

Just directly mention the right way,
"Make your changes on a private "topic" branch"

It only costs the user a couple more commands. Else you are starting
many first time git users on the wrong foot; days of misery and
twisted development habits that will take months to recover from
mentally.

$ grep -i never git/Documentation/*.txt


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

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

[Kamil Dudka]

On Wednesday 07 January 2009 08:35:24 Jim Meyering wrote:
> Have you considered other long-option names?
> I prefer --no-clobber.  or maybe --no-overwrite
In this case I prefer --no-overwrite, but feel free to change it.

> ---
> Please adjust the NEWS entry:
>
> -  cp/mv new option -n to not overwrite target
> +  cp and mv accept a new option, --LONG_OPTION (-n): silently refrain
> +  from overwriting any existing destination file
>
> -
> You haven't mentioned how this new option interacts with --backup,
> another option that prevents loss of any existing destination file.
>
> Since with --backup, cp and mv arrange to move any destination aside,
> one might expect -n --backup to be equivalent to --backup.
The behavior is the same as for -i option with negative user's response. If 
nothing is going to be overwritten, there is nothing to backup. I think this 
is an expected behavior and in this way is the --backup option already 
documented.

> ---
> In mv documentation (--help and texi), please say something like:
>
>   If you specify more than one of the -i,-f,-n options, only the
>   final one takes effect.
>
> That's easier to understand than
>
>   -i overrides preceding -f or -n
>   -n overrides preceding -i or -f
>   -f overrides preceding -i or -n
Yes, it makes sense. The current description was taken from FreeBSD man pages 
for cp/mv.

Attaching new version of the patch.


Kamil

From 8b391a82b6edee9906c3bd5ba2bd896c32233ce0 Mon Sep 17 00:00:00 2001
From: Kamil Dudka 
Date: Wed, 7 Jan 2009 16:32:47 +0100
Subject: [PATCH] cp/mv: add --no-overwrite (-n) option to not overwrite target

* src/cp.c (usage): Show new option -n in --help.
(main): Handle new option -n.
* src/mv.c (usage): Show new option -n in --help.
(main): Handle new option -n.
* doc/coreutils.texi: Document new cp/mv option -n.
* tests/cp/cp-i: Add tests for -f, -i and -n options.
* tests/mv/mv-n: New test for mv -n.
* tests/Makefile.am: Add test mv/mv-n to the list.
* NEWS: Mention the change.
---
 NEWS   |3 ++
 doc/coreutils.texi |   27 ++-
 src/cp.c   |   15 ++--
 src/mv.c   |   15 ++--
 tests/Makefile.am  |1 +
 tests/cp/cp-i  |   33 +
 tests/mv/mv-n  |   58 
 7 files changed, 144 insertions(+), 8 deletions(-)
 create mode 100755 tests/mv/mv-n

diff --git a/NEWS b/NEWS
index f605330..2c127a0 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,9 @@ GNU coreutils NEWS-*- outline -*-
 
 ** New features
 
+  cp and mv accept a new option, --no-overwrite (-n): silently refrain
+  from overwriting any existing destination file
+
   dd accepts iflag=cio and oflag=cio to open the file in CIO (concurrent I/O)
   mode where this feature is available.
 
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 51145de..dbe3c78 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7314,6 +7314,9 @@ description of @option{--remove-destination}.
 This option is independent of the @option{--interactive} or
 @option{-i} option: neither cancels the effect of the other.
 
+This option is redundant if the @option{--no-overwrite} or @option{-n} option is
+used.
+
 @item -H
 @opindex -H
 If a command line argument specifies a symbolic link, then copy the
@@ -7326,7 +7329,8 @@ via recursive traversal.
 @opindex -i
 @opindex --interactive
 When copying a file other than a directory, prompt whether to
-overwrite an existing destination file.
+overwrite an existing destination file. The @option{-i} option overrides
+a previous @option{-n} option.
 
 @item -l
 @itemx --link
@@ -7340,6 +7344,13 @@ Make hard links instead of copies of non-directories.
 @opindex --dereference
 Follow symbolic links when copying from them.
 
+...@item -n
+...@itemx --no-overwrite
+...@opindex -n
+...@opindex --no-overwrite
+Do not overwrite an existing file. The @option{-n} option overrides a previous
+...@option{-i} option.
+
 @item -P
 @itemx --no-dereference
 @opindex -P
@@ -8098,7 +8109,9 @@ The program accepts the following options.  Also see @ref{Common options}.
 @opindex -f
 @opindex --force
 @cindex prompts, omitting
-Do not prompt the user before removing a destination file.
+Do not prompt the user before removing a destination file. If you specify more
+than one of the @option{-i}, @option{-f}, @option{-n} options, only the final
+one takes effect.
 
 @item -i
 @itemx --interactive
@@ -8108,6 +8121,16 @@ Do not prompt the user before removing a destination file.
 Prompt whether to overwrite each existing destination file, regardless
 of its permissions.
 If the response is not affirmative, the file is skipped.
+If you specify more than one of the @option{-i}, @option{-f}, @option{-n}
+options, only the final one takes effect.
+
+...@item -n
+...@itemx --no-overwrite
+...@opindex -n
+...@opindex --no-overwrite
+...@cin

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

[Jim Meyering]

Kamil Dudka  wrote:
> On Wednesday 07 January 2009 08:35:24 Jim Meyering wrote:
>> Have you considered other long-option names?
>> I prefer --no-clobber.  or maybe --no-overwrite
> In this case I prefer --no-overwrite, but feel free to change it.

Hi Kamil,

--no-clobber gets a few more matches in C sources than --no-overwrite,

  57  http://www.google.com/codesearch?q=\-\-no\-clobber+lang:c
  40  http://www.google.com/codesearch?q=\-\-no\-overwrite+lang:c

Regarding uses, it appears to outnumber --no-overwrite 2-to-1.

Anyone else have a preference?

>> ---
>> Please adjust the NEWS entry:
>>
>> -  cp/mv new option -n to not overwrite target
>> +  cp and mv accept a new option, --LONG_OPTION (-n): silently refrain
>> +  from overwriting any existing destination file
>>
>> -
>> You haven't mentioned how this new option interacts with --backup,
>> another option that prevents loss of any existing destination file.
>>
>> Since with --backup, cp and mv arrange to move any destination aside,
>> one might expect -n --backup to be equivalent to --backup.
> The behavior is the same as for -i option with negative user's response. If
> nothing is going to be overwritten, there is nothing to backup. I think this
> is an expected behavior and in this way is the --backup option already
> documented.

My point is that depending on when you test for
the existence of the destination file, you could say that with
--backup, there is never an existing destination file, since
it's always moved aside before the "open".  In *that* case,
you would expect the "-n" in "--backup -n" to be ignored.
This ambiguity is why the semantics of "--backup -n" must be
documented explicitly.

Since there are three copies of that new sentence in coreutils.texi,

If you specify more than one of the @option{-i}, @option{-f},
@option{-n} options, only the final one takes effect.

would you please put it in a macro?

Thanks for being patient.


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

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

[Kamil Dudka]

On Wednesday 07 January 2009 17:08:04 Jim Meyering wrote:
> --no-clobber gets a few more matches in C sources than --no-overwrite,
>
>   57  http://www.google.com/codesearch?q=\-\-no\-clobber+lang:c
>   40  http://www.google.com/codesearch?q=\-\-no\-overwrite+lang:c
>
> Regarding uses, it appears to outnumber --no-overwrite 2-to-1.
>
> Anyone else have a preference?
Now the option is --no-clobber in attached patch. Anyway the change is 
trivial. No problem to change it if there will be a consensus 
for --no-overwrite or something else.

> My point is that depending on when you test for
> the existence of the destination file, you could say that with
> --backup, there is never an existing destination file, since
> it's always moved aside before the "open".  In *that* case,
> you would expect the "-n" in "--backup -n" to be ignored.
> This ambiguity is why the semantics of "--backup -n" must be
> documented explicitly.
Ok, mentioned in documentation of option -n.

> Since there are three copies of that new sentence in coreutils.texi,
>
> If you specify more than one of the @option{-i}, @option{-f},
> @option{-n} options, only the final one takes effect.
>
> would you please put it in a macro?
Ok, new patch attached.


Kamil
From 7e3be3500d0a7c27331131115158d608bca53ed7 Mon Sep 17 00:00:00 2001
From: Kamil Dudka 
Date: Wed, 7 Jan 2009 19:52:28 +0100
Subject: [PATCH] cp/mv: add --no-clobber (-n) option to not overwrite target

* src/cp.c (usage): Show new option -n in --help.
(main): Handle new option -n.
* src/mv.c (usage): Show new option -n in --help.
(main): Handle new option -n.
* doc/coreutils.texi: Document new cp/mv option -n.
* tests/cp/cp-i: Add tests for -f, -i and -n options.
* tests/mv/mv-n: New test for mv -n.
* tests/Makefile.am: Add test mv/mv-n to the list.
* NEWS: Mention the change.
---
 NEWS   |3 ++
 doc/coreutils.texi |   28 -
 src/cp.c   |   15 ++--
 src/mv.c   |   15 ++--
 tests/Makefile.am  |1 +
 tests/cp/cp-i  |   33 +
 tests/mv/mv-n  |   58 
 7 files changed, 146 insertions(+), 7 deletions(-)
 create mode 100755 tests/mv/mv-n

diff --git a/NEWS b/NEWS
index f605330..f1b383e 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,9 @@ GNU coreutils NEWS-*- outline -*-
 
 ** New features
 
+  cp and mv accept a new option, --no-clobber (-n): silently refrain
+  from overwriting any existing destination file
+
   dd accepts iflag=cio and oflag=cio to open the file in CIO (concurrent I/O)
   mode where this feature is available.
 
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 51145de..ee5e85e 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7314,6 +7314,9 @@ description of @option{--remove-destination}.
 This option is independent of the @option{--interactive} or
 @option{-i} option: neither cancels the effect of the other.
 
+This option is redundant if the @option{--no-clobber} or @option{-n} option is
+used.
+
 @item -H
 @opindex -H
 If a command line argument specifies a symbolic link, then copy the
@@ -7326,7 +7329,8 @@ via recursive traversal.
 @opindex -i
 @opindex --interactive
 When copying a file other than a directory, prompt whether to
-overwrite an existing destination file.
+overwrite an existing destination file. The @option{-i} option overrides
+a previous @option{-n} option.
 
 @item -l
 @itemx --link
@@ -7340,6 +7344,13 @@ Make hard links instead of copies of non-directories.
 @opindex --dereference
 Follow symbolic links when copying from them.
 
+...@item -n
+...@itemx --no-clobber
+...@opindex -n
+...@opindex --no-clobber
+Do not overwrite an existing file. The @option{-n} option overrides a previous
+...@option{-i} option. This option turns off the backup.
+
 @item -P
 @itemx --no-dereference
 @opindex -P
@@ -8099,6 +8110,11 @@ The program accepts the following options.  Also see @ref{Common options}.
 @opindex --force
 @cindex prompts, omitting
 Do not prompt the user before removing a destination file.
+...@macro mvOptsIfn
+If you specify more than one of the @option{-i}, @option{-f}, @option{-n}
+options, only the final one takes effect.
+...@end macro
+...@mvoptsifn
 
 @item -i
 @itemx --interactive
@@ -8108,6 +8124,16 @@ Do not prompt the user before removing a destination file.
 Prompt whether to overwrite each existing destination file, regardless
 of its permissions.
 If the response is not affirmative, the file is skipped.
+...@mvoptsifn
+
+...@item -n
+...@itemx --no-clobber
+...@opindex -n
+...@opindex --no-clobber
+...@cindex prompts, omitting
+Do not overwrite an existing file.
+...@mvoptsifn
+This option turns off the backup.
 
 @item -u
 @itemx --update
diff --git a/src/cp.c b/src/cp.c
index 8e34965..9f43875 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -116,6 +116,7 @@ static struct option const long_opts[] =
   {"force", no_argument, NULL, 'f'

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

[Jim Meyering]

Kamil Dudka  wrote:
> On Wednesday 07 January 2009 17:08:04 Jim Meyering wrote:
>> --no-clobber gets a few more matches in C sources than --no-overwrite,
>>
>>   57  http://www.google.com/codesearch?q=\-\-no\-clobber+lang:c
>>   40  http://www.google.com/codesearch?q=\-\-no\-overwrite+lang:c
>>
>> Regarding uses, it appears to outnumber --no-overwrite 2-to-1.
>>
>> Anyone else have a preference?
> Now the option is --no-clobber in attached patch. Anyway the change is
> trivial. No problem to change it if there will be a consensus
> for --no-overwrite or something else.
>
>> My point is that depending on when you test for
>> the existence of the destination file, you could say that with
>> --backup, there is never an existing destination file, since
>> it's always moved aside before the "open".  In *that* case,
>> you would expect the "-n" in "--backup -n" to be ignored.
>> This ambiguity is why the semantics of "--backup -n" must be
>> documented explicitly.
> Ok, mentioned in documentation of option -n.
>
>> Since there are three copies of that new sentence in coreutils.texi,
>>
>> If you specify more than one of the @option{-i}, @option{-f},
>> @option{-n} options, only the final one takes effect.
>>
>> would you please put it in a macro?
> Ok, new patch attached.

Thanks!  Almost done, I think.
Unless anyone pipes up about the choice of long option name.

> +...@item -n
> +...@itemx --no-clobber
> +...@opindex -n
> +...@opindex --no-clobber
> +Do not overwrite an existing file. The @option{-n} option overrides a 
> previous
> +...@option{-i} option. This option turns off the backup.

These semantics might be a little surprising, or even dangerous.
Imagine I run cp -n --backup=numbered important-file backup,
thinking that it's just made a backup of the old version and
I can now safely destroy "important-file".

What do you think about making cp/mv fail if -n and --backup are used together?
Then there would be no risk of misunderstanding.


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

Bug in date command

[Bob Kline]

The date command reports the wrong ISO week number in some cases.  For
example:

$ date -d 2008-12-31 +%Y%V
200801

Clearly the last day of the year can't be in the first week of that
year.

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com



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

Re: Bug in date command

[Eric Blake]

Bob Kline  rksystems.com> writes:

> 
> The date command reports the wrong ISO week number in some cases.  For
> example:
> 
> $ date -d 2008-12-31 +%Y%V
> 200801

Not a bug in date, but in your misuse of incompatible formats.  2008-12-31 is 
in the first ISO week of 2009, as evidenced by:

$ date -d 2008-12-31 +%G%V
200901
$ date -d 2009-01-01 +%G%V
200901

The ISO week starts on Monday, and is attributed to the year that contains four 
or more days of the week; it can be 01-53 inclusive (but 53 is rare).

Perhaps you wanted the more traditional week number:

$ date -d 2008-12-31 +%Y%U
200852
$ date -d 2009-01-01 +%Y%U
200900

Here, the week starts on Sunday, the range is 00-53, and no days are attributed 
to an adjacent year; week 01 is the first full week of the year.

This is specified by POSIX:
http://www.opengroup.org/onlinepubs/9699919799/utilities/date.html

In short, %G and %V go together, %Y and %U go together, and any other 
combination causes confusion.  Perhaps we should try to mention this in the 
usage text somehow?

There seems to always be a rash of "bug" reports about date at the turn of the 
year (and also around daylight savings changes), due to the large number of 
people who don't realize the subtleties involved.  Perhaps we should create a 
FAQ entry with the most common of these reports.

-- 
Eric Blake




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

Re: Bug in date command

[Bob Proulx]

Bob Kline wrote:
> The date command reports the wrong ISO week number in some cases.  For
> example:
> 
> $ date -d 2008-12-31 +%Y%V
> 200801
> 
> Clearly the last day of the year can't be in the first week of that
> year.

According to ISO 8601 it can.  See the official standard for the
authoritative details but wikipedia has a good summary.

  http://en.wikipedia.org/wiki/ISO_8601

Weeks begin with Monday and end on Sunday.  Week 01 is the week with
the year's first Thursday in it.

The GNU Coreutils date %V documentation says:

  `%V'
   week number of year with Monday as first day of the week as a
   decimal (`01'...`53').  If the week containing January 1 has four
   or more days in the new year, then it is considered week 1;
   otherwise, it is week 53 of the previous year, and the next week
   is week 1.  (See the ISO 8601 standard.)

Perhaps for your purposes (you didn't say what you purpose was) you
wanted to use %G%V?

  $ date -d 2008-12-31 +%G%V
  200901

Personally I prefer %F (a GNU extension) best.

  $ date -d 2008-12-31 +%F
  2008-12-31

Bob


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

Re: Bug in date command

[Bob Proulx]

Eric Blake wrote:
> There seems to always be a rash of "bug" reports about date at the
> turn of the year (and also around daylight savings changes), due to
> the large number of people who don't realize the subtleties
> involved.  Perhaps we should create a FAQ entry with the most common
> of these reports.

Good idea!  I have just now done so and have replaced the old and long
stale old date entry (which was tiny and if you don't remember just
said that things had been updated after 2000) with one that is quite a
bit longer now.  :-)

  
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

How does that look?

Bob


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

can't find out cumin-admin command

[yuan xinfang]

hi, sir

i have met a problem , i have install cumin and mrg management .

now i install cumin -0.1-3.el5, mrgmanagement -1.0-2.noarch

it setup succeed for it . and database have create
running
cumin-database-init   it's ok
su cuminit's ok

cumin-admin adduser testuserdoens't work show me this command not found


i don't know where can i find out this command package.



another question
we i try to install cumin-0.1-6  noarch.rpm.. it show me succeed ,but i init
database show e global "clog"  can't find. do i need to upgrede other rpm
for releateship this

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

Re: can't find out cumin-admin command

[Bob Proulx]

yuan xinfang wrote:
> i have met a problem , i have install cumin and mrg management .
> 
> now i install cumin -0.1-3.el5, mrgmanagement -1.0-2.noarch

You have reached the GNU Coreutils mailing list.  The GNU Coreutils
are the basic file, shell and text manipulation utilities of the GNU
Operating System.  You can learn more about GNU Coreutils here:

  http://www.gnu.org/software/coreutils/

The GNU Coreutils are part of the GNU Operating System.  You can learn
more about the GNU Project here:

  http://www.gnu.org/

But you are asking about mrg and cumin.  I am sorry but this is the
wrong mailing list.  We do not know anything about mrg or cumin.  They
are not part of the GNU Coreutils package.  We are unable to help you
here.

> it setup succeed for it . and database have create
> running
> cumin-database-init   it's ok
> su cuminit's ok
> 
> cumin-admin adduser testuserdoens't work show me this command not found
> 
> i don't know where can i find out this command package.

I do not know either.  I searched the web for mrg and cumin and it
looks as if it is a Red Hat package.  I found this page describing it.

  
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.0/html/Management_Console_Installation_Guide/

You would need to ask Red Hat for help.

> another question
> we i try to install cumin-0.1-6  noarch.rpm.. it show me succeed ,but i init
> database show e global "clog"  can't find. do i need to upgrede other rpm
> for releateship this

No ideas here.

Good luck!
Bob


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

Re: Bug in date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Proulx on 1/7/2009 3:12 PM:
>   
> http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
> 
> How does that look?

A couple of nits:

"The parsing of dates with date --date=STRING is a GNU extension and not
covered by any standards beyond those to which GNU holds itself."  Not
entirely true any longer, now that POSIX 2008 requires that 'touch -d
STRING' parse a limited format of ISO dates, and we implement that with
the same date parsing engine as our (true GNU extension) 'date -d'.  On
the other hand, since we don't yet accept 'T' in an ISO date (POSIX allows
the alternative of space, which we do parse), there is still some hacking
to be done on getdate.y.  But yes, in general, we parse many more STRINGs
as dates than what POSIX requires.

"The %Y and %U options work in combination."  To be fair, we should state
that the %Y and your choice of %U/%W work in combination (%W if you want
Monday, %U if you want Sunday as the first day of the week).

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkllaeEACgkQ84KuGfSFAYBYkwCgmFdOrkSBFAbXtEBrTDe0WDCO
DJ8Ani9RwIt1Cb6vP1cBoF289isk0Hdr
=gJI1
-END PGP SIGNATURE-


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

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 1/7/2009 12:27 PM:
>>> Anyone else have a preference?
>> Now the option is --no-clobber in attached patch. Anyway the change is
>> trivial. No problem to change it if there will be a consensus
>> for --no-overwrite or something else.
>>
> 
> Thanks!  Almost done, I think.
> Unless anyone pipes up about the choice of long option name.

I like --no-clobber, particularly since it is similar to the bash (and
tcsh) noclobber shell option.

> 
> What do you think about making cp/mv fail if -n and --backup are used 
> together?
> Then there would be no risk of misunderstanding.

Seems reasonable to me.

> +++ b/NEWS
> @@ -4,6 +4,9 @@ GNU coreutils NEWS
- -*- outline -*-
>
>  ** New features
>
> +  cp and mv accept a new option, --no-clobber (-n): silently refrain
> +  from overwriting any existing destination file

Missing period.

> + opened, remove it and try again (The
- -f option\n\
> + is redundant if the -n option is used.)\n\
> +  -i, --interactiveprompt before overwrite  (The -i option\n\
> + overrides a previous -n option.)\n\
>-H   follow command-line symbolic links in
SOURCE\n\
>  "), stdout);
>fputs (_("\
> @@ -176,6 +179,8 @@ Mandatory arguments to long options are mandatory
for short options too.\n\
>-L, --dereferencealways follow symbolic links in SOURCE\n\
>  "), stdout);
>fputs (_("\
> +  -n, --no-clobber do not overwrite an existing file  (The
- -n\n\
> + option overrides a previous -i option.)\n\

The formatting is not very consistent here (are these full sentences, with
capitalization, periods, and two spaces, or just phrases?)

> + case 'n':
> +   x.interactive = I_ALWAYS_NO;
> +   break;

Does this actually do the right thing, or does it only prevent overwrites
at spots where, without arguments, a prompt would be issued?  In other
words, is this particular implementation reinventing the same problems as
the deprecated --reply=no?

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkllbc0ACgkQ84KuGfSFAYBR3gCeKzfa+5jg4A0j34Hx++rC1w4o
WGEAn1Qtgxhg0NeQQBRqAl1tpOTVqR3m
=BDMK
-END PGP SIGNATURE-


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

Re: Bug in date command

[Bob Proulx]

Eric Blake wrote:
> A couple of nits:
> 
> "The parsing of dates with date --date=STRING is a GNU extension and not
> covered by any standards beyond those to which GNU holds itself."  Not
> entirely true any longer, now that POSIX 2008 requires that 'touch -d
> STRING' parse a limited format of ISO dates, and we implement that with
> the same date parsing engine as our (true GNU extension) 'date -d'.

Good point.  I added the following to the previous description.

  However @command{touch -d STRING} is defined by POSIX and is
  implemented with the same date string parsing code.  Therefore you
  can expect that similar rules will apply to both.

> "The %Y and %U options work in combination."  To be fair, we should state
> that the %Y and your choice of %U/%W work in combination (%W if you want
> Monday, %U if you want Sunday as the first day of the week).

As per your suggestion I have added discussion of %W too.

  The @option{%Y} and @option{%U} or @option{%W} options work in
  combination.  (Use @option{%U} for weeks starting with Sunday or
  @option{%W} for weeks starting with Monday.)  The ISO @option{%G} and
  @option{%V} options work in combination.  Mixing them up creates
  confusion.  Instead use @option{%Y} and @option{%U}/@option{%W}
  together or use @option{%G} and @option{%V} together.

Bob


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

Re: cp/mv: add -n option to not overwrite target (Ubuntu bug #229182)

[Jim Meyering]

Eric Blake  wrote:
> According to Jim Meyering on 1/7/2009 12:27 PM:
 Anyone else have a preference?
>>> Now the option is --no-clobber in attached patch. Anyway the change is
>>> trivial. No problem to change it if there will be a consensus
>>> for --no-overwrite or something else.
>>>
>>
>> Thanks!  Almost done, I think.
>> Unless anyone pipes up about the choice of long option name.
>
> I like --no-clobber, particularly since it is similar to the bash (and
> tcsh) noclobber shell option.
>
>>
>> What do you think about making cp/mv fail if -n and --backup are used 
>> together?
>> Then there would be no risk of misunderstanding.
>
> Seems reasonable to me.
>
>> +++ b/NEWS
>> @@ -4,6 +4,9 @@ GNU coreutils NEWS
> -*- outline -*-
>>
>>  ** New features
>>
>> +  cp and mv accept a new option, --no-clobber (-n): silently refrain
>> +  from overwriting any existing destination file
>
> Missing period.

Thanks for the review.

>> + opened, remove it and try again (The
> -f option\n\
>> + is redundant if the -n option is used.)\n\
>> +  -i, --interactiveprompt before overwrite  (The -i option\n\
>> + overrides a previous -n option.)\n\
>>-H   follow command-line symbolic links in
> SOURCE\n\
>>  "), stdout);
>>fputs (_("\
>> @@ -176,6 +179,8 @@ Mandatory arguments to long options are mandatory
> for short options too.\n\
>>-L, --dereferencealways follow symbolic links in SOURCE\n\
>>  "), stdout);
>>fputs (_("\
>> +  -n, --no-clobber do not overwrite an existing file  (The
> -n\n\
>> + option overrides a previous -i option.)\n\
>
> The formatting is not very consistent here (are these full sentences, with
> capitalization, periods, and two spaces, or just phrases?)

It's a little bit unusual to insert text into the option list,
but works for chown --help, so I suggest doing it here, too:

diff --git a/src/mv.c b/src/mv.c
index 635c4e0..d8ca50b 100644
--- a/src/mv.c
+++ b/src/mv.c
@@ -1,5 +1,5 @@
 /* mv -- move or rename files
-   Copyright (C) 86, 89, 90, 91, 1995-2008 Free Software Foundation, Inc.
+   Copyright (C) 86, 89, 90, 91, 1995-2009 Free Software Foundation, Inc.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -295,13 +295,10 @@ Mandatory arguments to long options are mandatory for 
short options too.\n\
   fputs (_("\
   --backup[=CONTROL]   make a backup of each existing destination 
file\n\
   -b   like --backup but does not accept an argument\n\
-  -f, --force  do not prompt before overwriting  (The -f 
option\n\
- overrides any previous -i or -n options.)\n\
-  -i, --interactiveprompt before overwrite  (The -i option\n\
- overrides any previous -f or -n options.)\n\
-  -n, --no-replace do not overwrite an existing file  (The -n\n\
- option overrides any previous -f or -i\n\
- options.)\n\
+  -f, --force  do not prompt before overwriting\n\
+  -i, --interactiveprompt before overwrite\n\
+  -n, --no-replace do not overwrite an existing file\n\
+If you specify more than one of -i, -f, -n, only the final one takes effect.\n\
 "), stdout);
   fputs (_("\
   --strip-trailing-slashes  remove any trailing slashes from each SOURCE\n\

>> +case 'n':
>> +  x.interactive = I_ALWAYS_NO;
>> +  break;
>
> Does this actually do the right thing, or does it only prevent overwrites
> at spots where, without arguments, a prompt would be issued?  In other
> words, is this particular implementation reinventing the same problems as
> the deprecated --reply=no?

Kamil's test additions appear to cover most cases.
Once -n --backup evokes failure, it'd be nice to exercise that, too.


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