bug#30814: Please increase the value of MAX_MON_WIDTH in ls.c

On Wednesday 14 March 2018, Pádraig Brady wrote: > On 13/03/18 17:06, Rafal Luzynski wrote: > > As we have introduced the support of nominative and genitive > > month names in glibc [1] and we are going to provide the updated > > locale data for Catalan language [2] it has been discovered [3] > > t

bug#28468: Bug in wc -l found

On Friday 15 September 2017, Weidner, Robert (I/EE-31, extern) wrote: > Dear GNU Team, > > seems I found a bug in wc, have a look: > > [cid:image001.png@01D32E12.3F5A7C20] > > Despite of it, I really want to say a BIG Thank you for great > tool-set, especially tree, which I use for 20 years now! T

bug#27420: Self Destruct - Self Erase of All Data On SD Card Using Shred,

On Sunday 18 June 2017, Pádraig Brady wrote: > tag 27420 notabug > close 27420 > stop > > On 18/06/17 00:22, John Shearing wrote: > > favorite > > >t-self-erase-of-all-data-on-sd-card-using-shred-dd-or-some-other#> > > > > I will

bug#25930: optimize mv for multiple bind mounts

Hi, I have two bind mounts of the same filesystem $ grep "/tmp" /etc/fstab /dev/vg0/tmpdirs /mnt/tmpdirs ext4 acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 1 2 /mnt/tmpdirs/tmp /tmp none bind 0 0 /mnt/tmpdir

bug#23896: ls incorrectly shows quotes when listing file names with spaces

On Monday 04 July 2016, Pádraig Brady wrote: > On 04/07/16 19:11, Shamim Islam wrote: > > Description of problem: > > Terminal sessions display quotes for files with spaces in them. > > This is non-intuitive behavior. The file name does not have quotes > > unless quotes have been used in the filena

bug#23422: stat -c %N returns strange results for file names including

On Wednesday 04 May 2016, Andreas Schwab wrote: > Ruediger Meier writes: > > Anyways the incompatible change is IMO not acceptable. %N is > > probably most likely used in scripts which rely on the known style. > > The style was never documented (and still isn't). Wha

bug#23422: stat -c %N returns strange results for file names including

On Tuesday 03 May 2016, Paul Eggert wrote: > On 05/02/2016 03:19 PM, Ruediger Meier wrote: > > This new quoting style default is just ugly, unreadable and > > annoying. > > If you can think of an unambiguous output style that is beautiful, > readable, and pleasant, plea

bug#23422: stat -c %N returns strange results for file names including

On Monday 02 May 2016, Michael Albinus wrote: > Pádraig Brady writes: > > Hi, > > >> I have a file called "foobar". Yes, it includes the > >> char in its name. When I call "stat -c %N", I get 'foo'$'\t''bar' > >> . > >> > >> This looks pretty strange. It is with "stat (GNU coreutils) 8.25". > >>

bug#23110: seq apparent bug

On Saturday 09 April 2016, Paul Eggert wrote: > On 04/08/2016 01:51 PM, Ruediger Meier wrote: > > On Friday 08 April 2016, Paul Eggert wrote: > >> For this I suggest the following heuristic. When inferring a > >> format that would apply to two or more lines of output, tr

bug#23110: seq apparent bug

On Friday 08 April 2016, Paul Eggert wrote: > On 04/08/2016 05:57 AM, Pádraig Brady wrote: > > Do we want to deal with these cases spinning the cpu, > > in further patches? > > > >seq 1 nan 1 > > NaN should be an error in any of the operands. > > > seq 1 .001 1 > > F

bug#23239: GNU echo -n argument bug

On Friday 08 April 2016, Eric Blake wrote: > tag 23239 notabug > thanks > > On 04/07/2016 01:27 PM, Faissal Bensefia wrote: > > Hey, > > I stumbled across a bug in GNU coreutils' echo, if I use echo with > > an option like -nn or -nnn it should be treated as something > > echoable and echo "-nn

bug#23110: seq apparent bug

On Thursday 07 April 2016, Bernhard Voelker wrote: > tags 23110 notabug > close 23110 > thanks > > On 04/06/2016 08:19 PM, Ruediger Meier wrote: > > This sounds all true, however then these one should also run > > forever: $ seq 10 0 2 > > > > Man page says

bug#23110: seq apparent bug

On Thursday 24 March 2016, Bernhard Voelker wrote: > On 03/24/2016 04:28 PM, Маренков Евгений wrote: > > I have recently noticed an apparent bug in 'seq'. If one runs > > seq -w 2 1 10 > > everything works fine. > > But > > seq -w 2 0 10 > > falls into endless loop ... > > Thanks for the report. >

bug#23090: true and false not POSIX

On Tuesday 22 March 2016, Stephane CHAZELAS wrote: > 2016-03-22 12:31:50 -0700, Paul Eggert: > [...] > > > It might be helpful to have some other environment variable that > > meant "try to be strict about supporting only behavior required by > > POSIX", as one could use that to develop shell scrip

bug#23090: true and false not POSIX

On Tuesday 22 March 2016, Eric Blake wrote: > On 03/22/2016 11:56 AM, Ruediger Meier wrote: > >> The man page (and --help output) specifically state: > >> > >>NOTE: your shell may have its own version of true, which > >> usually super‐ > >>

bug#23090: true and false not POSIX

On Tuesday 22 March 2016, Eric Blake wrote: > On 03/22/2016 10:38 AM, Ruediger Meier wrote: > > BTW this man page does not match to the most probably used built-in > > command. This confuses the reader even more and is IMO another > > argument why coreutils shouldn't hav

bug#23090: true and false not POSIX

On Tuesday 22 March 2016, Eric Blake wrote: > On 03/22/2016 06:43 AM, Ruediger Meier wrote: > > Hi, > > > > Is there any good reason why coreutils true and false are not > > POSIX? > > No, because coreutils' true and false ARE compliant with POSIX. > > &

bug#23090: true and false not POSIX

On Tuesday 22 March 2016, Eric Blake wrote: > On 03/22/2016 09:08 AM, Stephane Chazelas wrote: > >> BTW I know about POSIXLY_CORRECT env. I just ask this: Is it worth > >> to violate parts of POSIX just for minor cosmetical reasons? > >> > >> I mean echo -n/-e may be an improvement though non-posix

bug#23090: true and false not POSIX

On Tuesday 22 March 2016, Stephane Chazelas wrote: > 2016-03-22 13:43:30 +0100, Ruediger Meier: > [...] > > > Is there any good reason why coreutils true and false are not > > POSIX? > > > > man 1p true: > > OPTIONS > >None. > > STD

bug#23090: true and false not POSIX

Hi, Is there any good reason why coreutils true and false are not POSIX? man 1p true: OPTIONS None. STDOUT Not used. But coreutils true has --version and --help implemented. It needs >/dev/null redirection to work as expected. Also these options are the reason why true.c is u

bug#22696: ls output changes considered unacceptable

On Tuesday 16 February 2016, Assaf Gordon wrote: > Hello all, > > Regarding the recent change of default-quoting style, > what do you think about the attached patch, > enabling to set the default style during './configure' ? > > advanced users who prefer the previous behavior (but don't want to > u

bug#22696: ls output changes considered unacceptable

On Tuesday 16 February 2016, Paul Eggert wrote: > On 02/16/2016 10:48 AM, Ruediger Meier wrote: > > If the file name _is_ readable at all, then it was printed in a > > more readable way. > > Sorry, I'm not following. What do you mean by "readable at all"?

bug#22696: ls output changes considered unacceptable

On Tuesday 16 February 2016, Eric Blake wrote: > On 02/16/2016 03:13 PM, Ruediger Meier wrote: > > Do you really think that this ls output is clear to a newbie? > > $ ls > > 'a?b' 'a'$'\n''b' axb c 'd e' > > A ne

bug#22696: ls output changes considered unacceptable

On Tuesday 16 February 2016, Jon Stanley wrote: > On Tue, Feb 16, 2016 at 1:48 PM, Ruediger Meier wrote: > > No! IMO Newbies should learn (most painful as possible!) that > > non-ascii filenames sucks. :) Maybe ls shouldn't show them at all > > by default ;) > > I

bug#22696: ls output changes considered unacceptable

On Tuesday 16 February 2016, Paul Eggert wrote: > On 02/16/2016 08:58 AM, Ruediger Meier wrote: > > Terminal output should be human readable not machine readable. > > Sure, but under the old way of doing things, terminal output *wasn't* > human-readable. For example:

bug#22696: ls output changes considered unacceptable

On Tuesday 16 February 2016, Bernhard Voelker wrote: > On 02/16/2016 11:50 AM, Jason A. Donenfeld wrote: > > And, when such a > > change is made in software considered "core", by a single > > individual unilaterally without extremely wide consultation of the > > larger community, it is clear that a

bug#21051: direct/file deletion

On Wednesday 15 July 2015, Lee Sung wrote: > > How would I delete directory "." and ".." > > Those entries are required infrastructure and should not be deleted. > The "." directory refers to the current directory. The ".." refers > to the parent directory. The ".." entry on some classic Unix fil

bug#17505: Interface inconsistency, use of intelligent defaults.

On Friday 16 May 2014, Pádraig Brady wrote: > On 05/16/2014 02:24 AM, Linda Walsh wrote: > > On programs that allow input and output by specifying > > computer-base2 powers of K/M/G OR decimal based powers of 10, > > > > If the input units are specified in in powers of 2 then the output > > should

bug#17505: Interface inconsistency, use of intelligent defaults.

On Friday 16 May 2014, Linda Walsh wrote: > On programs that allow input and output by specifying computer-base2 > powers of K/M/G OR decimal based powers of 10, > > If the input units are specified in in powers of 2 then the output > should be given in the same units. > > Example: > > dd if=/dev/

bug#17360: base64 bug of result ending founded

On Monday 28 April 2014, Алексей wrote: > I take some difference of results base64 command and base64 php > function > > *echo "11" | base64* > give result > *MTExMTExCg==* echo prints a newline per default $ echo -n "11" | base64 MTExMTEx > > but base64 php function give result > *MTExMT

bug#13899: Bugs in echo and printf

On Thursday 07 March 2013, Sérgio Coutinho wrote: > Hello! > > I discovered a few bugs in echo and printf. > > echo --help > echo --version > printf --help > printf --version > > They all don't work... > > Sergio Probably you are using the shell builtins. Have you tried with full path /usr/bin/ech

bug#13183: tail -f ignores SIGPIPE

Hi, I want to use tail and grep to follow a file until a particular pattern appears. But tail does not exit when grep is finished. $ echo xxx > /tmp/blabla $ tail -f /tmp/blabla |grep -m1 --line-buffered "xxx" xxx Now tail still tries to read and exits only if I write again into /tmp/blabla.

bug#13028: inplace

On Thursday 29 November 2012, Reuben Thomas wrote: > On Fri, 14 May 2004 15:53:04 +0600 (YEKST), Victor Porton offered his > handy "inplace" script to coreutils, which runs a filter on a file > in-place. A couple of replies said there was no need for this as one > could do in-place editing with per

bug#11115: linux date arithmetic

On Wednesday 28 March 2012, Eric Blake wrote: > On 03/28/2012 03:23 PM, Bruno Haible wrote: > > Eric Blake wrote: > >> the parser is faced with an ambiguity between: > >> > >> (11:38 +1) minute > >> 11:38 (+1 minute) > > > > What is the first interpretation meant to mean? > > The time 11:38 in the

bug#11115: linux date arithmetic

On Wednesday 28 March 2012, Eric Blake wrote: > [adding bug-gnulib] > > On 03/28/2012 06:39 AM, Stefan Karamuz wrote: > > Please check the 2 linux commands: > > > > date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S > > date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S > > > > It's very confusing

bug#9939: Problems with the SIZE description in man pages for and

On Tuesday 15 November 2011, Eric Blake wrote: > On 11/15/2011 11:25 AM, Jim Meyering wrote: > > Eric Blake wrote: > >> On 11/15/2011 11:12 AM, Ruediger Meier wrote: > >>> I also think the multiplier version is a bit easier to read. > >>> My

bug#8782: date command

On Friday 03 June 2011, Ruediger Meier wrote: > There was no "2011-05-27 02:01:00" in Germany. Typo, I ment 2011-03-27. cu, Rudi

bug#8782: date command

On Friday 03 June 2011, Voelker, Bernhard wrote: > so in the night where the DST transition takes place, imagine you get > up to go to the toilet because you drank to much coffee the evening > before ... right in the hour where DST transition happens: > isn't there a `date`? > Or the other way roun

bug#8374: cp -a [-l] sometimes does not preserve timestamps of symlinks

Hi, I see you fixed that already for for cp -a http://marc.info/?t=12489708961&r=1&w=2 But it does not together with option -link: cd /tmp/ ln -s somewhere symlink touch -h -t "19700101" symlink cp -a symlink symlink-a cp -al symlink symlink-al ls -l symlink* lrwxrwxrwx 1 rudi users 9