bug#44248: Indentation of --help and --version

On 27/10/2020 02:19, Paul Eggert wrote: One way to attack the problem is (1) use only one-liners for option help, and (2) not worry about indentation so much (either in English or in German) as the excess indenting doesn't help readability enough to justify the translation hassle. To do that, I

bug#44248: Indentation of --help and --version

On 27/10/2020 00:03, Roland Illig wrote: Hi, > Some of the programs add an empty line before the --help and --version lines, which looks ok. Several others do not add a line, which looks wrong. This should be consistent among all coreutils. I agree we should make things as consistent as

bug#44235: [PATCH] dd: drop old workaround for lseek() bug in Linux kernel

On 26/10/2020 10:44, Kamil Dudka wrote: The workaround triggers warnings with new kernel versions in case a user does not have sufficient privileges for the MTIOCGET ioctl. * src/dd.c (skip_via_lseek): Drop wrapper function no longer needed. (skip): Use lseek() directly.

bug#44105: The included file "help2man" is too old; correction

On 21/10/2020 01:02, Brendan O'Dea wrote: On Wed, 21 Oct 2020 at 08:31, Bjarni Ingi Gislason wrote: On Tue, Oct 20, 2020 at 04:46:05PM +, Bjarni Ingi Gislason wrote: The included file "man/help2man" is version 1.47.3 from 2015, while the current version is 1.47.16 from 2020. This

bug#43684: Problem with numerical splitting with files > 90*l

On 29/09/2020 15:20, Assaf Gordon wrote: On 29/09/2020 02:18, ned haughton wrote: When splitting with -d, the numbering screws up after 89: In addition to Pádraig explanation, please see previous similar discussion here:

bug#43707: [PATCH] stat: use a colon before a list, and don't use backticks as quotes

On 29/09/2020 13:31, Benno Schulenberg wrote: * src/stat.c (usage): Replace a mistaken semicolon with a colon, and replace mistaken backticks with single quotes. Also reorder some words, for clarity. Pushed at:

bug#43684: Problem with numerical splitting with files > 90*l

tag 43684 notabug close 43684 stop On 29/09/2020 02:18, ned haughton wrote: When splitting with -d, the numbering screws up after 89: It behaves like that on purpose so that there is no limit on the number of file names to split, and so that normal globbing will result in the correct order

bug#43497: ls exit status on removed directory

On 19/09/2020 00:15, Philip Rowlands wrote: Steps to reproduce: $ mkdir /tmp/abc $ cd /tmp/abc $ rmdir /tmp/abc $ ls What happened: no output, successful exit status What was expected: no output, unsuccessful exit status ls tried to list the contents of . but failed to do so, at least on

bug#42831: timeout --foreground html manual

On 12/08/2020 16:56, Jonny Grant wrote: https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation I'd like to propose a clarification to this line: "This is needed to support timing out commands not started directly from an interactive shell, in two

bug#42795: stty settings

tag 42795 notabug close 42795 stop On 10/08/2020 07:42, Владимир Гультяев via GNU coreutils Bug Reports wrote: Looks like “-” is not_optoinal but mandatory for stty settings man stty | grep icrnl “ [-]icrnl translate carriage return to newline” effects some applications using tty

bug#42764: csplit does not suppress the last match when not using {*}

On 08/08/2020 10:12, Emanuele Giacomelli via GNU coreutils Bug Reports wrote: Good day, I am experiencing an odd behaviour in csplit which may actually be a bug. I am testing this against the code cloned from https://github.com/coreutils/coreutils.git, on the commit described by git as

bug#42633: 8.32 make check as root failure of rmdir/ignore.sh

On 31/07/2020 18:56, Bernhard Voelker wrote: On 2020-07-31 16:32, Nick Alcock wrote: I get an ERROR when running rmdir/ignore.sh as root (but not when running as non-root). [...] ERROR: tests/rmdir/ignore = [...] + mkdir -p x/y + chmod a-w x + returns_ 1 rmdir

bug#41634: 'timeout' returning 124 and 133

On 28/07/2020 22:38, Bernhard Voelker wrote: On 2020-07-16 00:59, Jonny Grant wrote: On 15/06/2020 21:57, Bernhard Voelker wrote: Hmm, in the HTML format, this is the first sentence after the table of contents: "This manual documents version 8.32 of the GNU core utilities, ..." Hi Berny

bug#42135: [PATCH] Fix spurious testsuite failure

On 30/06/2020 12:05, Andreas Schwab wrote: * tests/dd/stats.sh: Bump timeout. --- tests/dd/stats.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/dd/stats.sh b/tests/dd/stats.sh index 22ba3b014..fe5302de8 100755 --- a/tests/dd/stats.sh +++ b/tests/dd/stats.sh @@

bug#42044: nproc says "1" on mobile processors

On 25/06/2020 18:37, Adam Borowski wrote: Hi! I'm afraid that `nproc` shows only the number of _currently_ online CPUs, which on mobile processors tends to be 1 when starting a job. As there's a need to conserve power, holding cores online when they have nothing to do would be a waste, thus

bug#41962: Errors in man coreutils pages

On 20/06/2020 18:56, Helge Kreutzmann wrote: Hello Pádraig, On Sat, Jun 20, 2020 at 06:25:25PM +0100, Pádraig Brady wrote: On 20/06/2020 07:48, Helge Kreutzmann wrote: Thanks for reporting these issues. They should be addressed in the attached. Thanks for your quick reply. Man page: rm.1

bug#41935: tail: unrecognized file system type 0x786f4256

On 20/06/2020 15:15, Bernhard Voelker wrote: On 2020-06-18 17:57, Pausch Manfred wrote: Hello When I tail a logfile that’s located on a VirtualBox guest shared folder than I get this message: tail: unrecognized file system type 0x786f4256 for ‘oracle_12102_PSU190716-20200618_174315.log’.

bug#41962: Errors in man coreutils pages

On 20/06/2020 07:48, Helge Kreutzmann wrote: Thanks for reporting these issues. They should be addressed in the attached. Man page: rm.1 Issue: FIXME I<> → B<> "B<--preserve-root>[=I<\\,all\\/>]" The 'I' is auto generated by help2man and consistent with other uses. What's the specific

bug#41850: [PATCH] maint: Avoid signed integer overflows

On 14/06/2020 13:47, Tobias Stoeckmann wrote: Since -LONG_MIN results in LONG_MIN again, the operation itself is a signed integer overflow. This can be observed with the following calls (best if compiled with -ftrapv or -fsanitize=undefined): $ numfmt --padding=-9223372036854775808 $ seq

bug#41634: 'timeout' returning 124 and 133

On 07/06/2020 13:38, Bernhard Voelker wrote: Minor, grammar-related question: +Upon timeout send the TERM signal to COMMAND, if no other SIGNAL specified.\n\ ___^ s/timeout/&,/ ? I stumbled upon this sentence a couple of times - shouldn't there be a comma? The word 'timeout'

bug#41634: 'timeout' returning 124 and 133

On 06/06/2020 00:37, Bernhard Voelker wrote: On 2020-06-01 10:01, Jonny Grant wrote: My mistake missing that. But could the 137 be listed explicitly? ie. "It may be necessary to use the KILL (9) signal, since this signal cannot be caught, in which case the exit status is 137 (128+9) rather

bug#37702: Suggestion for 'df' utility

On 31/05/2020 10:36, Bernhard Voelker wrote: On 2020-05-31 01:07, Paul Eggert wrote: On 5/30/20 4:49 AM, Erik Auerswald wrote: I concur that a command line option to override config file (or env var) settings seems useful if a config file and/or env var approach is used. Just to mention

bug#41518: Bug in od?

tag 41518 notabug close 41518 stop response below... On 25/05/2020 04:05, Yuan Cao wrote: Hello, I recently came across the following behavior. When using "--traditional x2" or "-x" option, it seems the order of hex code output for the characters is pairwise reversed (if that's the correct

bug#41495: stat birth time issues with coreutils-8.32

On 23/05/2020 22:58, Andy wrote: On my arch linux system, I can't see birth time with coreutils-8.32 with either of - zfs mounts - ext4 mounts But I am having success with: - smb mounts == System details: stat --version > stat (GNU coreutils) 8.32 pacman -Qi coreutils >

bug#41456: fix cases where insecure randomness could be used

On 22/05/2020 16:47, Taylor Hornby wrote: On Fri, May 22, 2020 at 8:17 AM Pádraig Brady wrote: On 22/05/2020 08:19, Taylor Hornby wrote: I reported a potential security bug on GitHub: https://github.com/coreutils/coreutils/pull/32. To save you a click, I'll copy-paste it here (for context

bug#41456: fix cases where insecure randomness could be used

On 22/05/2020 08:19, Taylor Hornby wrote: I reported a potential security bug on GitHub: https://github.com/coreutils/coreutils/pull/32. To save you a click, I'll copy-paste it here (for context this is on a PR with a fix): Comment #1: Apologies for submitting on GitHub, it's so much more

bug#41075: Changes to 'ls' output

tag 41075 notabug close 41075 stop On 04/05/2020 10:43, Chris Elvidge wrote: I have noticed that the output of ls seems to have changed from v8.25 to v8.32 where there is an apostrophe in the filename (sometimes); change from " surrounding to ' surrounding and '\'' replacing '. When output is

bug#40352: cp -a --attributes-only zeroes a file with more than one link

On 31/03/2020 13:32, Matt Kloss wrote: Hello, When you cp -a --attributes-only a [dest] file which has a more than one “hardlink”, it zeroes the file: The attached fixes this, which I'll push later. Marking this as done. thanks! Pádraig >From

bug#40090: rm seems unfinished when calling mkdir

tag 40090 notabug close 40090 stop On 16/03/2020 15:02, Boyen, Peter wrote: When I remove a folder by using rm -rfv ${TEMP_STORAGE}', shortly followed by an 'mkdir -pv ${TEMP_STORAGE}' to recreate the same folder, I get mkdir: cannot create directory './temp_storage': Operation not permitted

bug#39929: coreutils-8.32 fails to build on aarch64

On 05/03/2020 21:43, Paul Eggert wrote: On 3/5/20 9:39 AM, Pádraig Brady wrote: Ah well. Does the attached address this for you. Eeeuw. Why is this code even there at all? If readdir(3) says that the current directory has no entries, shouldn't 'ls' just say that? Why should ls report

bug#39929: coreutils-8.32 fails to build on aarch64

On 05/03/2020 16:21, Kamil Dudka wrote: While trying to build coreutils-8.32 for Fedora on aarch64, I got the following compilation failure: ../src/ls.c: In function 'print_dir': ../src/ls.c:3026:24: error: 'SYS_getdents' undeclared (first use in this function); did you mean 'SYS_getdents64'?

bug#39879: Bug report

On 03/03/2020 06:15, Scott Baden wrote: As request in the output for running "make check" These two issues on macOS will be fixed in the impending release (v8.32) Specifically they were addressed by: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.31-93-gde73a867c thanks,

bug#38627: uniq -c gets wrong count with non-ascii strings

On 17/12/2019 17:25, Roy Smith wrote: I stopped short of actually building uniq.c from source (bootstrap, prerequisites, ...), but looking at the code, it looks like the call chain is: different() xmemcoll() memcoll() strcoll() so I tried a little test at the strcoll() level: #include

bug#39613: stat(1) shouldn't call permissions "Access..."

On 15/02/2020 02:15, 積丹尼 Dan Jacobson wrote: (info "(coreutils) stat invocation") says, • %a - Access rights in octal (note ‘#’ and ‘0’ printf flags) • %A - Access rights in human readable form Fair enough, as one might be confused that ACL info may be output. This may be done in

bug#39485: [PATCH] make tests/cp/preserve-gid work with single binary

On 10/02/2020 14:36, Kamil Dudka wrote: On Saturday, February 8, 2020 12:53:52 PM CET Pádraig Brady wrote: +if test -x "$abs_path_dir_/coreutils" && + { test -l "$abs_path_dir_/cp" || This should be spelled `test -L` I guess. + test $(wc -

bug#39485: [PATCH] make tests/cp/preserve-gid work with single binary

On 07/02/2020 16:05, Kamil Dudka wrote: * tests/cp/preserve-gid.sh: If configured with --enable-single-binary copy the coreutils single binary, instead of the cp one-line launcher. Bug: https://bugzilla.redhat.com/1800597 --- tests/cp/preserve-gid.sh | 8 +++- 1 file changed, 7

bug#39364: [PATCH] rmdir: fix clobbered errno

On 06/02/2020 18:04, Bernhard Voelker wrote: On 2020-02-04 20:21, Pádraig Brady wrote: pushed. marking done Hi Padraig, I just noticed that 'is_empty_dir' from 'src/system.h' is also used in 'src/remove.c', so - without having looked there yet - it could be that the patch changed something

bug#39357: tests/cp/proc-short-read.sh fails in modern build environment

On 04/02/2020 10:34, Kamil Dudka wrote: On Tuesday, February 4, 2020 1:45:06 AM CET Pádraig Brady wrote: On 30/01/2020 13:53, Kamil Dudka wrote: tests/cp/proc-short-read.sh expects that a pair of subsequent reads from /proc/kallsyms will always return the same content. This does not seem

bug#39364: [PATCH] rmdir: fix clobbered errno

On 03/02/2020 16:45, Pádraig Brady wrote: On 03/02/2020 13:26, Pádraig Brady wrote: On 31/01/2020 17:51, Pádraig Brady wrote: Actually I think the key issue is not errno handling, but a logic error fixed with: @@ -102,7 +102,7 @@ ignorable_failure (int error_number, char const *dir

bug#39357: tests/cp/proc-short-read.sh fails in modern build environment

On 30/01/2020 13:53, Kamil Dudka wrote: tests/cp/proc-short-read.sh expects that a pair of subsequent reads from /proc/kallsyms will always return the same content. This does not seem to be a safe assumption any more. The test has started to fail in our build environment. I am not sure how to

bug#39364: [PATCH] rmdir: fix clobbered errno

On 03/02/2020 13:26, Pádraig Brady wrote: On 31/01/2020 17:51, Pádraig Brady wrote: Actually I think the key issue is not errno handling, but a logic error fixed with: @@ -102,7 +102,7 @@ ignorable_failure (int error_number, char const *dir) return (ignore_fail_on_non_empty

bug#39364: [PATCH] rmdir: fix clobbered errno

On 31/01/2020 17:51, Pádraig Brady wrote: On 31/01/2020 01:46, Matthew Pfeiffer wrote: 'rmdir --ignore-fail-on-non-empty' would not report errors on non-empty directories that fail for a different reason. --- src/rmdir.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions

bug#39364: [PATCH] rmdir: fix clobbered errno

On 31/01/2020 01:46, Matthew Pfeiffer wrote: 'rmdir --ignore-fail-on-non-empty' would not report errors on non-empty directories that fail for a different reason. --- src/rmdir.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/rmdir.c b/src/rmdir.c index

bug#37864: bug: env exec bomb (no hash bang arg)

On 22/10/2019 03:13, Michael Coleman via GNU coreutils Bug Reports wrote: One of my users unwittingly stumbled upon the most delightful 'env' bug. It seems to be present in a couple of pretty recent distributions. Try this: #!/usr/bin/env whatever

bug#37702: Suggestion for 'df' utility

On 11/10/2019 20:56, Paul Eggert wrote: On 10/11/19 11:20 AM, Pádraig Brady wrote: if you want to exclude nested file systems like that, you could try:   alias df='df -x squashfs' On my Fedora 30 workstation that option doesn't make any difference. Regardless of whether '-x squashfs

bug#37702: Suggestion for 'df' utility

On 11/10/2019 08:55, John Pye wrote: Hi there I got this email address from the 'df' man page. Hope it's still active and the right place for feedback. With recent changes to Ubuntu and the increasing use of 'snap' packaging for all sorts of things, the 'df' utility output is now quite jumbled

bug#37241: large performance gap when start+inc specified with 'seq'

On 04/09/19 21:42, L A Walsh wrote: > > > On 2019/09/03 18:51, Pádraig Brady wrote: >> Yes we could be better here. >> Attached is a fairly simple improvement: >> >> $ time seq.new 1 1 1e8 >/dev/null >> real 0m1.516s >> >> $ time seq.new 1 2

bug#37241: large performance gap when start+inc specified with 'seq'

On 31/08/19 00:29, L A Walsh wrote: > Was looking at some large sequences and the time they took > and found that while end-point only was fast: > > declare -x TIMEFORMAT="%2Rsec %2Uusr %2Ssys (%P%% cpu)" > >> time seq 1e8 >/dev/null > 0.75sec 0.74usr 0.01sys (99.77% cpu) > > Trying just to

bug#36963: truncate man page

On 07/08/19 20:14, David wrote: > Hi > This is not a bug, but a request to update documentation for truncate. It > should state that truncate creates sparse files. > > Context: >

bug#36887: coreutils-8.31: printf chokes on \u0041

On 01/08/19 12:02, Ulrich Mueller wrote: > [Forwarding bug https://bugs.gentoo.org/680244 as requested by the > Gentoo package maintainer.] > > According to printf(1): > >Interpreted sequences are: >[...] > >\u Unicode (ISO/IEC 10646) character with hex value (4 digits)

bug#36291: od --skip-bytes reads everything from the very beginning

On 19/06/19 09:20, Szőts Ákos wrote: > Dear List members, > > I've recently discovered that od "--skip-bytes" feature doesn't > actually seek into the file but rather it reads everything from the > very beginning until the given offset is reached. > > This can be problematic in two cases: > -

bug#36220: ls -l: maddening mixed left right justifications with numeric ids

On 17/06/19 15:06, Pádraig Brady wrote: > On 15/06/19 03:35, Dan Jacobson wrote: >> Some files might only have numeric user ids, >> >> # ls -l >> -rw-r--r-- 1 777 root 0 06-15 10:14 a >> -rw-r--r-- 1 root 77 0 06-15 10:11 b >> -rw-r--r-- 1 root root

bug#36220: ls -l: maddening mixed left right justifications with numeric ids

On 15/06/19 03:35, Dan Jacobson wrote: > Some files might only have numeric user ids, > > # ls -l > -rw-r--r-- 1 777 root 0 06-15 10:14 a > -rw-r--r-- 1 root 77 0 06-15 10:11 b > -rw-r--r-- 1 root root 0 06-15 10:12 c > -rw-r--r-- 1 root777 0 06-15 10:12 d I guess the numeric IDs

bug#36130: split bug

On 10/06/19 19:28, Heather Wick wrote: > Thank you so much for your response. Here are the results of the tests you > sent: > Verbose: This seems to have made the same number of files this time; not > sure why the other 3-4 times I ran it it did not. They appear to be the > same size, with paired

bug#35291: [PATCH] split: fix incorrect suffix length computation

On 15/04/19 19:05, Johannes Altmanninger wrote: > * src/split.c (set_suffix_length): suffix_needed is now computed > to be the equivalent of ceil(log(n_units_end) / log(alphabet_len)). > Previously, it would give the floor of above logarithm if the number > of units is divisible by the length of

bug#35713: /dev/stdin problem in cp on Solaris

On 13/05/19 11:24, jakub.ku...@oracle.com wrote: > Hi, > > We found out that the following simple command fails on Solaris with: > > cat srcfile.txt | /usr/gnu/bin/cp /dev/stdin dstfile.txt > cp: skipping file '/dev/stdin', as it was replaced while being copied > > I found that problem is

bug#35849: documentation error: wrong command

On 21/05/19 16:46, Martin Castillo wrote: > Hi, > > I found an error in the info page for version 8.31. > As linked below, in the join(1) documentation, the 3rd line is > > sort file1 file1 file2 | uniq > > but should be > > sort file1 file1 file2 | uniq -u > > I wonder, why no one noticed,

bug#14703: stat(1) Linux creation date support

close 14703 stop On 21/05/19 18:35, Zoran Dželajlija wrote: > reopen 14703 > thanks > > Hi, > > - support for statx() syscall was added to Linux kernel 4.11 (in 2017), >says statx(2) man page at http://man7.org/linux/man-pages/man2/statx.2.html >and it also says that > > - support

bug#35247: [PATCH] Add alacritty to terminal list supporting colors

On 12/04/19 12:20, doron.be...@gmail.com wrote: > From: Doron Behar > > https://github.com/jwilm/alacritty > --- > src/dircolors.hin | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/dircolors.hin b/src/dircolors.hin > index 3aa445bfa..424ed5b19 100644 > --- a/src/dircolors.hin >

bug#35531: problem with ls in coreutils

tag 35531 notabug close 35531 stop On 03/05/19 17:01, Peter Edwards wrote: > Hi > > Although this bug report seems to be a problem with the windows port > of ls, it reminded me of an interesting investigation into slow ls > speeds due to colorizing via the LS_COLORS environment variable. > >

bug#35650: [PATCH] Improving HP-UX support

On 09/05/19 03:50, Osipov, Michael wrote: > Hi folks, > > please find a patch attached to properly compile and link GNU coreutils > 8.31 on HP-UX IA64. As of now, it does not compile out of the box. > > The patch includes these changes: > > * basenc.c: HP aCC does not allow anonymous unions

bug#35046: [PATCH] factor: check the standard output instead of the standard input

On 30/03/19 22:14, Paul Eggert wrote: > Pádraig Brady wrote: >>> -line_buffered = isatty (STDIN_FILENO); >>> +line_buffered = isatty (STDOUT_FILENO); >>> if (line_buffered) >>> lbuf_flush (); >>> else if (b

bug#35041: tee: use STDIN_FILENO instead of 0

On 29/03/19 11:16, Martin Castillo wrote: > I was reading through tee.c and saw > 231: bytes_read = read (0, buffer, sizeof buffer); > > Maybe it should read > read(STDIN_FILENO, buffer, sizeof buffer); > ? > > Greetings, > Martin Castillo Pushed:

bug#35046: [PATCH] factor: check the standard output instead of the standard input

On 29/03/19 23:43, Shugo Maeda wrote: > * src/factor.c (lbuf_putc): Use line buffered mode if the standard > output (not the standard input) is a terminal in the same way as the > stdio library. User programs might use pty only for the standard out > like the example of Ruby's PTY module: >

bug#34876: [bug-coreutils] ln 8.31 on Solaris 10 is partially broken

On 16/03/19 14:08, Pádraig Brady wrote: > On 16/03/19 11:27, Paul Eggert wrote: >> Nelson H. F. Beebe wrote: >> >>> touch foo bar && ls -ld foo bar && ln -f foo bar >>> ... >>> -rw-rw-r-- 1 bowman sysstaff 0 Mar 15 15:55 bar >>

bug#34876: [bug-coreutils] ln 8.31 on Solaris 10 is partially broken

On 16/03/19 11:27, Paul Eggert wrote: > Nelson H. F. Beebe wrote: > >> touch foo bar && ls -ld foo bar && ln -f foo bar >> ... >> -rw-rw-r-- 1 bowman sysstaff 0 Mar 15 15:55 bar >> -rw-rw-r-- 1 bowman sysstaff 0 Mar 15 15:55 foo >> ln: failed to access 'bar/foo': Not a directory > > Thanks for

bug#34524: wc: word count incorrect when words separated only by no-break space

On 09/03/19 05:52, Bruno Haible wrote: > Hi Pádraig, > In regard to options for enabling various behaviors for wc(1), I'm thinking we might keep the strict POSIX isspace() behavior with LC_CTYPE=C and/or POSIXLY_CORRECT=1, and use iswnbspace() by default > > Since you plan to

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 03/03/19 16:59, Pádraig Brady wrote: > A summary of the all signal options in my local set now is: > > --block-signal[=SIG]block delivery of SIG signal(s) to COMMAND > --unblock-signal[=SIG] unblock delivery of SIG signal(s) to COMMAND > --default-signal[=SIG] reset

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 03/03/19 16:07, Pádraig Brady wrote: > On 03/03/19 15:36, Pádraig Brady wrote: >> On 25/02/19 22:35, Pádraig Brady wrote: >>> Thanks for doing all that. >>> I've attached a few changes: >>> >>> - spelling fixes >>> - usage() clarified/reord

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 03/03/19 15:36, Pádraig Brady wrote: > On 25/02/19 22:35, Pádraig Brady wrote: >> Thanks for doing all that. >> I've attached a few changes: >> >> - spelling fixes >> - usage() clarified/reordered >> - ensure sigset_t are initialized >> - Don't s

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 25/02/19 22:35, Pádraig Brady wrote: > Thanks for doing all that. > I've attached a few changes: > > - spelling fixes > - usage() clarified/reordered > - ensure sigset_t are initialized > - Don't setprocmask() unless specified > - Simplified SETMASK_SIGNAL_OPTION hand

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

On 26/07/18 18:23, Paul Eggert wrote: > Pádraig Brady wrote: >> I've pushed the c_iscntrl patch since it's simplest >> and probably most appropriate patch for an existing release. > > Yes, that makes sense for a quick patch. However, for the next release I > think &

bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes

tag 33644 notabug close 33644 stop rationale below... On 12/02/19 04:03, Kamil Dudka wrote: > On Monday, February 11, 2019 7:30:42 PM CET Pádraig Brady wrote: >> On 11/02/19 03:50, Kamil Dudka wrote: >>> I think that the information in xattr.conf is correct. system.nfs4

bug#34664: Mention wc default action on man page

tag 34664 notabug close 34664 stop On 26/02/19 02:47, 積丹尼 Dan Jacobson wrote: > INFO says >By default, ‘wc’ prints three counts: the newline, words, and byte > and wc --help even more so. > > Alas man wc doesn't say if what we are looking at is bytes or > characters, so kindly mention the

bug#34681: mv fails when renaming on external drive in coreutils 8.30-2

On 27/02/19 14:20, Derek Dongray wrote: > When trying to use mv to rename a file on an external drive using coreutils > 8.30-2 on a debian system (Linux version 4.19.0-3-amd64), the rename fails > with the error message: > > mv: cannot move 'file1' to a subdirectory of itself 'file2' > >

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

Thanks for doing all that. I've attached a few changes: - spelling fixes - usage() clarified/reordered - ensure sigset_t are initialized - Don't setprocmask() unless specified - Simplified SETMASK_SIGNAL_OPTION handling - The test missed `env` as a prerequisite - The test was slow/spun cpu, so

bug#34524: wc: word count incorrect when words separated only by no-break space

On 24/02/19 19:55, Pádraig Brady wrote: > On 24/02/19 17:07, Pádraig Brady wrote: >> So non break space is generally considered a word delimiter, >> though there are complications you detail from unicode. >> >> In regard to options for enabling various behaviors for wc(1

bug#34524: wc: word count incorrect when words separated only by no-break space

On 24/02/19 17:07, Pádraig Brady wrote: > So non break space is generally considered a word delimiter, > though there are complications you detail from unicode. > > In regard to options for enabling various behaviors for wc(1), > I'm thinking we might keep the strict POSIX iss

bug#34524: wc: word count incorrect when words separated only by no-break space

On 24/02/19 05:58, Bruno Haible wrote: > [Ccing bug-libunistring, because this is about Unicode handling in GNU. The > original thread is in .] > >>> The man page for wc states: "A word is a... sequence of characters >>> delimited by white

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 18/02/19 01:46, Assaf Gordon wrote: > Hello, > > Thanks for all comments (on and off list). > Attached an updated patch with documentation. > > The supported options are: > > --default-signal[=SIG] reset signal SIG to its default signal handler. > without SIG,

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 18/02/19 08:02, Eric Blake wrote: > On 2/17/19 8:20 PM, Pádraig Brady wrote: >> On 15/02/19 07:20, Eric Blake wrote: >>> Except that POSIX has the nasty requirement that sh started with an >>> inherited ignored SIGPIPE must silently ignore all attempts from with

bug#34524: wc: word count incorrect when words separated only by no-break space

On 18/02/19 00:12, vampyre...@gmail.com wrote: > $ wc --version > wc (GNU coreutils) 8.29 > Packaged by Gentoo (8.29-r1 (p1.0)) > > The man page for wc states: "A word is a... sequence of characters delimited > by white space." > > But its concept of white space only seems to include ASCII

bug#34522: Bug in --help command of comm --help

tag 34522 notabug close 34522 stop On 17/02/19 22:17, Sai Bhargav Varanasi wrote: > Examples: > comm -12 file1 file2 Print only lines present in both file1 and file2. > comm -3 file1 file2 Print lines in file1 not in file2, and vice versa. > > comm -3 prints lines that are unique to both

bug#34583: minor documentation error (info page)

forcemerge 34583 34584 close 34583 stop On 19/02/19 16:20, Martin Castillo wrote: > Hi, > > I found an error in the info page for version 8.29. > > As linked below, in the join(1) documentation, there is the following: > > $ join -v 1 file1 file2 unpaired lines from the first file >

bug#34490: console the user that his -n in sort --debug -n was seen

On 16/02/19 23:28, 積丹尼 Dan Jacobson wrote: >>>>>> "PB" == Pádraig Brady writes: > PB> Fair point. I'm thinking of this extra qualification: > > PB> sort: text ordering performed using ‘en_IE.UTF-8’ sorting rules > Maybe say

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 15/02/19 07:20, Eric Blake wrote: > Except that POSIX has the nasty requirement that sh started with an > inherited ignored SIGPIPE must silently ignore all attempts from within > the shell to restore SIGPIPE handling to child processes of the shell: > > $ (trap '' PIPE; bash -c 'trap - PIPE;

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 15/02/19 14:11, Eric Blake wrote: > On 2/15/19 3:40 PM, Assaf Gordon wrote: >> Helo, >> >> On 2019-02-15 8:20 a.m., Eric Blake wrote: >>> On 2/15/19 8:43 AM, 積丹尼 Dan Jacobson wrote: sort: write failed: 'standard output': Broken pipe sort: write error >> [...] >>> Perhaps coreutils

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 16/02/19 23:24, 積丹尼 Dan Jacobson wrote: > (I recall I heard about 50 years ago when pipe buffers first came to > Unix they were supposed to be invisible to the user...) Right. A lot of folks don't understand/handle them fully though: https://www.pixelbeat.org/programming/sigpipe_handling.html

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

On 17/02/19 13:00, Paul Eggert wrote: > You make good points about nohup. Still, it's too bad that we'd have to add a > new command for such a trivial thing. > > Perhaps it'd be better to overload 'env' instead, as you proposed earlier. > After > all, env is already being used for another

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

On 15/02/19 10:32, Assaf Gordon wrote: > Hello Eric and all, > > > Thanks for the quick and detailed review. > I've amended all the issues you mentioned. > > On 2019-02-13 8:20 p.m., Eric Blake wrote: >>> 15 files changed, 46 insertions(+), 141 deletions(-) >> >> Nice diffstat. > > These are

bug#34490: console the user that his -n in sort --debug -n was seen

On 15/02/19 06:21, 積丹尼 Dan Jacobson wrote: > Can you please have assure the user in that message it makes > that it has indeed seen his -n/--numeric-sort. > > $ sort --debug > sort: using simple byte comparison > $ sort --debug --numeric-sort > sort: using simple byte comparison >

bug#34438: [8.30, info] doc error in -R

On 11/02/19 09:29, Filipp Gunbin wrote: > Hi, > > There's a small bug in doc here: > > ‘-R’ > ‘--rfc-email’ > ... > This format conforms to Internet RFCs 5322 > (https://tools.ietf.org/search/rfc5322), 822 > ^

bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes

On 11/02/19 03:50, Kamil Dudka wrote: > On Monday, February 11, 2019 6:07:18 AM CET Pádraig Brady wrote: >> On 06/12/18 05:08, Kamil Dudka wrote: >>> ... which cannot be preserved by other means >>> >>> Bug: https://bugzilla.redhat.com/1031423

bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes

On 06/12/18 05:08, Kamil Dudka wrote: > ... which cannot be preserved by other means > > Bug: https://bugzilla.redhat.com/1031423#c4 > --- > src/copy.c | 22 +- > 1 file changed, 17 insertions(+), 5 deletions(-) > > diff --git a/src/copy.c b/src/copy.c > index

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)

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