bug#79096: du: -x doesn't detect sshfs file system

On 7/25/25 20:25, Stan Marsh wrote: With "du", I prefer using ~/* instead of just ~ because then you get totals for each (top-level) directory instead of just one grand total. And you get output as you go, not just at the very end (after a long wait/delay). With 'du -sxc ~/*', you explicitly

bug#78910: tail does not support -r added by POSIX.1-2024

On 6/28/25 00:21, Pádraig Brady wrote: I wouldn't be rushing to implement it TBH. Furthermore, -r clashes with the existing -f,--follow ... hence it's even more surprising that POSIX does not specify what should happen for those logically conflicting modes. Have a nice day, Berny

bug#78476: GNU 'factor' problems with 128-bit word

On 5/20/25 09:04, Torbjörn Granlund wrote: The current factor.c code is becoming insanely complex. Contructs masking bugs triggered on hypothetical systems doesn't help with managing complexity. If such hardware seems to be quite some time away, what about guarding the code for the ranges we k

bug#76876: logname output is often wrong when linked with glibc

Hi Padraig, On 3/9/25 13:48, Pádraig Brady wrote: I pushed an update to coreutils NEWS mentioning the fix. Marking this as done. >doc: mention logname improvement in NEWS > >* NEWS: Mention the improvement in gnulib commit 90840606. >Addresses https://bugs.gnu.org/76876 FWIW: That

bug#76768: BUGGY! "cut" AND "printf" in func arg >> $@

[re-adding the list] On 3/6/25 15:32, G. K. wrote: hi bernhard voelker/berny, an explanation in connection with the "cut" program for displaying the files in the current directory, I had to specifically exclude that in your answer. you said that the problem could be the quotation

bug#76768: BUGGY! "cut" AND "printf" in func arg >> $@

tag 76768 notabug close 76768 stop On 3/6/25 03:46, G.K. wrote: #1 echo -e "1\n2\n3\n4"'' | tac | cut -zf-4 First of all, let's simplify the test case: change non-portable 'echo -e' to printf, and avoiding tac(1). $ echo -e '1\n2\n3\n4' | tac | od -tx1z 000 34 0a 33 0a 32 0a 31 0a

bug#76290: "sort -u" vs "sort -h -u": possible bug

On 2/18/25 7:45 PM, Rupert Gallagher via GNU coreutils Bug Reports wrote: By comparison, human (-h) and numeric (-n) sort cause data loss: not really. That's the difference between a) "I have a list containing numbers; I merely care about numbers and want to get a unique, sorted list of

bug#74428: tests/printf/printf-cov failure on macOS

On 12/6/24 14:24, Pádraig Brady wrote: On 06/12/2024 07:13, Bernhard Voelker wrote: On 11/19/24 19:31, Pádraig Brady wrote: OK I've adjusted our test to use \u00032 instead, The bug report was talking about Macos only, but now I'm seeing this failure also on openSUSE for Leap 16.0

bug#74503: Test issues in "make check"

On 11/24/24 06:34, Gordon Steemson wrote: Setup: Coreutils package, v. 9.5; Power Mac G5 running OS 10.5.8 (Darwin 9.8.0). When running `make check`, I noticed the following two problems. - tests/ls/dired.sh can’t cope with the underlying file system stealthily applying normalization to the

bug#73418: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share

The attached fixes the check. Have a nice day, BernyFrom 0911361e79cddc2ffeab043f9ff120c19431384a Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Sun, 6 Oct 2024 16:09:26 +0200 Subject: [PATCH] maint: adjust check-ls-dircolors to recent change in ls.c 'make distcheck' would fail

bug#73418: ls (GNU coreutils) 9.4 is extremely slower than ls (GNU coreutils) 8.32 listing files on a cifs mounted share

On 9/30/24 7:24 AM, Paul Eggert wrote: I installed the attached patch to fix some of the issue There's a new syntax-check failure for a require_root_ test here: FAIL: tests/ls/capability = ++ initial_cwd_=/home/berny/git/coreutils +++ testdir_prefix_ +++ printf gt ++ p

bug#73134: coreutils: df: no file systems processed

On 9/8/24 11:45 PM, Felix Miata wrote: ab85m:~ # df/sys/firmware/efi/efivars/ df: no file systems processed ab85m:~ # Anything any ordinary user can do the superuser ought be able to do, especially when involving OS, right??? This is not necessarily true, because the kernel decides what 'root'

bug#71895: Test failure in Coreutils 9.4 [During LFS Build]

On 7/2/24 10:10, Pádraig Brady wrote: Note some of the output of the test seemed to be elided, so I wasn't able to see exactly the line that failed (No space left on device is an expected case and not the issue here). Latest 'returns_', i.e., after gnulib commit 7b8fe0cfbde, seem to have improv

bug#70298: uname -i returns unknown since fedora 38

On 4/9/24 2:21 PM, Pádraig Brady wrote: Thanks for looking at this. From the Fedora side, they dropped a Fedora specific patch for Fedora 38. https://bugzilla.redhat.com/show_bug.cgi?id=548834 https://bugzilla.redhat.com/show_bug.cgi?id=2208048 FWIW: OpenSUSE still has that patch which was ke

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

On 3/22/24 11:22, Karel Zak wrote: > On Wed, Mar 20, 2024 at 11:53:05PM +0100, Bernhard Voelker wrote:>> On userland OTOH, we have broader choice. >> Karel did his choice in util-linux for exch(1), and coreutils could expose >> the same functionality. >> >> Fo

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

On 3/23/24 02:44, Paul Eggert wrote: I installed the attached patches to do the above. (Basically, the problem was that my earlier patches were too ambitious; these patches scale things back to avoid some optimizations so that mv --exchange is more like ordinary mv.) The first patch simplifies t

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

On 3/21/24 00:56, Paul Eggert wrote: On 3/20/24 15:53, Bernhard Voelker wrote: Yes, that's the expected behavior for this contrived case. Just as one would get odd behavior if one did the same thing without --exchange. There's another which is not consistent with/without --exchange

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

On 3/20/24 21:56, Paul Eggert wrote: On 3/20/24 12:43, Bernhard Voelker wrote: This stems from the fact that although mv(1) is a userland frontend for renameat(2), the user interface is different: while renameat(2) deals exactly with 2 operands, mv(1) has always been able to work on more

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

On 3/17/24 07:10, Paul Eggert wrote: Although removing that "mv --swap" implementation was a win, I don't think we can simply delegate this to util-linux's exch command. I still have some headache adding this. This stems from the fact that although mv(1) is a userland frontend for renameat(2),

bug#68866: man page description of pwd command has error I guess

tag 68866 notabug close 68866 stop On 2/1/24 04:09, Seungchul Lee wrote: man page description has following line, "If no option is specified, -P is assumed." But in my machine, its default behavior seems -L without any option for pwd. 'man pwd' and 'env pwd --help' also tells: NOTE: your sh

bug#62572: cp --no-clobber behavior has changed

On 12/15/23 21:13, Michael Stone wrote: On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote: Stlll, Pádraig gave a reasonable summary of why the change was made, despite its incompatibility with previous behavior. (One thing I'd add is that the FreeBSD behavior is inherently less race-pr

bug#66176: 9.4 root test fails: tests/rm/ext3-perf tests/rm/ext3-perf.sh

On 9/23/23 18:35, Jeffrey Cliff wrote: Test suite told me to send this report in so here we are. environment : custom LFS (GNM) coreutils: 9.4 gcc: (GCC) 13.2.0 > FAIL: tests/rm/ext3-perf > > [...] > > ++ date +%s > + start=1698065263 > + mkdir d > + cd d > + xargs to

bug#64540: [PATCH] od: exit out on failure to write to stdout

On 7/15/23 23:08, Pádraig Brady wrote: The attached patch-set addresses two classes of issue: 1. Doubled error messages upon write errors 2. Continued processing upon write errors (the orig problem reported). Nice work! Patch 1: > --- /dev/null > +++ b/tests/misc/write-errors.sh > @@ -0,0 +1

bug#64326: Some more info about rm bug

tag 64326 notabug close 64326 stop On 6/28/23 19:33, Chris Elvidge wrote: > On 28/06/2023 16:41, Arsen Arsenović via GNU coreutils Bug Reports wrote: >> Hi, >> >> LitHack writes: >> >>> Basically what it doing is that it doesn't recognise (-) this as a file >>> name part even when using (\-). Th

bug#63732: Tailing Difficulities

tag 63732 notabug close 63732 stop On 5/26/23 02:26, Greg Carter via GNU coreutils Bug Reports wrote: Got this when executing `tail -f install/MYSYBASE.log` for an SAP ASE message log (a text file) with a Docker container: ``` tail: unrecognized file system type 0x794c7630 for 'install/MYSYBASE.

bug#61530: sha256sum check single file in a mutiple sha sum text file

tag 61530 notabug close 61530 stop On 2/15/23 14:28, Andreas Löw wrote: Hello, I want to check a single file for correct sha256. All the files of my directory are included in a sha256 text file named allsha256. The sha256sum always checks all files included in the allsha256 fil

bug#61248: uniq --unique needs examples

On 2/3/23 08:12, Dan Jacobson wrote: uniq INFO page says: ‘-u’ ‘--unique’ Discard the last line that would be output for a repeated input group. When used by itself, this option causes ‘uniq’ to print unique lines, and nothing else. This really needs some examples, to help peo

bug#60512: tail: unrecognized file system type 0x794c7630

tag 60512 notabug close 60512 stop On 1/3/23 10:27, 闵续 wrote: tail: unrecognized file system type 0x794c7630 for ‘douyin.search.api.log’. please report this to bug-coreutils@gnu.org. reverting to polling Thanks for the report. That docker image seems to use a quite old coreutils version: 'ove

bug#59461: please help me

tag 59461 notabug close 59461 stop On 11/21/22 10:21, 林兴隆 wrote: OS: Rocky Linux release 9.0 (Blue Onyx) kenel: 5.14.0-70.22.1.el9_0.x86_64 Docker： 20.10.21, build baeda1f Docker-Compose： v2.11.2 I use docker compose to run a container activemq，The contents are as follows，Error encounte

bug#59304: tail: unrecognized file system type 0x794c7630

tag 59304 notabug close 59304 stop On 11/16/22 05:44, Stuart Rothrock wrote: tail -f /var/log/melog | while read a; do echo $(date) $(echo $a | sed -e 's/[{}",]//g' -e 's/[a-z]\+://g'); done 2>&1 | tee -a dock2.log tail -f power-dock2.log tail: unrecognized file system type 0x794c7630 for ‘dock

bug#56631: flock does not unlock instantly

tag 56631 notabug close 56631 stop On 7/18/22 12:50, Alexey Kuznetsov wrote: > Simple bash script: > > #!/bin/bashset -eexec 7<"$0"flock -n 7sleep 60 > > Will prevent a second instance from being executed (exits instantly). But > if the first instance got killed by 'killall test.sh', the second

bug#55837: Options `-p` and `--tmpdir` behave differently

tag 55837 notabug close 55837 stop On 6/8/22 02:28, Klaatu wrote: According to the man page, `--tmpfile` is the long option for `-p` However, I get different results when using one or the other. The `-p` option results in success: $ mktemp -p ~/Demo /home/klaatu/Demo/tmp.6TWPxScyKK $ mktemp -p

bug#53674: Docker error code: 0x794c7630

tag 53674 notabug close 53674 stop On 2/1/22 03:38, Alexandre Louisdhon wrote: > Error- tail: unrecognized file system type 0x794c7630 for > ‘/var/log/syslog’. Thanks for the report. That docker image seems to use a quite old coreutils version: overlayfs - commonly used with Docker containers -

bug#53212: feature request: mount option to specify the device number

tag 53212 notabug close 53212 stop On 1/12/22 17:59, Joachim Wagner wrote: > Not sure whether this is coreutils or kernel. Maybe both. > > A filesystem's device number such as reported by `stat` can be derived from > major and minor of the underlying block device, e.g. xfs, or be allocated at >

bug#53209: stat shows wrong, non-existing device number

On 1/12/22 16:35, Joachim Wagner wrote: > I cloned git://git.sv.gnu.org/coreutils to add a sentence on this to stat's > man page but coreutils/man/stat.x is only a template, missing what I see in > `man stat` on my system. Trying to find out how to contribute to > documentation, I encountered th

bug#53145: 回覆: bug#53145: Acknowledgement ("cut" can't segment Chinese characters correctly?)

On 1/12/22 12:19, zendas via GNU coreutils Bug Reports wrote: > I have considered dealing with this problem directly with three bytes > instead, but I have two doubts, I can correctly use wc -m to recognize the > bytes in the same environment (but cut can't?), and my script goal is to > recogniz

bug#52122: mv: deletes src file on error

On 11/26/21 13:23, Frank Busse wrote: > I tried it several times with checking the timestamps/md5sums of the > files but after remounting the stick it doesn't happen anymore?! I > guess it was a hiccup somewhere else in the system, sorry. Perhaps the USB stick was removed from the system before th

bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

On 11/26/21 00:10, Warren Parad wrote: > On Fri, Nov 26, 2021 at 12:02 AM Bernhard Voelker <mailto:m...@bernhard-voelker.de>> wrote: >> The synopsis is already complex and confusing enough: > > Opinion, it is as complex as it allows, sounds like you are saying "

bug#52115: Suggestion: LN command should swap TARGET and LINK_NAME if LINK_NAME already exists

On 11/25/21 18:53, Warren Parad wrote: > It is too frequent a problem to know which is the correct order of TARGET > and LINK_NAME. I disagree: it is a one-time effort to learn the order ... similar as for mv(1) and cp(1). > Since the command already believes that it can't create a link to a file

bug#52033: a bug in paste command

tag 52033 notabug close 52033 stop On 11/22/21 14:39, Visser, Gerard wrote: > Please close the case. Hereby done.

bug#51311: [PATCH] echo: update --help to document edge cases

On 10/22/21 16:21, Pádraig Brady wrote: > Thanks for all the input. > I've now pushed the following to address this: > > https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=f60a3981c > > Notes: > - Brevity in --help and man pages is a feature > - I kept the existing NOTE: style in -

bug#51311: [PATCH] echo: update --help to document edge cases

On 10/21/21 15:14, Florent Flament wrote: > Pádraig Brady writes: >> +NOTE: printf(1) is a preferred alternative, with more standard option >> handling.\ > I believe that it misses the point. It is still not clear that the echo > command doesn't behave as one would expect for a few edge cases. >

bug#51011: [PATCH] sort: --debug: add warnings about radix and grouping chars

On 10/10/21 19:57, Pádraig Brady wrote: >sort: numbers use ‘.’ as a decimal point in this locale What about adding the hint to that message that this an "ambiguity warning"? sort: ambiguity warning: numbers use ‘.’ as a decimal point in this locale (Likewise for the other cases, of cours

bug#50784: coreutils 9.0 sometimes gets spurious failures in chmod -R

On 9/24/21 22:02, Pádraig Brady wrote: Tested equivalent patch is attached. Nice small patch. Maybe it's worth documenting in the enum where the "bad range" starts against which the code later tests? Furthermore, I think it's worth adding a NEWS entry and mentioning that this bug has been int

bug#50167: fixes for "fmt - -" etc.

On 8/25/21 10:38 AM, Jim Meyering wrote: > * cfg.mk (exclude_file_name_regexp--sc_system_h_headers): > Add find-mount-point.h to the regexp. +1 even better, thanks. Have a nice day, Berny

bug#50167: fixes for "fmt - -" etc.

e a particular reason to include stdlib.h? Have a nice day, Berny >From fd277435c8cc4b758c101b9466fd8e86f4f37807 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Tue, 24 Aug 2021 21:32:26 +0200 Subject: [PATCH] maint: avoid sc_system_h_headers error `make syntax-check` complains: src/fin

bug#50169: Linux cp missing destination file

On 8/22/21 8:26 PM, Diana ladydi_r wrote: > Linux cp bug is happening when I am in wadam@localhost ~]$ That just shows a command prompt, and nothing related to cp(1) or coreutils at all. > What can I do? You failed to provide the information for any of the typical questions like: - what do you

bug#49716: no -print0 for ls?

On 7/26/21 5:00 PM, Pádraig Brady wrote: > The patch set looks good thanks. Wait - I see another reason why we didn't add it earlier: The --null option is not compatible with about half of the other options of ls(1); at least the actual output is more than questionable, and not usable in progra

bug#48330: The xargs -r, --no-run-if-empty Option Is Ignored When a Delimiter Is Passed

tag 48330 notabug close 48330 stop On 5/10/21 8:07 AM, Kurt von Laven wrote: > [[ $input = *[![:space:]]* ]] && xargs --null -I str echo str <<< "$input" You have reached the GNU coreutils mailing list, and 'xargs' is not part of the coreutils [1]. [1] https://www.gnu.org/software/coreutils/ In

bug#48070: sort.exe cannot do ascii ordering but help says it can.

On 4/27/21 7:39 PM, Peter SMITH1 (contractor) via GNU coreutils Bug Reports wrote: > CONFIDENTIAL & RESTRICTED This cannot be enforced on a public mailing list, for obvious reasons. > Hello, > > C:\gener\gnuutils>\bin\sort --version > sort (GNU coreutils) 5.3.0 > Written by Mike Haertel and Pau

bug#47859: Additional seq outlandish example: seq 0 dangers

On 4/18/21 3:26 AM, 積丹尼 Dan Jacobson wrote: > Here's another 'fun/sad/DDOS yourself' example you might add: > > One day I wrote a Makefile, > m: > seq 0 9|sed s/$$/號.html/|xargs make > but before using it, I though I'll just test with one item, > m: > seq 0 |sed s/$$/號.html/|xargs mak

bug#47777: Feature request

On 4/14/21 9:43 PM, Stuart Blake Tener wrote: > Pádraig, > > [...] your response [...] was a bit offensive. I don't feel Padraig's reply was offensive at all. Instead, he just asked for further clarification about the requested feature. Adding a clear example maybe would have helped. > --incl

bug#47324: AW: bug#47324: Missing information in documentation

On 3/23/21 11:18 AM, Walter Harms via GNU coreutils Bug Reports wrote: > In my case there was no security context involved. > It was a loop device mounted (that i was not aware of, > the image was already gone). > and rm -r stoped here because of "in use". > > I expected some mentioning of mount s

bug#47348: Possible bug coreutils : no cat command

On 3/23/21 12:22 PM, Luís via GNU coreutils Bug Reports wrote: > I found that the cat command, supported by the Coreutils package > (8.30-ubuntu2) is no longer working. That's quite a vague description, so no one will probably be able to help you based on that. What exactly happens when you run

bug#47324: Missing information in documentation

On 3/22/21 5:37 PM, Walter Harms via GNU coreutils Bug Reports wrote: > hi list, > in the documentation (man page) [...] According to the GNU guidelines and to avoid double work, the man page of the coreutils is essentially not much more than the output of --help (and actually gets generated via t

bug#47322: unrecognized file system type 0x794c7630

tag 47322 notabug close 47322 stop On 3/22/21 5:16 PM, Felipe Lima wrote: > I was trying do tail a file in a docker container when I received that > message: > > ``` > tail: unrecognized file system type 0x794c7630 for > ‘zookeeper-gc.log.0.current’. please report this to bug-coreutils@gnu.org. >

bug#45832: CYBER HACK URGENT BUG REPORT

tag 45832 notabug close 45832 stop On 1/12/21 10:33 PM, hayley novelli wrote: > https://www.gnu.org/software/coreutils/coreutils > > > > https://dl.bintray.com/grimler/science-packages-24 science/stable aarch64 > Packages [8936 > > > bintray

bug#45726: backup-to-s3 bug

tag 45726 notabug close 45726 stop On 1/8/21 5:41 AM, Admin Golky via GNU coreutils Bug Reports wrote: > unrecognized file system type 0x794c7630 for '/var/log/cron.fifo'. please > report this to bug-coreutils@gnu.org. reverting to polling overlayfs - commonly used with Docker containers - has

bug#45648: `dd` seek/skip which way is up?

On 1/5/21 3:06 AM, Paul Eggert wrote: > On 1/4/21 3:07 PM, Bernhard Voelker wrote: >> What 'dd' implementation was this specifically? > > Solaris dd has iseek and oseek. However, they are not aliases for skip > and seek. If coreutils dd were to add these features I

bug#45648: `dd` seek/skip which way is up?

On 1/4/21 4:03 AM, Bela Lubkin wrote: > I constantly confuse 'seek=N' and 'skip=N'. The two words have no natural > affinity to one I/O direction or the other. While the words 'seek' and 'skip' may not be strong enough for everyone to be clear about whether they apply on input or output - e.g. fo

bug#45258: mkdir man page unclear in describing -m flag

On 12/16/20 2:34 PM, Pádraig Brady wrote: > Insightful comments. I've updated the gotchas note with them: > https://www.pixelbeat.org/docs/coreutils-gotchas.html#mkdir Nice, and also better wording than mine, thanks! Have a nice day, Berny

bug#45258: mkdir man page unclear in describing -m flag

On 12/15/20 9:00 PM, Paul Eggert wrote: > Thanks for your bug report. I installed the attached patch; although it > doesn't use the exact wording you proposed, I hope it works well enough. Thanks for clarifying. > +If the @option{-m} option is also given, it does not affect > +file permission bit

bug#45001: Ls bug

tag 45001 notabug close 45001 stop On 12/2/20 5:37 AM, Paul Morton wrote: > Hello, I am using the command prompt linux to -1 a Ls > > What can I do to acquire help from you. A good bug report answers the following questions: - What do you want to achieve? - How do you attempt to achieve it? Repr

bug#44959: date error message should say -I

Hi Padraig, On 11/30/20 10:31 PM, Pádraig Brady wrote: > For my reference, if we were to give explicit diagnosis of the leading '='. > we would need to update xstrtol_fatal, XARGMATCH, operand2sig, set_fields, ... I'd also rather keep it like it is, but if we change something: we could advance pa

bug#44959: date error message should say -I

On 11/30/20 2:13 PM, 積丹尼 Dan Jacobson wrote: > $ date -I=seconds > date: invalid argument ‘=seconds’ for ‘--iso-8601’ Hmm, first of all, 'date' 8.32 outputs more than the above: $ date -I=seconds date: invalid argument '=seconds' for '--iso-8601' Valid arguments are: - 'hours' - 'mi

bug#44763: Error when 'make'ing latest version of coreutils

[adding Paul] On 11/21/20 8:54 PM, Chris Elvidge wrote: >CC test-nl_langinfo-mt.o > test-nl_langinfo-mt.c: In function 'threadN_func': > test-nl_langinfo-mt.c:185:1: error: no return statement in function > returning non-void [-Werror=return-type] > } > ^ > cc1: all warnings being t

bug#44763: Error when 'make'ing latest version of coreutils

On 11/20/20 5:38 PM, Chris Elvidge wrote: > Reran the whole thing from git clone etc. > ( > git clone git://git.sv.gnu.org/coreutils > cd coreutils > ./bootstrap > git submodule foreach git pull origin master > git config --global user.email "celvidge...@gmail.com" > git config --global user.name "

bug#44704: uniq: replace repeated lines with a message about how many repeated lines

On 11/18/20 12:25 PM, Chris Elvidge wrote: > You could write your own function to do it. E.g. > > unique() { > [ "$1" ] || { echo "Needs a readable file to test" && return 1; } > [ -r "$1" ] || { echo "Needs a readable file to test" && return 1; } > R=""; N=0 > while IFS=$'\n' read L; do > [ "$L"

bug#44635: bugs in watch

tag 44635 notabug close 44635 stop On 11/14/20 2:07 PM, John Lawrence Aspden wrote: > Hi Guys, > > I noticed a couple of things that look like bugs in 'watch' [...] You have reached the GNU coreutils mailing list, and 'watch' is not part of the coreutils [1]. [1] https://www.gnu.org/software/co

bug#44587: ls prints garbage when listing contents of a directory without exec permissions

On 11/12/20 12:24 AM, Jan Schaumann wrote: > When running 'ls -l' on a directory that the user does > not have execute permissions on, ls(1) still attempts > to generate the long listing and prints the various > fields with garbage: > > $ mkdir dir > $ touch dir/file > $ chmod a-x dir > $ ls -ld d

bug#44412: RFE for 'env'?

tag 44412 notabug close 44412 stop On 11/3/20 6:29 PM, L A Walsh wrote: > > > On 2020/11/03 04:29, Bernhard Voelker wrote: >> >> As you didn't give an example, it's hard for me to imagine what you >> want to achieve, or better why current 'env' w

bug#44412: RFE for 'env'?

On 11/3/20 10:14 AM, L A Walsh wrote: > I wanted to pass a switch to an interp line, but 'env' seems to dislike it. > > I also noticed that env ignores '--' to indicate end of switches that it > should > process. > > How difficult would this be to do? Specifically, > allow double-dash ("--") to

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

On 10/27/20 3:15 PM, Pádraig Brady wrote: 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 just

bug#43235: Xeoma Docker Container Bug reporting to GNU.org

tag 43235 notabug close 43235 stop On 2020-09-06 16:37, Philip Rowlands wrote: > On Sun, 6 Sep 2020, at 06:08, Scott Carter wrote: > >> *tail: unrecognized file system type 0x794c7630 for ‘/var/log/syslog’. >> please report this to bug-coreutils@gnu.org . > > Recent versions of tail now take thi

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

On 2020-08-03 22:07, Bernhard Voelker wrote: > Pushing soon ... unless there are objections. Pushed some days ago, and therefore I'm hereby marking this issue as done. Have a nice day, Berny

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

On 2020-07-31 21:42, Pádraig Brady wrote: > Patch looks good thanks. Thanks. > An alternative could be to use rmdir itself to test, like: > >if ! rmdir x/y 2>/dev/null; then > returns_ 1 rmdir --ignore-fail-on-non-empty x/y || fail=1 >fi I thought about that, but as there's a secon

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

489e1d9 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Fri, 31 Jul 2020 19:49:35 +0200 Subject: [PATCH] tests: skip some parts of 'tests/rmdir/ignore.sh' if run as root Parts of this test expect that the rmdir syscall returns with EPERM, but the root user does not see that. * tests

bug#41634: 'timeout' returning 124 and 133

On 2020-07-28 23:53, Pádraig Brady wrote: > +1 thanks Thanks, pushed.

bug#41634: 'timeout' returning 124 and 133

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, ..." >

bug#42470: Help text update suggestion for "date" util

[sorry, this one hung in my outbox ... not sure if this helps though] On 2020-07-25 17:07, Wes Novack wrote: > For future reference, what is the PR process? Not exactly sure what you mean with "PR". If you refer to the process of reporting bugs, making suggestions, sending patches, etc., then ple

bug#42470: Help text update suggestion for "date" util

On 2020-07-21 19:45, Wes Novack wrote: > Greetings! For the GNU coreutils "date" utility, I would like to suggest > updating the help text > > from %s seconds since 1970-01-01 00:00:00 UTC > to %s seconds since the epoch, 1970-01-01 00:00:00 UTC > > This was suggested in this StackOverflow post a

bug#41634: 'timeout' returning 124 and 133

On 2020-07-05 12:53, Jonny Grant wrote: > Your patch looks great. Thanks, pushed (with the minor tweak mentioned below) at: https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=49bd08aea > Is it worth clarifying that --kill-after=0s would send the KILL signal > immediately after TERM? > $ time

bug#41634: 'timeout' returning 124 and 133

ng this long after the initial signal was sent What about the attached? Thanks & have a nice day, Berny >From 56e4aa9d0c083b9e49747d51866e80acec1142a2 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Sun, 5 Jul 2020 01:20:10 +0200 Subject: [PATCH] doc: clarify

bug#41634: 'timeout' returning 124 and 133

On 2020-06-15 22:57, Bernhard Voelker wrote: > The attached is an attempt to add some useful examples. There were no comments, so I pushed with a few tweaks: https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=b1c6ef230c Marking this as done. Have a nice day, Berny

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

marking this as done.

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

On 2020-06-20 19:28, Pádraig Brady wrote: > +1 Thanks for the review, pushed at: https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=f5644c986ce Have a nice day, Berny

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

27;vboxsf', and I think that this cannot really reliably work, e.g. if a Windows host exposes a directory on a CIFS share into a Linux guest VM (which works, I tried). Therefore, I've marked 'vboxsf' as a 'remote' file system which uses polling. Have a nice day, B

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

On 2020-06-16 00:11, Pádraig Brady wrote: > I've updated your patch (attached) to add tests for this. nice, thanks. Have a nice day, Berny

bug#41634: 'timeout' returning 124 and 133

-t 6s -k 11s ls" > > or even > "$ timeout --timeout=6s --kill-after=11s ls" While that would be possible, I'm not so excited about it. The timeout value is a mandatory value similar to the perms for chmod(1), and I've not seen any requests to support "chmod --mo

bug#41792: dd function – message: "No boot sector on USB device""

tag 41792 notabug close 41792 stop response below... On 2020-06-10 17:49, Ricky Tigg wrote: > *Component*: coreutils.x86_64 8.32-4.fc32.; *OS*: Linux Fedora > > Source of file: > https://www.microsoft.com/en-us/software-download/windows10ISO > > Disc image file > - checked against its SHA-256

bug#41634: 'timeout' returning 124 and 133

On 2020-06-07 15:34, Pádraig Brady wrote: > [...] it is better to add the comma there [...] thanks, pushed with that change: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=189776ff3b Marking this as done. Have a nice day, Berny

bug#41634: 'timeout' returning 124 and 133

Hi Padraig, On 2020-06-07 14:13, Pádraig Brady wrote: > How about we add the exit code table to the man page also? > I've adjusted your patch to do that (along with some other tweaks) in the > attached. nice, especially also: > -124 if @var{command} times out > +124 if @var{command} times out,

bug#41634: 'timeout' returning 124 and 133

On 2020-06-06 23:49, Jonny Grant wrote: > Great patch. thanks, Padraig meanwhile further improved it. > How about writing signal 9 by the name, ie $ kill -s KILL > likewise $ kill -s TERM Where do you mean? Have a nice day, Berny

bug#41634: 'timeout' returning 124 and 133

thanks for the suggestion. I think this could still be improved: there is still the open question what happens when the KILL signal is sent either to timeout(1) or to COMMAND. The attached patch tries to clarify. Have a nice day, Berny >From d4ee1f8ace585124e80a3d6e11c6902e37e9e71f Mon Sep 17

bug#37702: Suggestion for 'df' utility

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 another alternative to control the behavior bes

bug#41106: date --date '20180325 02:58:00' fails

tag 41106 notabug thanks On 2020-05-06 10:04, Julien Demaria wrote: >> $ date --date '20180325 02:58:00' >> date: invalid date `20180325 02:58:00' > Sorry I just found the reason in the FAQ... :-( > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-righ

bug#40551: tail: unrecognized file system type 0x794c7630 for /path/to/nginx/error.log'

tag 40551 notabug close 40551 stop Hello, On 2020-04-11 10:20, 王群强 wrote: > hi , > I am using " tail -f error.log " command in k8s pod environment, thus i > got a fatal error bellow : > > error message === > tail: unrecognized file system type 0x794c7630 for 'error.log'. please > report th

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

On 2020-04-01 14:10, Pádraig Brady wrote: > 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. LG

bug#39951: tail -n +NUM is not working properly

On 3/6/20 10:42 AM, Dimitris Moraitidis wrote: Hey there, tail -n + NUM does not return the desired output. +NUM starts from the top of the file, not from the bottom. So for example, given the following file: this is an example file each word represents a line and executing tail -n +3 examp

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

On 2020-03-06 08:31, Bernhard Voelker wrote: > On 2020-03-06 02:27, Paul Eggert wrote: >> On 3/5/20 1:43 PM, Paul Eggert wrote: >> >>> Why is this code even there at all? If readdir(3) says that the current >>> directory has no entries, shouldn't 'ls&

  1   2   3   4   5   6   7   >