bug#34347: At least add 2nd comm error message after output

On 06/02/19 04:16, 積丹尼 Dan Jacobson wrote: > (info "(coreutils) comm invocation") > > "Before ‘comm’ can be used, the input files must be sorted" > > "If an input file is diagnosed as being unsorted, the ‘comm’ command > will exit with a nonzero

bug#34239: build failure on Android, due to S_MAGIC_* symbols

On 28/01/19 19:19, Bruno Haible wrote: > Hi, > > Compiling coreutils on Android produces this error: > > CC src/tail.o > In file included from ../src/tail.c:63: > ../src/fs-is-local.h: In function 'is_local_fs_type': > ../src/fs-is-local.h:9: error: 'S_MAGIC_AAFS' undeclared (first use

bug#33946: tail -f stops abruptly in AIX when piped.

On 17/01/19 06:25, Bernhard Voelker wrote: > On 1/16/19 4:09 AM, Pádraig Brady wrote: >> On 14/01/19 23:54, Bernhard Voelker wrote: >>> On 1/13/19 4:31 AM, Pádraig Brady wrote: >>>> Thanks for testing. Pushed at: >>>> https://git.sv.gnu.org/gitw

bug#33946: tail -f stops abruptly in AIX when piped.

On 15/01/19 19:11, Pádraig Brady wrote: > On 15/01/19 04:42, Ayappan P2 wrote: >> >> The patch/commit is not proper. The select() call will still be invoked in >> AIX. > > Drats I pushed the debugging version of my patch :/ > I'll fix up (preferably with Bernha

bug#33946: tail -f stops abruptly in AIX when piped.

On 14/01/19 23:54, Bernhard Voelker wrote: > On 1/13/19 4:31 AM, Pádraig Brady wrote: >> Thanks for testing. Pushed at: >> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=d5ab4cb > >> -timeout 10 tail -f $mode $fastpoll out | sleep .1 || fail=1 >> +(re

bug#33946: tail -f stops abruptly in AIX when piped.

On 15/01/19 04:42, Ayappan P2 wrote: > > The patch/commit is not proper. The select() call will still be invoked in > AIX. Drats I pushed the debugging version of my patch :/ I'll fix up (preferably with Bernhard's test issue also addressed)

bug#33946: tail -f stops abruptly in AIX when piped.

On 07/01/19 01:04, Ayappan P2 wrote: > The poll() solution is working in AIX. Great. Thanks for testing. Pushed at: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=d5ab4cb cheers, Pádraig

bug#33946: tail -f stops abruptly in AIX when piped.

On 03/01/19 23:01, Ayappan P2 wrote: > > The problem happens only when we pipe the output of "tail -f" . > > I am not sure how one can take the truss of "/tail -f test_file | grep > 123" . > > I did little debugging on the tail code. This function "check_output_alive" > introduced by the

bug#33914: In man pages, the URL's should not be split on two lines

On 29/12/18 16:41, Vincent Lefevre wrote: > In the dircolors(1) man page (and other ones for long command names) > of GNU coreutils 8.30, as output in a 80-column terminal, one has > > REPORTING BUGS >GNU coreutils online help: >Report

bug#33915: ls / dircolors should support more than 8 colors

On 29/12/18 18:10, Vincent Lefevre wrote: > On 2018-12-30 02:21:15 +0100, Vincent Lefevre wrote: >> But one can get bright colors without bold by using 90, 91, etc. >> This is useful with gnome-terminal. >> >> I think that this should be documented. >> >> Support for more than 16 colors could be

bug#33785: df: don't suppress remote mounts

On 17/12/18 22:42, lzhong wrote: > Hi list, > > According to the following commit > > commit 2e81e62243409c5c574b899f52b08c000e4d99fd > Author: Pádraig Brady > Date: Wed Oct 29 02:49:17 2014 + > > df: only suppress remote mounts of separate exports with

bug#33468: A bug with yes and --help

On 22/11/18 10:09, Uko Kokņevičs wrote: > So I was messing around with `yes`, and after running `yes --help me` it > output this: > >> yes: unrecognized option '--help' >> Try 'yes --help' for more information. > > After a bit of more testing of this, I found the same reaction from > `whoami`.

bug#33474: Bug in error message formatting

On 23/11/18 05:56, Mark Roberts wrote: > Dear madams and sirs, > > the German translation of 'tail' has a formatting error when reporting > that the PID to be monitored is invalid. The English version is correct. > > English version: > >> export LANG="" >> tail -f --pid=aaa /dev/null > tail:

bug#13183: tail -f ignores SIGPIPE

On 15/02/15 11:14, Pádraig Brady wrote: > On 14/12/12 14:33, Pádraig Brady wrote: >> tag 13183 + notabug >> close 13183 >> stop >> >> On 12/14/2012 02:04 PM, Ruediger Meier wrote: >>> Hi, >>> >>> I want to use tail and grep to follow

bug#33113: incorrect and inconsistent quoting in ls output

On 23/10/18 17:54, Paul Eggert wrote: > On 10/22/18 1:44 AM, Vincent Lefevre wrote: >> On the behavior, there's still the issue concerning = and &. > > Yes, you're right, there's no need to quote = with -b. The reason \= is quoted with -bF is to distinguish socket names that end in =. An edge

bug#32703: echo_man_error

On 24/09/18 21:51, Pádraig Brady wrote: > On 24/09/18 15:15, Eric Blake wrote: >> On 9/23/18 9:48 PM, Pádraig Brady wrote: >> >>> +++ b/NEWS >>> @@ -5,6 +5,12 @@ GNU coreutils NEWS-*- >>> outline -*- >>>

bug#33097: test has filetest -a but man page doesn't list it

On 21/10/18 16:06, Bernhard Voelker wrote: > On 10/21/18 2:09 AM, Paul Eggert wrote: >> I have the opposite impression. Any scripts using this confusing -a operator >> are >> already broken, and we should phase it out. Not that anybody actually *uses* >> coreutils "test -a". > > Done with the

bug#31979: csplit: a regexp pattern does not consider the negative offset of a

tag 31979 notabug close 31979 stop On 24/09/18 05:40, Stéphane Campinas wrote: > Hi, > > After attempting to port csplit, I think I understand why it is like > that: it is to stop the iteration in case a pattern should be executed > several times. Therefore, maybe an easy fix is to alter the >

bug#32703: echo_man_error

On 24/09/18 15:15, Eric Blake wrote: > On 9/23/18 9:48 PM, Pádraig Brady wrote: > >> +++ b/NEWS >> @@ -5,6 +5,12 @@ GNU coreutils NEWS-*- >> outline -*- >> ** Bug fixes >> >> df no longer corrupts displayed

bug#32703: echo_man_error

On 24/09/18 14:47, Bernhard Voelker wrote: > On 9/24/18 4:48 AM, Pádraig Brady wrote: >> I'll push the attached later. >> Interesting there were no echo tests until now. > > Nice work, indeed. > > Additionally to Eric's comment, I'd suggest to increase the coverage &g

bug#32317: wrong information in csplit documentation

On 30/07/18 10:57, Stéphane Campinas wrote: > Hello, > > In the invocation paget [0] describing csplit, the following is said: > > In any case, concatenating the output files in sorted order by file name > produces the original input file. > > However, that is not true if a pattern was

bug#32703: echo_man_error

On 11/09/18 11:07, Eric Blake wrote: > On 9/11/18 11:01 AM, Eric Blake wrote: > >> $ POSIXLY_CORRECT=1 /bin/echo a\\nb >> a\nb >> >> Yikes! Even though we asked for POSIX correctness, we are NOT >> interpreting backslashes. I think this is a bug in GNU coreutils' echo, >> and could be fixed

bug#32751: split does not break on error from tar

tag 32751 notabug close 32751 stop On 18/09/18 00:59, Alexander Fieroch wrote: >> As far as I can tell, this is not a bug, but the way pipelines work, >> i.e. the result of a pipeline (here the combination of tar and >> split) is the result of the last command in the pipeline. If you >> want the

bug#32703: echo_man_error

On 11/09/18 11:07, Eric Blake wrote: > On 9/11/18 11:01 AM, Eric Blake wrote: > >> $ POSIXLY_CORRECT=1 /bin/echo a\\nb >> a\nb >> >> Yikes! Even though we asked for POSIX correctness, we are NOT >> interpreting backslashes. I think this is a bug in GNU coreutils' echo, >> and could be fixed

bug#32653: single quotes suddenly appearing in ls displays

close 32653 stop On 06/09/18 16:49, Ethan Furman wrote: > I recently installed Linux Mint 18, and when I did an "ls -la" (aliased to > "la") on a directory with hundreds of folders > that are automatically created by a script, single-quote-marks started > showing up. I spent three hours

bug#32521: coreutils timeout in a bash script not transparent for the application

tag 32521 notabug close 32521 stop On 24/08/18 11:19, Rafal Jankowski wrote: > Dear coreutils users/developers > > https://stackoverflow.com/questions/52008104/coreutils-timeout-in-a-bash-script-not-transparent-for-the-application > > I have not done enough investigation to claim this is a true

bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS

On 26/07/18 02:01, Paul Eggert wrote: > Chih-Hsuan Yen wrote: >> How about following the idea from Pádraig Brady >> and filter \n only? > > Given the later comments it seems better to filter out encoding errors and > control characters. Programs that parse the out

bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS

On 21/07/18 15:43, Bruno Haible wrote: > Hi Pádraig, > >> I've attached a gnulib patch to document for iscntrl at least. > >> +This function does not support arguments outside of the range of the >> +unsigned char type in locales with large character sets, on some platforms. >> +OS X 10.5 will

bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS

On 22/07/18 08:12, Paul Eggert wrote: > Pádraig Brady wrote: >> I've also attached an alternative patch for df (in your name). > > That still has problems, since it can generate improperly-encoded strings in > UTF-8 locales (if the inputs are improperly encoded), and

bug#32242: dd help text lacks information about binary prefixes

On 21/07/18 13:36, Wodry wrote: > Am 21.07.2018 um 21:43 schrieb Pádraig Brady: >> We should update truncate(1) etc. to be consistent if making this change. > > truncate uses function emit_size_note for size help text, as do: > > git/coreutils/src$ g

bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS

On 21/07/18 07:20, Chih-Hsuan Yen wrote: > Hi coreutils developers, > > I'm using coreutils on macOS High Sierra (10.13). I noticed that with > `LANG=zh_TW.UTF-8`, `df` output is corrupted. > > �?�?系統 容�?? 已�?� �?��?� 已�?�% �??�?�? > /dev/disk1s1234G 151G81G65% / > /dev/disk1s4

bug#32242: dd help text lacks information about binary prefixes

On 21/07/18 11:48, Wodry wrote: > One can use binary prefixes (iB, e.g. MiB) with dd command, but that is > not written in the help text. > > I just found out because I wanted to add support for binary prefixes > since I did not know they are already supported. > > It's a hidden, but valuable

bug#29886: tests/rm/rm-readdir-fail is failing with SIGBUS on Gentoo sparc

On 15/07/18 07:28, Thomas Deutschmann wrote: > On 2018-07-15 03:21, Pádraig Brady wrote: >> Does this skip the test for you? > rm-readdir-fail.sh: set-up failure: failed to build shared library > ERROR: tests/rm/rm-readdir-fail.sh Thanks for confirming your __LP64__ setting.

bug#29886: tests/rm/rm-readdir-fail is failing with SIGBUS on Gentoo sparc

On 11/07/18 10:05, Paul Eggert wrote: > Thomas Deutschmann wrote: > >> Not sure if this is a kernel problem. Isn't test suite using >> LD_PRELOAD to pull in additional libraries which could cause >> such a breakage? > > You're right, it could be a library problem. The test suite's LD_PRELOAD >

bug#31873: head/tail --help K != N

tag 31873 notabug close 31873 stop On 17/06/18 14:47, Karl Berry wrote: > It's just an idea, and a tiny one at that, but I was momentarily > perplexed by the lines like > -n, --lines=[-]K > in head --help, making it look like the number is given in kilobytes, > when I knew that was not correct

bug#31493: please add null-terminated line output for sha256sum, sha1sum, etc

On 18/05/18 07:49, Daniel Kahn Gillmor wrote: > Hi GNU coreutils developers! > > This is a feature request for the hashing/digesting tools in coreutils, > like sha256sum, sha1sum, md5sum, etc. > > currently, those tools emit line-oriented output about the files that > they hash. if a file has a

bug#31712: cp --attributes-only

tag 31712 notabug close 31712 stop On 19/05/18 00:54, kalle wrote: > hello, > I have coreutils 8.26 > and the option > > cp --attributes only FILE OTHERFILE > > correctly doesn't copy the content of FILE, > but the modification time of OTHERFILE is the actual date, whereas I > understood that

bug#31675: Existing directories and files permissions are not being kept intact

On 03/06/18 15:43, Pádraig Brady wrote: > Actually looking more, this is a relatively recent change: > https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.19-145-g24ebca6 > > Also in retrospect, using --no-preserve=mode should > have no guarantees on the mode bits of

bug#31675: Existing directories and files permissions are not being kept intact

iles and directories? >> >> Is there a way I can tell cp to preserve destination permissions now? >> >> Thanks & Regards >> Gunjan Gupta >> >> On Mon 4 Jun, 2018, 3:50 AM Pádraig Brady, wrote: >> >>> tag 31675 notabug >>> close 31

bug#31675: Existing directories and files permissions are not being kept intact

tag 31675 notabug close 31675 stop On 31/05/18 20:50, Gunjan Gupta wrote: > Hi, > > Suppose I have the following directory structure > > / > | - destination (mode=0755) > | - dir (mode=0755) > | - file.txt (mode=0644) > | - source > | - dir (mode=0755) > | -

bug#31644: tests/ls/abmon-align does not work today (May 29th)

t; > > On Wednesday, March 14, 2018 7:40:31 PM CEST Pádraig Brady wrote: >> Given the increase in supported size should only impact relatively few >> languages it probably makes sense to increase to 12. The attached does that >> and also augments the test to find ambig

bug#31600: [PATCH] man: Some formatting fixes in "du.x" and "rm.x"

On 25/05/18 17:10, Bjarni Ingi Gislason wrote: > Change ".BR" to ".B" if there is only one argument. > > Protect an end-of-sentence indicator (.?!) with '\&' if it does not > mean an end of a sentence. > > Change '--' to '\-\­' if it indicates an option. > > Change '\=' to '='. > >

bug#31184: tail -f on Network FS not refreshing as soon as the file is changed.

On 22/05/18 14:23, Jewsco Pius Jacquez wrote: > Any more ideas? > > Thanks, > Jewsco > > -Original Message- > From: Jewsco Pius Jacquez > Sent: Tuesday, May 8, 2018 8:56 AM > To: 'Pádraig Brady' <p...@draigbrady.com>; 31...@debbugs.gnu.org > Subject:

bug#31493: please add null-terminated line output for sha256sum, sha1sum, etc

On 18/05/18 07:49, Daniel Kahn Gillmor wrote: > So i'm proposing a flag -z, --zero-terminated for these tools that > alters the output (and input) format, to use NUL chars instead of > newlines. presumably when that flag is used, the emitted data should > *not* be backslash-escaped. This is a

bug#31335: Fwd: bug#31335: unexpected cp -f behavior

On 16/05/18 00:03, Pádraig Brady wrote: > Agreed. I can't think of a case where replacing a self symlink > is not what you'd want to happen. > > Proposed patch is attached. Now pushed at: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.29-37-gc732388 cheers, Pádraig

bug#31335: Fwd: bug#31335: unexpected cp -f behavior

On 15/05/18 17:11, Paul Eggert wrote: > On 05/15/2018 10:05 AM, Pádraig Brady wrote: >>> It's also what I would expect, if I use -f, I expect cp will do everything >>> it can to force the operation and succeed if all possible. >> Maybe, though that's worth furthe

bug#31335: Fwd: bug#31335: unexpected cp -f behavior

On 03/05/18 23:24, Ernesto Alfonso wrote: > did not reply all > > -- Forwarded message -- > From: Ernesto Alfonso <erjoa...@gmail.com> > Date: Thu, May 3, 2018 at 11:10 PM > Subject: Re: bug#31335: unexpected cp -f behavior > To: Pádraig

bug#31364: cp -rfs: Fails to overwrite a symlink when it is on a different device

Pushed at https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.29-36-gd3daa95 marking this as done cheers, Pádraig.

bug#31364: cp -rfs: Fails to overwrite a symlink when it is on a different device

On 06/05/18 18:58, Jason Smith wrote: > Hello, Pádraig, > > I was actually the one to identify the bug and analyze the code underlying it > (Illia, my colleague, was kind enough to volunteer to file the bug report and > attempt a patch), and so I may be in the better position to follow up on >

bug#31439: Possible memory leak in fts.c

On 12/05/18 18:50, ISE Development wrote: > Hi, > > I may be wrong but I suspect there is a corner case where fts_close() > will not free the FTSENT structures correctly if called immediately > after fts_open(). > > After fts_open(), the current entry is a dummy entry created as > follows: > >

bug#31439: [PATCH] fts: avoid a memory leak edge case

On 12/05/18 18:50, ISE Development wrote: > Hi, > > I may be wrong but I suspect there is a corner case where fts_close() > will not free the FTSENT structures correctly if called immediately > after fts_open(). > > After fts_open(), the current entry is a dummy entry created as > follows: > >

bug#31424: BUGREPORT for "nl" command

tag 31424 notabug close 31424 stop On 11/05/18 13:32, Peter Patoschka wrote: > nl: ungültiges Zeilennummerformat: »=ln“ There is a subtlety here with '=' Note the error states "=ln" so it's indicated at least there is an issue with the '='. In general short options do not use '=' but rather

bug#31364: cp -rfs: Fails to overwrite a symlink when it is on a different device

On 04/05/18 16:37, Illia Bobyr wrote: > Hello, > > I have found a bug in "cp -rfs". > > Steps to reproduce: > > 1. Given "path1" and "path2" are on different devices. > 2. $ touch "path1/file" > 3. $ cd path2/; ln -s path1/file > 4. $ cp --symbolic-link --force --recursive path1/file . > >

bug#31184: tail -f on Network FS not refreshing as soon as the file is changed.

[jjacquez@cmilsbtest02 coreutils-8.29]$ > > > > Thanks, > Jewsco > > > > > > -Original Message- > From: Pádraig Brady [mailto:p...@draigbrady.com] > Sent: Thursday, May 3, 2018 8:47 PM > To: Jewsco Pius Jacquez <jewscopius.jacq...@amdocs.

bug#31335: unexpected cp -f behavior

On 01/05/18 11:14, Ernesto Alfonso wrote: > > cp -f fails when destination is a recursive symlink: > > $ ln -s self self > $ cat self > self: Too many levels of symbolic links > $ touch a > $ cp a self > cp: failed to access 'self': Too many levels of symbolic links >

bug#31184: tail -f on Network FS not refreshing as soon as the file is changed.

On 02/05/18 06:39, Jewsco Pius Jacquez wrote: > I tried and the --follow=name doesn't refresh either. The stat output is > changing. > > [jjacquez@cmilsbtest03 ~]$ tail --follow=name /media/samba/test.file > append Wed May 2 08:35:54 CDT 2018 > append Wed May 2 08:35:54 CDT 2018 > append Wed

bug#31184: tail -f on Network FS not refreshing as soon as the file is changed.

On 19/04/18 07:43, Jewsco Pius Jacquez wrote: > Pádraig, thanks for your response. > > In my reproducer environment, it doesn't totally update. RHEL7 Samba server, > RHEL6 Samba client. > > Unless I provided the extra interval parameter. You said you used: tail --follow=name

bug#31225: undocumented change in tail in 8.28 (pipe output monitoring)

On 20/04/18 07:56, Dr. Thomas Orgis wrote: > Hi all, > > during debugging of a background process issue where I have tail -f > feeding into a pipe, I was surprised by a change in tail introduced in > release 8.28 of GNU coreutils: The monitoring of the output pipe and > silent exit of tail e.g.

bug#31215: coreutils env fails in a bash shebang

On 18/04/18 17:18, William Schmidt wrote: > I think I've found a bug in *coreutils*, *env*. > > Linux debian 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) > x86_64 GNU/Linux > > All my Perl scripts contain either of these shebangs: > > #!/usr/bin/env perl -w > or > #!/usr/bin/env

bug#31184: tail -f on Network FS not refreshing as soon as the file is changed.

Could you clarify whether the rhel7 version of tail is too slow when showing updates to the file, or misses updates to the file entirely. There have been various fixes to tail, so it would be worth verifying how the latest behaves, like: wget

bug#31183: ls --block-size and -l

tag 31183 notabug close 31183 stop On 16/04/18 09:19, Hugo Connery wrote: > Hi, > > ls --block-size=M foo > > foo > > Doesn't --block-size imply -l (so that I can see the file size) ? --block-size is more of a config option, than one that should imply a mode. In addition it's applicable to

bug#31184: tail -f on Network FS not refreshing as soon as the file is changed.

On 16/04/18 10:11, Jewsco Pius Jacquez wrote: > Hello, > > We have a legacy application that is using tail -f command in the application > and is running in Redhat 9 under a shared Samba filesystem. > > We want to migrate the application to RHEL7 and we noticed that the tail -f > command here

bug#30928: no error val returned by 'nice' failure?

On 24/03/18 16:32, L A Walsh wrote: > > > Paul Eggert wrote: >> L A Walsh wrote: >>> how do you tell if the resetting of the >>> priority worked or failed? >> >> I guess you're supposed to look at stderr, which is what you did. >> >> This is the way 'nice' has behaved for quite some time, and

bug#31013: mv utility bug or how to create `hairy eyes` directory

tag 31013 notabug close 31013 stop On 31/03/18 12:55, Andry wrote: > Hello Bug-coreutils, > > Seems this bug has waited ages before anybody has noticed it. > I am not a Linux fan, but this one bug was my most one-shot-bug > I've ever catched from a thing first time usage (VirtualBox

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

On 14/03/18 15:53, Rafal Luzynski wrote: > 14.03.2018 19:40 Pádraig Brady <p...@draigbrady.com> wrote: >> [...] >> One can browse the abbreviations by length using: >> >> locale -a | grep utf8 | >> while read l; do LC_ALL=$l locale abmon; done | >> tr '

bug#30795: Issue with date command and EDT

On 15/03/18 00:15, Assaf Gordon wrote: > Hello, > > On Wed, Mar 14, 2018 at 05:22:04PM -0700, Paul Eggert wrote: >> On 03/13/2018 06:42 PM, Assaf Gordon wrote: >>> Therefore it is always recommended to use noon (12pm) >>> as explicit time when adjusting days >> >> Maybe "date" should default to

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

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] > that the current limit of the maximum length of the

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

On 20/02/18 00:04, Declercq Laurent wrote: > Le 20/02/2018 à 04:26, Pádraig Brady a écrit : >>> 2. Non-permission bits are preserved, even when the --no-preserve=mode >>> option is involved. >>> >>> Original file to copy: prwSrw-rw- 1 root staff 0 févr.

bug#30534: cp - Possible bugs when not preserving mode (explicit) and when copying special files

On 19/02/18 02:22, Declercq Laurent wrote: > I think that I did found at least two bugs in cp(1) command when the > --no-preserve=mode option is involved and when copying special file. I > describe each of them below. > > 1. Mode set on special files seem to be wrong: > > Original file to

bug#29617: `seq 1 --help' doesn't give help

On 18/02/18 10:41, chadweis...@nym.hush.com wrote: > >> On 12/08/2017 11:38 AM, Eric B wrote: >>> Hello, >>> >>> I am using coreutils version 8.27 on Fedora, and I don't see this fixed in >>> 8.28's NEWS. >>> >>> $ seq 1 --help >>> seq: invalid floating point argument: ‘--help’ >>> Try 'seq

bug#30430: [column] accounting for ansi color codes

On 11/02/18 22:07, Boruch Baum wrote: > The `column -t' command doesn't align input properly when that input > includes ansi color codes. > > An argument that it should do so, is that `column' serves to make input > more readable, and easier to find and compare fields of input data - the > same

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

On 15/02/18 16:44, Ian Morris Nieves wrote: > Hello all, > > Apologies if I have incorrectly followed any conventions. I’ve tried. > Attached please find a new feature I created to simplify setting permissions > (especially recursively), which enables the user to separately target files > or

bug#30253: Fix for bug 21062 coreutils-8.24 - cp(1) check failures on tmpfs filesystem (Solaris 10 / Solaris 11)

forcemerge 21062 30253 stop On 25/01/18 14:34, Alexander Pyhalov wrote: > Hello. > > I have a fix for 'bug 21062 coreutils-8.24 - cp(1) check failures on > tmpfs filesystem (Solaris 10 / Solaris 11)'. > > The issue is that when on tmpfs we use acl(), trying to set ACL, it sets > errno to

bug#30174: shred bug - 1st byte written is wrong sometimes

tag 30174 notabug close 30174 stop On 19/01/18 10:19, devz...@web.de wrote: > Hi, > > i`m testing wear-levelling of an SLC USB Stick (cheap one i want to > use them for long-term data-logging) and found shred to be a useful > and fast utility to repeatedly overwrite a file's region (the >

bug#29961: [PATCH] mv -n: do not overwrite the destination

t. Sorry, I misread your patch. It should work. > >> On Friday, January 5, 2018 4:29:55 PM CET Pádraig Brady wrote: >> >>> Paul's also avoids a stat() in the common case >>> where the initial renameat2() succeeds. >> At the cost of _not_ avoiding the renameat2()

bug#29989: coreutils-8.29 make test fail

On 05/01/18 07:16, GS wrote: > Good day > > please find enclosed test-suit.log file as requested and my terminal file. For future ref, terminal file is redundant when we have the test-suite.log The pertinent part of your log is: FAIL: tests/df/df-symlink = ++ df

bug#29961: [PATCH] mv -n: do not overwrite the destination

On 05/01/18 11:56, Kamil Dudka wrote: > On Friday, January 5, 2018 2:00:52 AM CET Paul Eggert wrote: >> On 01/04/2018 03:01 AM, Kamil Dudka wrote: >>> On Thursday, January 4, 2018 10:48:56 AM CET Paul Eggert wrote: Kamil Dudka wrote: > - if (rename (src_name, dst_name) == 0) > +

bug#29961: [PATCH] mv: document the missing atomicity of 'mv -n'

On 03/01/18 15:01, Kamil Dudka wrote: > * src/mv.c (usage): Add note about the missing atomicity of 'mv -n'. > * doc/coreutils.texi (mv invocation): Likewise. > --- > doc/coreutils.texi | 3 +++ > src/mv.c | 2 ++ > 2 files changed, 5 insertions(+) > > diff --git a/doc/coreutils.texi

bug#29946: no -A argument for 'tr' generates an error message whenever the AIX command "lslpp -L" is used (AIX 6.1 and later).

On 03/01/18 04:16, Paul Eggert wrote: > +case 'A': > + /* Undocumented option, for compatibility with AIX. */ > + setlocale (LC_COLLATE, "C"); > + setlocale (LC_CTYPE, "C"); > + break; I'm ok with this as it's undocumented. Thanks for doing this.

bug#29946: no -A argument for 'tr' generates an error message whenever the AIX command "lslpp -L" is used (AIX 6.1 and later).

On 02/01/18 16:32, Michael wrote: > 1). AIX 5.3 (/usr/bin/tr) as an argument (-A) that was not used by the > command 'lslpp', so the message does not occur: > > root@x064:[/home/prj/gnu/coreutils-8.29]/usr/bin/tr -A > tr: 0653-712 The combination of options and String parameters is not legal.

bug#29921: O(n^2) performance of rm -r

tag 29921 notabug close 29921 stop On 31/12/17 21:07, Niklas Hambüchen wrote: > Hello, > > in commit > > rm -r: avoid O(n^2) performance for a directory with very many entries > http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=24412edeaf556a > > it says that `rm -r` > > "now

bug#29832: Bug in 'ls -FQ': incorrectly quoted characters

On 24/12/17 07:14, hacke...@member.fsf.org wrote: > Hello! > > Thank you for your continued improvements and maintenance of 'ls' in > coreutils-8.28. > > I have found a somewhat subtle bug. I've included a patch and a test script > to make sure there are no regressions. > > In short, the

bug#29802: "uniq -c" doesn't like counting lines with nulls

On 21/12/17 08:40, PD wrote: > # Whoops, fail to count duplicate binary lines: > # printf "\n\x00\n\x00\n" | uniq -c | cat -e > 1 $ > 1 ^@$ > 1 ^@$ Not reproducible on recent versions. Might this have been specific to the i18n patch? I.E. can you reproduce with LC_ALL=C set

bug#29390: chmod man page - clear setuid/setgid with numerical value

On 21/11/17 18:46, Oliver Isaac wrote: > Hello, > > There is an incorrect assertion made in the chmod man page: > > Under the setuid/setgid header it says, "you can set (but not clear) the bits > with a numeric mode" > > This is not entirely true. If you prefix your numeric mode with a 0 then

bug#29317: info shred:documentation feedback

On 16/11/17 03:38, kalle wrote: > hello, > > - at the sentence "by default does not truncate": what does truncating a > file means? Could this be described better in the manual? > -part "on a busy system": why is this written here? Is this a usual > method to overwrite content? truncate

bug#29315: info cp: documentation feedback

On 16/11/17 03:36, kalle wrote: > hello, > here some mistakes/improvement proposals to `info cp' from me: > > -sentence "If the `--target": take away "failing that"? It's better as is, to document that these are separate modes > -sentence "descending into source directories": shouldn't it be

bug#29606: Command 'fold' dangerous with utf-8 input

On 08/12/17 19:15, Assaf Gordon wrote: > Hello Mark, > > First, > thank you for taking the time and effort > to test our development snapshot, and reporting results back. > This kind of feedback is critical in getting multibyte support ready. > > > Second, > I can confirm the behavior you are

bug#29563: [PATCH] doc: fix default QUOTING_STYLE for %N format of stat(1)

On 04/12/17 08:06, Kamil Dudka wrote: > * doc/coreutils.texi (stat invocation): The default value > of QUOTING_STYLE for the %N format of 'stat --printf' is > 'shell-escape-always'. > > Reported by Christian Groessler at > https://bugzilla.redhat.com/1520399#c3 > --- > doc/coreutils.texi | 2 +-

bug#21760: timeout: Feature Request: --verbose ==> output if timeout

On 28/11/17 14:48, Bernhard Voelker wrote: > On 11/28/2017 11:03 AM, Pádraig Brady wrote: >> Attached is a diff to change to using sed. > > Thanks, I merged your changes. > > Please note that this new check only works with the patch applied > discussed at: >http:/

bug#21760: timeout: Feature Request: --verbose ==> output if timeout

On 27/11/17 16:06, Bernhard Voelker wrote: > On 11/27/2017 07:21 PM, Pádraig Brady wrote: >> Blush. Please apply. > > Thanks, pushed. > >>> BTW: what do you think about a new syntax-check rule to verify that >>> all options in usage are actually supported? &g

bug#21760: timeout: Feature Request: --verbose ==> output if timeout

On 27/11/17 07:18, Bernhard Voelker wrote: > [sending again, because the first try came back with some unclear > error message, and the message didn't show up on the ML so far.] > > On 11/24/2017 02:48 AM, Pádraig Brady wrote: >> Pushed with those improvements. > > Sorr

bug#29421: bug in command "tr"

tag 29421 notabug close 29421 stop On 23/11/17 17:01, wangjian wrote: > Hi there, I think this is a bug > > mkdir empty_foler > cd empty_foler > touch a > echo "abc" | tr [:blank:] + # you will get “+bc” as output, instead of “abc” > touch b > echo "abc" | tr [:blank:] # you will get “bbc” as

bug#21760: timeout: Feature Request: --verbose ==> output if timeout

On 23/11/17 15:38, Jim Meyering wrote: > On Thu, Nov 23, 2017 at 2:35 PM, Pádraig Brady <p...@draigbrady.com> wrote: > ... >>> So I'm leaning towards supporting --verbose which would output something >>> like: >>> >>> timeout: aborting command 'b

bug#21760: timeout: Feature Request: --verbose ==> output if timeout

On 03/10/17 23:36, Pádraig Brady wrote: > On 02/10/17 07:04, Ian Jackson wrote: >> I have to say that I find this bug thread quite perplexing. >> >> It is completely normal for a GNU/Unix command line utility to print a >> message to stderr in error cases. Almo

bug#29259: tail does not seek to the end of block device

On 12/11/17 22:21, Pádraig Brady wrote: > On 12/11/17 21:52, Paul Eggert wrote: >> Why doesn't lseek work for this? > > Good call, it probably would. > Something like the following is more acceptable > since it adds very little complexity: Full patch attached with tests. c

bug#29259: tail does not seek to the end of block device

On 12/11/17 21:52, Paul Eggert wrote: > Why doesn't lseek work for this? Good call, it probably would. Something like the following is more acceptable since it adds very little complexity: diff --git a/src/tail.c b/src/tail.c index 1c7418d..a10470b 100644 --- a/src/tail.c +++ b/src/tail.c @@

bug#29259: tail does not seek to the end of block device

On 11/11/17 12:08, David Durham wrote: > sudo tail -c 1024 /dev/sda2 | hd the entire /dev/sda2 device rather than > seeking to the end. This takes a very long time with large disks. Deltik > gives a nice explanation here - >

bug#29167: Acknowledgement (tests/ls/readdir-mountpoint-inode.sh is unstable and should require root privileges)

On 06/11/17 04:06, Thomas Deutschmann wrote: > Hi, > > here's a better fix (from Sebastian Kühn via > https://bugs.gentoo.org/353164): > > diff --git a/tests/ls/readdir-mountpoint-inode.sh > b/tests/ls/readdir-mountpoint-inode.sh > index b4ca9e46e..5270df079 100755 > ---

bug#29038: df hangs on fifos/named pipes

On 29/10/17 23:16, Paul Eggert wrote: > Pádraig Brady wrote: > >> I suppose we could stat() and if that succeeds && !fifo, only then call >> open() ? >> Patch to do that is attached. > > Better is to use open with O_NONBLOCK, as this avoids interpreting

bug#29038: df hangs on fifos/named pipes

On 28/10/17 00:18, Stephane Chazelas wrote: > test case: > >mkfifo p >df p > > That hangs, unless you make "p" non-readable or some other process > has the fifo open in write mode. > > The reason is that df tries to open the fifo in read-only mode, > according to comments in the source

<    1   2   3   4   5   6   7   8   9   10   >