bug#25833: fold -s ... but for more than just spaces

2017-02-21 Thread 積丹尼 Dan Jacobson
fold -s will break at spaces. But why not let the user also pick an arbitrary character, other than spaces, too?

bug#25832: split (v 8.25) with numeric suffixes beyond 89

2017-02-21 Thread Pádraig Brady
On 21/02/17 20:01, Assaf Gordon wrote: > >> On Feb 21, 2017, at 22:32, Pádraig Brady wrote: >> >> This was discussed at http://bugs.gnu.org/20874 > > Missed that - sorry. I should've looked through the archives first... > >> I'm not sure anything needs to be done here, >> since for backward com

bug#25832: split (v 8.25) with numeric suffixes beyond 89

2017-02-21 Thread Assaf Gordon
> On Feb 21, 2017, at 22:32, Pádraig Brady wrote: > > This was discussed at http://bugs.gnu.org/20874 Missed that - sorry. I should've looked through the archives first... > I'm not sure anything needs to be done here, > since for backward compat for concat operations > expecting lexical sort

bug#25832: split (v 8.25) with numeric suffixes beyond 89

2017-02-21 Thread Pádraig Brady
unarchive 20874 forcemerge 20874 25832 stop On 21/02/17 18:40, Assaf Gordon wrote: > Hello, > >> On Feb 21, 2017, at 19:55, Holger Wolff >> wrote: >> >> Incorrect numeric suffixes are sometimes produced when going beyond number >> 89: >> Assume a file "test.txt" with 1000 lines, and the comman

bug#25832: split (v 8.25) with numeric suffixes beyond 89

2017-02-21 Thread Assaf Gordon
Hello, > On Feb 21, 2017, at 19:55, Holger Wolff > wrote: > > Incorrect numeric suffixes are sometimes produced when going beyond number 89: > Assume a file "test.txt" with 1000 lines, and the command > > $ split -d -l 10 test.txt test_ > > I expect files test_00 through test_99, but what I g

bug#25832: split (v 8.25) with numeric suffixes beyond 89

2017-02-21 Thread Holger Wolff
Hello Incorrect numeric suffixes are sometimes produced when going beyond number 89: Assume a file "test.txt" with 1000 lines, and the command $ split -d -l 10 test.txt test_ I expect files test_00 through test_99, but what I get are test_00 through test_89 and test_9000 through test_9009.

bug#25817: Why were Gnu coding standards violated in favor of posix for 'rm -fr .'?: request for reversion of behavior

2017-02-21 Thread L A Walsh
Eric Blake wrote: the discussion here is about an early exit on an attempt to remove '.', which, contrary to your claim, appears to always have been in POSIX as far as I can tell (and even if it has not always been in POSIX, the fact that I can quote a 20-year-old document that describes curre

bug#25817: Why were Gnu coding standards violated in favor of posix for 'rm -fr .'?: request for reversion of behavior

2017-02-21 Thread Paul Eggert
On 02/21/2017 05:42 AM, Eric Blake wrote: "If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component), rm will write a diagnostic message to standard error and do nothing more with such operands." The same wording is in the

bug#25817: Why were Gnu coding standards violated in favor of posix for 'rm -fr .'?: request for reversion of behavior

2017-02-21 Thread Eric Blake
On 02/21/2017 07:42 AM, Eric Blake wrote: > On 02/21/2017 02:41 AM, L A Walsh wrote: >> >> Do you really need me to find the older version >> of 'rm' in your source tree? > > It wouldn't hurt to point out which commit id changed behavior, if you > indeed want to call that commit a regression.

bug#25817: Why were Gnu coding standards violated in favor of posix for 'rm -fr .'?: request for reversion of behavior

2017-02-21 Thread Eric Blake
On 02/21/2017 02:41 AM, L A Walsh wrote: > > Do you really need me to find the older version > of 'rm' in your source tree? It wouldn't hurt to point out which commit id changed behavior, if you indeed want to call that commit a regression. Being able to read the commit itself, as well as ma

bug#25817: Why were Gnu coding standards violated in favor of posix for 'rm -fr .'?: request for reversion of behavior

2017-02-21 Thread L A Walsh
Or are you arguing that contents within the directory should be removed, even though the directory itself cannot be? --- That's the way a recursive descent algorithm works: it processes the contents, before the parents. When it gets to the parent, it couldn't remove it, but due to th

bug#25378: cp does not preserve SElinx context of sub folder

2017-02-21 Thread Pádraig Brady
On 20/02/17 23:18, Bernhard Voelker wrote: > Hi Padraig, > > only some minor remarks from my side. > > On 02/21/2017 04:11 AM, Pádraig Brady wrote: >> From d17ca013f3aadcf697663830fa9ec34cba551f66 Mon Sep 17 00:00:00 2001 >> From: =?UTF-8?q?P=C3=A1draig=20Brady?= >> Date: Mon, 20 Feb 2017 18:46: