bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.

[Pádraig Brady]

On 02/16/2012 09:30 PM, Jérémy Compostella wrote:
> Pádraig, all,
> 
> I rebased my branch for this feature and make the syntax-check
> success. I attached the new patch which I hope will satisfy you.
> 
> Feel free to comment it, I will take into account whatever you want.

Thanks for continuing with this.
One general thing that might both improve
and simplify the implementation, is to
not to convert from string to int at all.

I.E. when processing the arg, just validate like:
if (strlen (optarg) != strspn (optarg, suffix_alphabet))
  error()
else
   /* skip over any leading 0, and use this as the start directly. */

Then the subsequent check for length and
the initialization of the file name should be simplified.

Also this removes the limitation of size of an unsigned int,
though that's not really a practical concern I suppose.

I've also attached some string and test cleanups,
to --amend into your patch.

cheers,
Pádraig.
diff --git a/NEWS b/NEWS
index fae6ecc..4662919 100644
--- a/NEWS
+++ b/NEWS
@@ -7,10 +7,8 @@ GNU coreutils NEWS-*- 
outline -*-
   dd now accepts the count_bytes, skip_bytes iflags and the count_bytes
   oflag, to more easily allow processing portions of a file.
 
-  split now accept an optional "from" value for the
-  --numeric-suffixes option. If this argument is specified, the
-  numeric suffix counts from this value, otherwise, like before, it
-  counts from 0.
+  split now accepts an optional "from" argument to --numeric-suffixes,
+  which changes the start number from the default of 0.
 
 ** Bug fixes
 
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f5616d8..d7a43d6 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3087,7 +3087,7 @@ Use suffixes of length @var{length}.  The default 
@var{length} is 2.
 @itemx --numeric-suffixes[=@var{from}]
 @opindex -d
 @opindex --numeric-suffixes
-Use digits in suffixes rather than lower-case letters. The numerical
+Use digits in suffixes rather than lower-case letters.  The numerical
 suffix counts from @var{from} if specified, 0 otherwise.
 
 @item -e
diff --git a/src/split.c b/src/split.c
index 03feb9f..e7c61bb 100644
--- a/src/split.c
+++ b/src/split.c
@@ -249,8 +249,7 @@ next_file_name (void)
   outfile_mid = outfile + outbase_length;
   memcpy (outfile, outbase, outbase_length);
   sufindex = xcalloc (suffix_length, sizeof *sufindex);
-  /* Initialize the suffix index accordingly to the count from
- value.  */
+  /* Initialize the suffix index according to start value.  */
   {
 unsigned long left = suffix_count_from;
 while (i-- != 0)
@@ -1166,7 +1165,7 @@ main (int argc, char **argv)
   if (xstrtoul (optarg, NULL, 10, &tmp, "") != LONGINT_OK)
 {
   error (0, 0,
- _("%s: invalid count from numerical suffix number"),
+ _("%s: invalid start value for numerical suffix"),
  optarg);
   usage (EXIT_FAILURE);
 }
@@ -1243,7 +1242,7 @@ main (int argc, char **argv)
   usage (EXIT_FAILURE);
 }
 
-  /* Check that the suffix length is greater enough for the numerical
+  /* Check that the suffix length is large enough for the numerical
  suffix count from value.  */
   if (suffix_count_from)
 {
@@ -1254,8 +1253,8 @@ main (int argc, char **argv)
 {
   if (length == 0)
 {
-  error (0, 0, _("numerical suffix FROM number too hight\
- for the suffix length"));
+  error (0, 0, _("numerical suffix start value is too large "
+ "for the suffix length"));
   usage (EXIT_FAILURE);
 }
   start /= 10;
diff --git a/tests/split/numeric b/tests/split/numeric
index 5550d6f..ad22df6 100755
--- a/tests/split/numeric
+++ b/tests/split/numeric
@@ -21,7 +21,7 @@ print_ver_ split
 
 # Check default start from 0
 printf '1\n2\n3\n4\n5\n' > in || framework_failure_
-split --numeric-suffixes --lines=2 in > out || fail=1
+split --numeric-suffixes --lines=2 in || fail=1
 cat <<\EOF > exp-1
 1
 2
@@ -38,7 +38,7 @@ compare exp-2 x01 || fail=1
 compare exp-3 x02 || fail=1
 
 # Check --numeric-suffixes=X
-split --numeric-suffixes=1 --lines=2 in > out || fail=1
+split --numeric-suffixes=1 --lines=2 in || fail=1
 cat <<\EOF > exp-1
 1
 2
@@ -54,8 +54,12 @@ compare exp-1 x01 || fail=1
 compare exp-2 x02 || fail=1
 compare exp-3 x03 || fail=1
 
-# Check that split failed when suffix length is not greater enough for
-# the numerical suffix count from value
-fail=1 && split -a 3 --numeric-suffixes=1000 in > out 2> /dev/null || fail=0
+# Check that split failed when suffix length is not large enough for
+# the numerical suffix start value
+split -a 3 --numeric-suffixes=1000 in 2> /dev/null && fail=1
+
+# check invalid --numeric-suffixes start values are flagged
+split --numeric-suffixes=-1 in 2> /dev/null && fa

bug#10819: [BUG][RM]

[Philip Rowlands]

On 16/02/2012 18:58, Eric Blake wrote:


so that we could simplify a bunch of automake recipes); but a more extensive
probing is needed in this matter I guess.  And if you are right (as I hope),
then this 'rm' feature could be documented in the Autoconf manual.


Yep, I think that's appropriate, as it is unlikely that we will come up
with any counterexamples any time soon.


As the now-POSIX-infringing behaviour is simple to detect, couldn't 
automake detect it early and die with a helpful message, or is that 
contrary to its philosophy?


Cheers,
Phil

bug#10819: POSIX will say running "rm -f" with no argument is OK

[Stefano Lattarini]

Severity: wishlist

[CC:ing bug-automake, so that we won't forget about this issue]

Reference:
  

POSIX will say in a future version that running "rm -f" with no argument is OK;
we might simplify several automake-generated "cleaning" rules accordingly, to
get rid of the awful idiom:

  test -z "$(VAR)" || rm -f $(VAR)

On 02/16/2012 08:15 PM, Philip Rowlands wrote:
> On 16/02/2012 18:58, Eric Blake wrote:
> 
>>> so that we could simplify a bunch of automake recipes); but a more extensive
>>> probing is needed in this matter I guess.  And if you are right (as I hope),
>>> then this 'rm' feature could be documented in the Autoconf manual.
>>
>> Yep, I think that's appropriate, as it is unlikely that we will come up
>> with any counterexamples any time soon.
> 
> As the now-POSIX-infringing behaviour is simple to detect, couldn't automake 
> detect
> it early and die with a helpful message, or is that contrary to its 
> philosophy?
>
Well, that might be an overkill, since it appears that all the non-museum
implementations of 'rm' have the behaviour we want.  But I agree that, in case
we ever stumble upon a system violating this new expectation, adding proper
configure-time probing and warning might be helpful (and might convince the
users of such an inferior system to start using GNU coreutils).

Regards,
  Stefano

bug#10819: [BUG][RM]

[Eric Blake]

On 02/16/2012 11:38 AM, Stefano Lattarini wrote:
>> FYI: I just opened a POSIX bug report, asking that this usage be
>> codified (since everyone that I tested already does it):
>> http://austingroupbugs.net/view.php?id=542

By the way, that bug report was accepted in today's Austin Group
meeting, so it will be a POSIX requirement whenever Technical
Corrigendum 2 is released :)

>>
> Still, I vaguely recall that there are some 'rm' implementations out there
> which fails upon "rm -f" (with no arguments); and that's why automake uses
> the ugly idiom:
> 
>   test -z "$(VAR)" || rm -f $(VAR)
> 
> in a lot of recipes.  Now, I can't tell off-hand which systems those were,
> nor if they actually exist (and in fact I'd *love* to be proven wrong here,

As would I.  My tests were pretty extensive, hitting some rather old
machines:

FreeBSD 6.4
AIX 5.1
HP-UX 10.20
IRIX 6.5
Solaris 2.6 (both /bin/rm and /usr/xpg4/bin/rm)
Tru64 UNIX 5.1

In all cases, 'rm' gave a usage message and non-zero status, 'rm -f' was
silent with status 0.

GNU coreutils made the swap back in 1993-03-28 (commit 7735ccac,
fileutils 3.8.3b), and if coreutils was the only holdout that caused us
to implement that automake verbosity, we can safely say that 19 years is
long enough to consider the problem long dead.

> so that we could simplify a bunch of automake recipes); but a more extensive
> probing is needed in this matter I guess.  And if you are right (as I hope),
> then this 'rm' feature could be documented in the Autoconf manual.

Yep, I think that's appropriate, as it is unlikely that we will come up
with any counterexamples any time soon.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#10819: [BUG][RM]

[Stefano Lattarini]

Hi Eric.

On 02/16/2012 04:28 PM, Eric Blake wrote:
>
> You can always use 'rm -rf dummy $file_list' without having to check for
> whether $file_list is empty, but yes, that is the primary reasoning why
> -f with no options behaves differently than any other case with no options.
> 
> FYI: I just opened a POSIX bug report, asking that this usage be
> codified (since everyone that I tested already does it):
> http://austingroupbugs.net/view.php?id=542
> 
Still, I vaguely recall that there are some 'rm' implementations out there
which fails upon "rm -f" (with no arguments); and that's why automake uses
the ugly idiom:

  test -z "$(VAR)" || rm -f $(VAR)

in a lot of recipes.  Now, I can't tell off-hand which systems those were,
nor if they actually exist (and in fact I'd *love* to be proven wrong here,
so that we could simplify a bunch of automake recipes); but a more extensive
probing is needed in this matter I guess.  And if you are right (as I hope),
then this 'rm' feature could be documented in the Autoconf manual.

Regards,
  Stefano

bug#10819: [BUG][RM]

[Eric Blake]

On 02/16/2012 03:59 AM, Jim Meyering wrote:
>> I think Davide's point is not about the # comment ... rm won't see
>> that on argv anyway. The point is that 'rm -f' does not complain about
>> missing operands while 'rm' does:
>>
>>   $ rm
>>   rm: missing operand
>>   Try `rm --help' for more information.
>>   $ rm -f
>>   $
>>
>> According to the info, '-f' just silences error messages for files
>> which do not exist (and never to prompt for confirmation), but why
>> should it also affect the "missing operand" message?
> 
> Two reasons:
> 
>  - that's what rm -f has always done
>  - because that's more useful.  Otherwise, "rm -rf $file_list" would
>have to be wrapped in code to handle specially the case in which
>$file_list is empty.

You can always use 'rm -rf dummy $file_list' without having to check for
whether $file_list is empty, but yes, that is the primary reasoning why
-f with no options behaves differently than any other case with no options.

FYI: I just opened a POSIX bug report, asking that this usage be
codified (since everyone that I tested already does it):
http://austingroupbugs.net/view.php?id=542

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#10819: [BUG][RM]

[Voelker, Bernhard]

tags 10819 fixed
thanks

Jim Meyering wrote:
> Voelker, Bernhard wrote:
> > Good point.
> > That means, the info page could be enhanced to mention that
> > special case (see below).
> ...
> > Subject: [PATCH] doc: document 'rm -f' better

> Thanks.  I've applied that with these tweaks:

Even better, thank you.

Marking it as done.

Have a nice day,
Berny

bug#10819: [BUG][RM]

[Jim Meyering]

Voelker, Bernhard wrote:
> Good point.
> That means, the info page could be enhanced to mention that
> special case (see below).
...
> Subject: [PATCH] doc: document 'rm -f' better
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> * doc/coreutils.texi (rm invocation): Mention that the option '-f' also
> silences the message for missing operands which is useful in scripts
> e.g. for "rm -f $file_list" when $file_list is empty.
> * src/rm.c (usage):  Likewise.
> Reported by Jérémy Magrin in http://bugs.gnu.org/10819
...

Thanks.  I've applied that with these tweaks:

doc: improve 'rm -f' description

diff --git a/THANKS.in b/THANKS.in
index 904bb3e..c8dd75f 100644
--- a/THANKS.in
+++ b/THANKS.in
@@ -276,6 +276,7 @@ Jens Elkner elk...@imsgroup.de
 Jens Schmidtj...@jsds.hamburg.com
 Jeph Cowan  j...@ucar.edu
 Jeremy Maitin-Shepard   j...@cmu.edu
+Jérémy Magrin   jeremy.mag...@epitech.eu
 Jerome Abelaab...@hsc.fr
 Jérôme Zago bug-coreutils...@agt-the-walker.net
 Jesse Kornblum  kornb...@usna.edu
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 87624c2..8c6a287 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8769,7 +8769,7 @@ rm invocation
 @itemx --force
 @opindex -f
 @opindex --force
-Ignore nonexistent files, missing operands and never prompt the user.
+Ignore nonexistent files and missing operands, and never prompt the user.
 Ignore any previous @option{--interactive} (@option{-i}) option.

 @item -i

bug#10819: [BUG][RM]

[Voelker, Bernhard]

Jim Meyering wrote:

> Voelker, Bernhard wrote:
> 
> > I think Davide's point is not about the # comment ... rm won't see
> > that on argv anyway. The point is that 'rm -f' does not complain about
> > missing operands while 'rm' does:
> >
> >   $ rm
> >   rm: missing operand
> >   Try `rm --help' for more information.
> >   $ rm -f
> >   $
> >
> > According to the info, '-f' just silences error messages for files
> > which do not exist (and never to prompt for confirmation), but why
> > should it also affect the "missing operand" message?
> 
> Two reasons:
> 
>  - that's what rm -f has always done
>  - because that's more useful.  Otherwise, "rm -rf $file_list" would
>have to be wrapped in code to handle specially the case in which
>$file_list is empty.

Good point.
That means, the info page could be enhanced to mention that
special case (see below).

Have a nice day,
Berny


>From 55d64bcdfdba4726c6e2668066bb25f4bfa6c0b6 Mon Sep 17 00:00:00 2001
From: Bernhard Voelker 
Date: Thu, 16 Feb 2012 13:29:44 +0100
Subject: [PATCH] doc: document 'rm -f' better
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/coreutils.texi (rm invocation): Mention that the option '-f' also
silences the message for missing operands which is useful in scripts
e.g. for "rm -f $file_list" when $file_list is empty.
* src/rm.c (usage):  Likewise.
Reported by Jérémy Magrin in http://bugs.gnu.org/10819
---
 doc/coreutils.texi |2 +-
 src/rm.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 02c3a2a..87624c2 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -8769,7 +8769,7 @@ The program accepts the following options.  Also see 
@ref{Common options}.
 @itemx --force
 @opindex -f
 @opindex --force
-Ignore nonexistent files and never prompt the user.
+Ignore nonexistent files, missing operands and never prompt the user.
 Ignore any previous @option{--interactive} (@option{-i}) option.
 
 @item -i
diff --git a/src/rm.c b/src/rm.c
index db525d0..02809f2 100644
--- a/src/rm.c
+++ b/src/rm.c
@@ -135,7 +135,7 @@ usage (int status)
   fputs (_("\
 Remove (unlink) the FILE(s).\n\
 \n\
-  -f, --force   ignore nonexistent files, never prompt\n\
+  -f, --force   ignore nonexistent files and arguments, never prompt\n\
   -iprompt before every removal\n\
 "), stdout);
   fputs (_("\
-- 
1.7.7

bug#10819: [BUG][RM]

[Jim Meyering]

Voelker, Bernhard wrote:

> Jim Meyering wrote:
>> Davide Brini wrote:
>> ...
>> > At least in bash, but I suppose in other shells too,
>> >
>> > rm -rf #*
>> >
>> > treats the "#*" part as a comment, and (if you remove the "-f") complains
>> > about missing operand to rm.
>>
>> That is the default, but for an interactive shell,
>> that behavior can be changed:
>>
>> $ echo a b # c
>> a b
>> $ shopt -u interactive_comments
>> $ echo a b # c
>> a b # c
>
> I think Davide's point is not about the # comment ... rm won't see
> that on argv anyway. The point is that 'rm -f' does not complain about
> missing operands while 'rm' does:
>
>   $ rm
>   rm: missing operand
>   Try `rm --help' for more information.
>   $ rm -f
>   $
>
> According to the info, '-f' just silences error messages for files
> which do not exist (and never to prompt for confirmation), but why
> should it also affect the "missing operand" message?

Two reasons:

 - that's what rm -f has always done
 - because that's more useful.  Otherwise, "rm -rf $file_list" would
   have to be wrapped in code to handle specially the case in which
   $file_list is empty.

bug#10819: [BUG][RM]

[Voelker, Bernhard]

Jim Meyering wrote:
> Davide Brini wrote:
> ...
> > At least in bash, but I suppose in other shells too,
> >
> > rm -rf #*
> >
> > treats the "#*" part as a comment, and (if you remove the "-f") complains
> > about missing operand to rm.
> 
> That is the default, but for an interactive shell,
> that behavior can be changed:
> 
> $ echo a b # c
> a b
> $ shopt -u interactive_comments
> $ echo a b # c
> a b # c

I think Davide's point is not about the # comment ... rm won't see
that on argv anyway. The point is that 'rm -f' does not complain about
missing operands while 'rm' does:

  $ rm 
  rm: missing operand
  Try `rm --help' for more information.
  $ rm -f
  $

According to the info, '-f' just silences error messages for files
which do not exist (and never to prompt for confirmation), but why
should it also affect the "missing operand" message?

Have a nice day,
Berny

bug#10819: [BUG][RM]

[Jim Meyering]

Davide Brini wrote:
...
> At least in bash, but I suppose in other shells too,
>
> rm -rf #*
>
> treats the "#*" part as a comment, and (if you remove the "-f") complains
> about missing operand to rm.

That is the default, but for an interactive shell,
that behavior can be changed:

$ echo a b # c
a b
$ shopt -u interactive_comments
$ echo a b # c
a b # c

bug#10819: [BUG][RM]

[Davide Brini]

On Wed, 15 Feb 2012 15:06:05 -0700, Eric Blake  wrote:

> tag 10819 needinfo
> thanks
> 
> On 02/15/2012 08:05 AM, jeremy.mag...@epitech.eu wrote:
> > Hello,
> > 
> > I'm writing to you to inform you of a possible bug in the linux "rm"
> > command.
> > I've experienced that when using by error the said command as
> > following : "rm - rf#*"
> 
> That's (probably) not a valid command.  By putting a space between - and
> r, you are asking rm to remove the literal files named "-" and any files
> that match the glob "rf#*".  Did you mean to type "rm -rf #*" instead,
> which says to recursively and without warning remove any files that
> match the glob "#*"?

At least in bash, but I suppose in other shells too,

rm -rf #*

treats the "#*" part as a comment, and (if you remove the "-f") complains
about missing operand to rm.

-- 
D.