bug#55212: GNU Linux "sort -g" can hang indefinitely when run on standard input if NaNs are involved

On 2022/05/01 10:16, Giulio Genovese wrote: As explained here , when running "sort -g" from standard input, if NaNs are involved, this can cause "sort -g" to hang indefinit

bug#15612: README-prereq patch

Hi folks, There's a `cd' missing in the README-prereq in git. I am off-list. cheers, Ben README-prereq-patch-20131014.diff Description: Binary data

tail fails in xnanosleep - correction (linux 2.4.22 kernel)

tail (coreutils) 5.0.91 invoked with: $ tail -f -n300 /var/spool/cid/log occasional error message: --- tail: xnanosleep.c:104: xnanosleep: Assertion `0 <= seconds' failed. Aborted --- The file /var/spool/cid/log is only appended to by another program - never truncated or anything

tail fails in xnanosleep

tail (coreutils) 5.0.91 invoked with: $ tail -f -n300 /var/spool/cid/log occasional error message: --- tail: xnanosleep.c:104: xnanosleep: Assertion `0 <= seconds' failed. Aborted --- The file /var/spool/cid/log is only appended to by another program - never truncated or anything

bug#29475: filesystem does not allow ln to create bad symbolic link

Hi Paul: On Mon 11/27/17 14:37 -0800 Paul Eggert wrote: > On 11/27/2017 10:17 AM, bug-coreut...@trodman.com wrote: > > $ ln -s not-there badlink > > ln: failed to create symbolic link ‘badlink’: No such file or directory > > What happens if you do the following shell command instead? > > strace

bug#29475: filesystem (apparently cagefs) does not allow ln to create bad symbolic link

On Mon 11/27/17 18:41 -0800 Paul Eggert wrote: > bug-coreut...@trodman.com wrote: > > stat("badlink", 0x7ffc0eb805a0) = -1 ENOENT (No such file or > > directory) > > symlink("not-there", "badlink") = -1 ENOENT (No such file or > > directory) > > My guess is that you've removed th

bug#30102: date -d 'next tuesday, 2 years ago' # Is something like that supported?

$ date --version date (GNU coreutils) 8.27 --snip $ info date -n 'Date input formats' |grep 'next tue' * Relative items in date strings:: next tuesday, 2 years ago. My goal is to find for example the date of the first Saturday after 1/7/2018 with a single date command. -- thanks!

bug#30102: date -d 'next tuesday, 2 years ago' # Is something like that supported?

Hi Assaf: On Sun 1/14/18 3:50 -0700 Assaf Gordon wrote: > On 2018-01-13 05:03 PM, bug-coreut...@trodman.com wrote: > In version 8.27 the date command has an additional option called > "--debug" which can help in understanding the date parsing. Thanks/good to know. > I will use it in the output

bug#40958: date command give current time zone regardless of seconds since epoch requested.

I am going to hazard a guess and say this is the expected behaviour, but I cannot find anything though goog. The date command has a number of switches, one of which is -d where you give it the number of seconds since epoch, as in "date -d@1234" or "date --date @1234". Additionally, you can get

bug#47348: Possible bug coreutils : no cat command

    In a reinstallation of Linux Mint 20 ( based on the ubuntu 20 focal fossa ), I found that the cat command, supported by the Coreutils package (8.30-ubuntu2) is no longer working. I tried to reinstall ( just reinstall, because purge breaks the system, so I couldn't test removing pos

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

I receive the following error when using make with coreutils in a alpine based docker container: > #10 304.0 CC lib/mkdir-p.o > #10 304.1 CC lib/modechange.o > #10 304.1 CC lib/mpsort.o > #10 304.2 CC lib/nproc.o > #10 304.2 CC lib/nstrftime.o > #10 304.3 CC lib/openat-die.o

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

t apply cleanly #10 177.2 gnulib/gnulib-tool: *** Stop. #10 177.2 ./bootstrap: gnulib-tool failed #10 ERROR: executor failed running [/bin/sh -c git clone --branch v8.32 --single-branch https://git.savannah.gnu.org/git/coreutils.git && cd coreutils && git clone https:/

bug#50085: fatal error: parse-datetime.tab.h: No such file or directory

Thanks for your patience and clarification. I was able to get it working properly with the latest master: RUN git clone --branch master --single-branch https://git.savannah.gnu.org/git/coreutils.git \ && cd coreutils \ && export FORCE_UNSAFE_CONFIGURE=1 \

bug#53052: Unusual df output

Dear coreutils devs, I'm the dev of the 'boot-repair' and 'boot-info' utilities. A Linux Mint 20.2 user reported the following system information:https://paste.ubuntu.com/p/kcXPDC79RF/ (pastebin will expire so I attach a copy) Interesting extract for you, is that

bug#53145: "cut" can't segment Chinese characters correctly?

/debian_version 11.1 zendas@Backup-Server:~$ cut --version cut (GNU coreutils) 8.32 Copyright (C) 2020 Free Software Foundation, Inc. 授權條款 GPLv3+：GNU 通用公共授權條款第 3 版或更新版本 <https://gnu.org/licenses/gpl.html>。 本軟體是自由軟體：您可以自由修改和重新發布它。 在法律範圍內沒有其他保證。 由 David M. Ihnat、David MacKenzie 和 Jim Meyer

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

： > Reference source: > > https://blog.csdn.net/m0_38110132/article/details/79883827 > > my environment is: > > zendas@Backup-Server:~$ cat /etc/debian_version > > 11.1 > > zendas@Backup-Server:~$ cut --version > > cut (GNU coreutils) 8.32 > > Copyrigh

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

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 recognize Chinese, will The probability of execution is higher on platforms th

bug#46808: Man page of "tail"

> Am 24.02.2022 um 00:02 schrieb Andreas Schwab : > > On Feb 27 2021, Reuti wrote: > >> I'm not a `groff` expert, but the sequence "\,some-text\/" appears a couple >> of times. What effect does it have for the formatting as the "," and "/" are >> not output? > > \, and \/ add some space as i

bug#54519: YES

Hello !   I try to use GNU «yes» on Suse Linux...but it not WORK, as I think…   I use such variants:   yes | zypper up;   yes y | zypper up;   yes 'y' | zypper up;   ALL variants DID not work …   Why such problems with yes ?   Best regards Dmitry Telegram: https://t.me/bdmalex    

bug#55183: date

%r has a space at the end that makes me insanely angry fix it

bug#55304: build: INSTALL file is missing from .tar.gz snapshots

In the following snapshot: http://git.savannah.gnu.org/cgit/coreutils.git/snapshot/coreutils-9.1.tar.gz ... the file README says the following a few paragraphs from the top: > If this file came to you as part of a tar archive, then see the file INSTALL > for compilation and instal

bug#62403: checksums --check (sha256sum, sha1sum) return file: OK when they shouldn't

hat: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b319685c6e12e66bf357c2384fe69f1c63f66aed % sha256sum --version sha256sum (GNU coreutils) 9.2 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you

bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with NFS

is the only platform on which I have observed this behavior. I also checked on all other platforms, including x86, arm, ppc, riscv, mips, sparc, hppa, and ia64. No other platform exhibited this error. I am using kernel 6.3, glibc 2.37, and coreutils 9.3. If anybody would mind taking a look

bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with NFS

ig suggests, the output of the following shell command would be useful: strace stat -f -c '%T' . Also please see <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1899582>. Although it's about s390x I expect there are similar issues on alpha, which may not be fix

bug#69369: wc -w ignores breaking space over UCHAR_MAX

Hi, wc -w doesn't seem to recognize whitespace characters with a codepoint over UCHAR_MAX (255) as word separators. For example, using the character EM SPACE U+2003: $ printf "foo\u2003bar" | ./wc -w 1 I should get a word count of 2, but instead the space is ignored while counting words. Meanwhi

bug#71309: du --total output does not take in account the --threshold

--total 10-Megs 20-Megs 10240   10-Megs 20480   20-Megs 30720   total But the actual output is: $du --threshold -50M --total * 10240   10-Megs 20480   20-Megs 174088  total and so the total includes all the files scanned, and not just the files displayed. I see this in coreutils 8.32, but the

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

Hello, While running the test for Coreutils during my LFS build (Chapter 8.57 Coreutils-9.4: https://www.linuxfromscratch.org/lfs/view/12.1/chapter08/coreutils.html), I encountered a potential bug and the test recommended I report it. LFS 12.1 Build, on Pop_OS! Host System Coreutils Verson

bug#75682: ls -l sometimes shows a year in place of the hour and minute

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Coreutils maintainers, I believe I've found a bug in the coreutils' ls command. I was watching a file with watch and ls -l while it was being updated, but sometimes I saw that the time would display a year instead of an hour a

bug#75682: ls -l sometimes shows a year in place of the hour and minute

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > df -T . I was running it under /dev/shm to use a tmpfs. > - What's your libc version? 2.36 > uname -sr "Linux 6.1.0-29-amd64" > ls --version "ls (GNU coreutils) 9.1" I'm definitely not using a

bug#78857: shred bug

Hi! I've started shredding a drive /dev/sdc on the latest stable linux mint (debian), then I've connected another drive for work, and the shredding command was cancelled with an error "Error writing at offset [offset]: No such device". Apparently, Mint has automounted and assigned the name /dev/

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

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 This results in an endless 'execve' recursion (if that's the w

bug#41001: mkdir: cannot create directory ‘test’: File exists

anged? Maybe I can make a patch for it. Jonny $ mkdir test $ mkdir test mkdir: cannot create directory ‘test’: File exists $ mkdir --version mkdir (GNU coreutils) 8.28 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&

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

That's showing up your bright stupidity but you future is still bright! keep working on that~! lol... just joke added~ :) 2020년 5월 6일 수요일 오후 05시 47분 51초 GMT+9, Julien Demaria 작성: Sorry I just found the reason in the FAQ... :-( https://www.gnu.org/software/coreutils/faq/core

bug#42336: RTL LANG

hi can you add support of RTL Lang to fold?for that it need to split line from right to left -best regard saeid

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

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 v8.32-52-gc0e5f8c59. Suppose I have the following YAML file: ==> test.yaml <==

bug#42795: stty settings

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 described on https://stackoverflow.com/questions/7812142/how-to-toggle-cr-lf-in-gnu-screen in my case problems with vi(elv

bug#42804: mkdir saying it can't create folder although it created it

When I use mkdir, when it succeeds sometimes it has no message, which is acceptable, but sometimes it says this: mkdir: cannot create directory '': File exists But the directory didn't exist before I used mkdir to make it, and I show hidden files, thus also hidden directories. I suggest the mess

bug#42804: mkdir saying it can't create folder although it created it

I don't know why my bug report appeared twice with the same bug number, but the version answered by Paul Eggert was incomplete, so I'm not surprised that he didn't understand. To answer: The point about hidden files is that I knew the directory did not exist before I executed mkdir because I can

bug#42804: mkdir saying it can't create folder although it created it

I couldn't reproduce the problem anymore, in either Terminal or Konsole (both are CLI terminal emulators), so either it's gone or it's intermittent. We can treat this bug as closed unless and until I make a new version of this report. I don't know of a difference in circumstances unless it's tha

bug#43415: coreutils 8.32: install: fchmod fails with EBADF

Hello, I am experiencing some curious behavior when trying to set the file mode using the install command. Version info: install (GNU coreutils) 8.32 Summary of behavior: fchmod to 1777 fails with EBADF The log from strace shows the following:     ...     geteuid

bug#45700: rm should not prompt if ! isatty(2)

$ /bin/rm --version rm (GNU coreutils) 8.30 $ uname -a Linux xxx 5.4.0-59-generic #65-Ubuntu SMP Thu Dec 10 12:01:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID:    Linuxmint Description:    Linux Mint 20 Release:    20 Codename

bug#45700: rm should not prompt if ! isatty(2)

/21 10:56 AM, John Wiersba via GNU coreutils Bug Reports wrote: > $ touch asdf && chmod a-w asdf && rm asdf 2>&1 | catrm: remove > write-protected regular empty file 'asdf'?  # should*not*  prompt > > If the prompt cannot be seen, then it can&#x

bug#45726: backup-to-s3 bug

    unrecognized file system type 0x794c7630 for '/var/log/cron.fifo'. please report this to bug-coreutils@gnu.org. reverting to polling

bug#45890: Printf bug GNU coreutils 8.30/8.32

Hello, I'm using GNU coreutils 8.30, I found that the printf tool is broken while coding a shell script. andrea@Workstation:~$ printf --version bash: printf: --: invalid option printf: usage: printf [-v var] format [arguments] I tried with coreutils 8.32 too with the same error. PRINTF(1

bug#45890: Printf bug GNU coreutils 8.30/8.32

I'm sorry, I found the answer in the FAQ. So i'ts resolved. Thanks ‐‐‐ Original Message ‐‐‐ On Friday, January 15, 2021 12:08 PM, Andrea Dari wrote: > Hello, > > I'm using GNU coreutils 8.30, I found that the printf tool is broken while > coding a shell scr

bug#46723: Feature request: Add -i option to rmdir

Please add a -i option to rmdir, similar to the -i toption (interactive prompt) for mv and rm.  It would be useful for the same reasons as it is useful for rm and mv.  I know there are workarounds, but all these commands should support -i for consistency. Thanks!-- John Wiersba

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

Dear maintener, I found a reproducible bug in df utility, installed in debian stable $ df --version |head -1 df (GNU coreutils) 8.30 $ cat /etc/debian_version 10.8 df displays G instead of GM as unit size for Gigabytes in power of 1000 (but the value is correct) $ df -BGB /home Sys. de

bug#47324: Missing information in documentation

hi list, in the documentation (man page) a nice feature is mssing when a fs is mounted on a directory ls marks that with a dot behing the permission mask (see example) drwxr-xr-x. 2 1003 users 4096 Mar 22 17:53 vendor ^^ notice the dot here I found nothing mentioned

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

en den/die Absender*in und wissen, dass der Inhalt sicher ist. 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 mu

bug#49044: linux sort issue.

This is my data which needs to be sort 01Sty01, AB 01Sty,Make 01Sty02,CD Now i apply sort to the above file result come as 01Sty01,AB 01Sty02,CD 01Sty,Make I need to see as - This is the way it does in AIX 01Sty,Make 01Sty01,AB 01Sty02,CD Any Suggestion. sanjit - 248 249 0175

bug#49044: linux sort issue.

confirm with csosl. Rick can you take it. sanjit On Tue, Jun 15, 2021 at 3:40 PM Paul Eggert wrote: > To get the effect you want, set LC_ALL="C" in your environment. See: > > > https://www.gnu.org/software/coreutils/manual/html_node/sort-invocation.html#FOOT2 >

bug#50889: Please improve the documentation for install --compare (-C)

Hi, A while back a request was made to improve the documentation of the `install --compare` cmd: https://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00029.html It seems the wording in `coreutils.texi` has been updated since (https://github.com/coreutils/coreutils/commit

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

Hello, Cross-filesystem copying seems to have been broken in the latest coreutils release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ appears to return successfully, but if one analyzes /tmp/test, it’s filled with NULL characters. However, copying works fine when the source

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

> On Nov 15, 2021, at 10:09 AM, Pádraig Brady wrote: > > On 15/11/2021 04:02, Sudhip Nashi via GNU coreutils Bug Reports wrote: >> Hello, >> Cross-filesystem copying seems to have been broken in the latest coreutils >> release on macOS. Running a command like ‘

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On Mon, Nov 15, 2021 at 09:33:21AM -0800, Paul Eggert wrote: > Is the source file on a ZFS file system by any chance? See my lseek comment > below. No, this is one APFS (Apple File System). > > On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote: > > >

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

> On Nov 15, 2021, at 11:33, Paul Eggert wrote: > > Is the source file on a ZFS file system by any chance? See my lseek comment > below. > >> On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote: >> >> stat64("/tmp/test\0", 0

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On Mon, Nov 15, 2021 at 01:33:44PM -0800, Paul Eggert wrote: > On 11/15/21 09:40, Cameron Katri wrote: > > Did you build vanilla coreutils 9.0 yourself? If so, what commands did you > you use to build it, exactly? If not, who built coreutils and how did they > configure and/or mod

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

get fixed to work around this lseek+SEEK_DATA > incompatibility (as FreeBSD, Solaris, etc. all do things the Linux way and > that's what I think will appear in the next POSIX), but in the meantime I > attempted to work around the portability issue by installing the attached > patch into Gnuli

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

It doesn’t seem like this patch works. I compiled from the tarball you provided, but the destination file is still filled with NULL chars. > On Nov 15, 2021, at 5:46 PM, Sudhip Nashi via GNU coreutils Bug Reports > wrote: > > Awesome, thanks for the quick response! I’ll give this

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

Sure, here’s the dtruss output: SYSCALL(args)= return access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2 bsdthread_register(0x1AEC802C8, 0x1AEC802BC, 0x4000) = 1073742303 0 shm_open(0x1AEB48F55, 0x0, 0xDD8000) = 3 0 fstat64(0x3, 0x16F026

bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

> So, not only does macOS lseek disagree with all other implementations, it > even disagrees with the Darwin documentation. Oh wow, that’s convoluted. > To work around this macOS problem I installed the attached further patch into > Gnulib and propagated it into coreutils. Pl

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

Hello, It appears that in coreutils 9.0 and greater, the mv command is broken on non-APFS filesystems on macOS. For example, on Apple tmpfs, it fails whenever moving a file with ENOTSUPP. It works fine on APFS filesystems (which is the primary macOS filesystem), however, so I assume it slipped

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

> I don't observe this problem with the latest development version of > coreutils. Here's how I tried to reproduce the problem on macOS 11.3.1 20E241: > > % touch /tmp/ > % src/mv /tmp/ /tmp/ > > and it worked OK. macOS is different in that

bug#52252: Escape sequences treated as visible characters, long characters split

"fold" includes the character '\e' and each of the following characters that are used to format text as if they were all visible. Example: echo "a\e[3mb\e[0mc" | fold -w1 Result: a *b* c It still formats correctly, it just breaks too early. Special characters can even be broken up. Example:

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

> macOS is different in that /tmp isn’t actually on a tmpfs filesystem, but is > rather just a normal directory on the main data volume that is cleaned on > boot. One has to manually mount a tmpfs volume themselves with mount_tmpfs. > Anyways, I’ll try the tarball linked and see if the issue s

bug#52330: Different processor architecture on Apple M1 CPU

I've identified an issue with GNU Coreutils uname utility. Specifically with the value it returns for the processor type/architecture(-p). When used on a MacOS with M1 arm64 processor the returned value is amr64, but the default uname utility on MacOS returns arm. This issue has caused

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

> Can you give a way to reproduce the probglem on a macOS system, assuming one > has a tmpfs filesystem /A and a non-tmpfs filesystem /B? The scenario wasn't > entirely clear from the bug report. Running the command “mount_tmpfs ~/mntpnt” mounts a tmpfs (and non CoW) filesystem at ~/mntpnt. T

bug#52330: Different processor architecture on Apple M1 CPU

Thanks for that. I tried building it on an M1 host using this Nix derivation adding the patch: { pkgs ? import { } }: pkgs.coreutils.overrideAttrs (old: rec { patches = old.patches ++ [ (pkgs.fetchurl { url = " https://lists.gnu.org/archive/html/bug-coreutils/20

bug#52330: Different processor architecture on Apple M1 CPU

Oh, you're right: [nix-shell:~/coreutils-9.0.37-202be]$ ./src/uname -p arm [nix-shell:~/coreutils-9.0.37-202be]$ ./src/uname -m arm64 Now it works the same as the default uname utility! On Tue, Dec 7, 2021 at 8:16 PM Paul Eggert wrote: > On 12/7/21 04:03, Jakub Sokołowski wrote:

bug#52330: Different processor architecture on Apple M1 CPU

That's amazing. Thank You for the fast response. Paron my eagerness, but when is a new release planned for? I guess not before 2022? On Tue, Dec 7, 2021 at 11:01 PM Paul Eggert wrote: > Thanks for checking. I installed the patch and am closing the bug report. > -- Jakub Grzegorz Sokołowski He

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

> Thanks, but as I don't have access to a macOS machine I don't know what "the > issue" is. What are the symptoms visible to the user? Can you do the > equivalent of an strace to show us what system calls are being executed? > > As near as I can make out, on macOS mv should be doing the equiva

bug#52193: mv broken on non-APFS filesystems on macOS on coreutils >= 9.0

> Thanks, I think I see the problem now. Please try the attached patch; I > haven't tested myself as I lack access to macOS. Thanks. > <0001-renameatu-port-to-macOS-tmpfs.patch> It looks like this patch solves the problem.

bug#53033: date has multiple "first saturday"s?

(This has been verified to occur with 9.0.) $ date -d "first saturday" Sat Jan 8 00:00:00 PST 2022 Unless there is some weird definition of "first Saturday", shouldn't this be the 1st (New Year's Day)? Also, I ran this last week (I think on the 29th or the 30th), and it did prop

bug#53033: date has multiple "first saturday"s?

From coreutils 9.0 (note the difference between the "second" and "third" saturdays): $ src/date --debug -d "first saturday" date: parsed day part: next/first Sat (day ordinal=1 number=6) date: input timezone: system default date: warning: using midnight as starting

bug#53033: date has multiple "first saturday"s?

%b %e %H:%M:%S %Z %Y’ Sat Jan 8 00:00:01 PST 2022 I just noticed that "second Saturday" is being parsed as "Saturday + 1 second". -- Darryl -Original Message----- From: Bug-coreutils On Behalf Of Darryl Okahata via GNU coreutils Bug Reports

bug#53033: date has multiple "first saturday"s?

Bob Proulx wrote: Inconsistencies like this are why I wish it had never been implemented. Best to avoid the syntax completely. Thanks. I'll avoid date and use either python or ruby to get this info. -- Darryl

bug#53033: date has multiple "first saturday"s?

Hmmm, it might be that I'm misunderstanding the syntax. I'm used to specifying dates for repeating calendar events, and, to me, "first Saturday" means the "first Saturday of the month", and not the next Saturday from now. -- Darryl -Original Message- From: Bob Proulx Sent: Monday,

bug#55225: GNU Linux "sort -g" can hang indefinitely when run on standard input (on Ubuntu)

https://unix.stackexchange.com/a/700967/2972 dd if=/dev/urandom count=80 bs=1 | od -An -t f4 -w4 | sponge | sort -g goes into infinite loop. It is caused by 'nan' showing up at a position that apparently is bad. This works (100x bigger than the example above but removes all nan's):

bug#50889: Please improve the documentation for install --compare (-C)

Wonderful, many thanks! Ian.

bug#56520: Security vulnerabilities at coreutils version for CentOS 7.9

Hello, My name is Meirav Rath, I'm a software developer and security champion at Imperva. As part of our effort to map security risks in our products I've been scanning our 3rd party rpms for vulnerabilities. It looks like coreutils available rpm for CentOS 7.9 (8.22) has the vul

bug#56520: Security vulnerabilities at coreutils version for CentOS 7.9

From: Pádraig Brady On Behalf Of Pádraig Brady Sent: Wednesday, July 13, 2022 12:53 AM To: Meirav Rath ; 56...@debbugs.gnu.org Cc: Gadi Friedman ; Ariel Bressler Subject: Re: bug#56520: Security vulnerabilities at coreutils version for CentOS 7.9 CAUTION: This message was sent from outside the company

bug#57631: Coreutils 9.1 build error with glibc 2.23

Thanks for the bug report. Please try this Gnulib patch, which should appear in the next Coreutils release: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b

bug#13028: inplace

c()ing requirements etc. > > Implementation in C in coreutils could also use other APIs where available > like renameat2(..., RENAME_EXCHANGE) and exchangedata() etc. > I noticed XFS_IOC_SWAPEXT but that's currently hardcoded > to support only same sized replacements (for defrag

bug#57785: [PATCH] doc: minor grammar correction

Thanks for the fix; I installed it.

bug#57834: Date Command Anomaly

0:00 GMT 2022 mjh@carnaby:~> date --date="2022/03/27 01:00:00" date: invalid date ‘2022/03/27 01:00:00’ mjh@carnaby:~> date --date="2022/03/27 02:00:00" Sun 27 Mar 02:00:00 BST 2022 The version of date is: mjh@carnaby:~> date --version date (GNU coreutils) 8.29 Copyri

bug#57834: Date Command Anomaly - Forget it. My Oversite

Sorry, my oversite, It was the transition from Greenwich Mean Time to British Summer time 27th March. Martin Hughes

bug#56512: URLs in coreutils manuals documentation should use HTTPS

Thanks, I installed that.

bug#57946: ls indenting broken if executed without color flag after i set tabs to 4

On 9/19/22 20:19, galih surya wrote: Actually, I don't know if this is a bug. It's not something 'ls' can easily fix, because 'ls' can't deduce from the operating system that you have installed nonstandard tab stops. I installed the attached to try to document the issue. Messing with hardwa

bug#57834: Date Command Anomaly

possible reasons: date:non-existing due to daylight-saving time; date:numeric values overflow; date:missing timezone date: invalid date ‘2022/03/27 01:00:00’ Best Bert On Thu, Sep 15, 2022 at 5:21 PM Martin Hughes via GNU coreutils Bug Reports wrote: > > > Dear Sir

bug#58163: coreutils instalation failure x86_64

Failure at make output from configure and make attached uname -a Linux xenial64-sda1 4.9.58 #1 SMP PREEMPT Mon Nov 13 15:54:01 GMT 2017 x86_64  x86_64 x86_64 GNU/Linux followed: \cd  /GS/pool/common-apps  git clone git://git.sv.gnu.org/coreutils  cd coreutils  git submodule foreach git pull

bug#59732: Problem unable to enter command

Hello tty Team, I am using an Arch based distribution. The tty1 screen was opened with the Ctrl+Alt+F1 key combination. When I pressed the Alt+F1 key on this screen, I saw the commands I saw while opening the distribution on the screen. I forcibly shut down the computer so as not to wait any lo

bug#59732: Problem unable to enter command

I think the issue is related to lightdm so it would be better to report the issue to the lightdm developers. Thank you for your answer. Good Jobs tty Team

bug#59732: Problem unable to enter command

e issue to the > lightdm developers. Thanks, I'm closing the coreutils bug report.

bug#59796: How to change GDB binaries installation default path different from /usr/local/bin and libs in /usr/local/lib

Could you please let me know how could I change the GDB binaries installation default path different from /usr/local/bin and libs in /usr/local/lib ? Thanks, Arthur --- mailto: arthur.khachatr...@yahoo.com

bug#59796: Please close the bug 59796

Please close the bug #59796 - How to change GDB binaries installation default path different from /usr/local/bin and libs in /usr/local/lib - GNU bug report logs | | | | #59796 - How to change GDB binaries installation default path different ... | | | I figured out how to fix it.

bug#60215: tail -c +XX on newer coreutils wants FILE

# echo tessdfdsdsfdsfdsfdsfsdft | tail -c +13 sfdsfdsfsdft # tail --version tail (GNU coreutils) 8.32 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to chan

bug#60215: tail -c +XX on newer coreutils wants FILE

On 20.12.2022 13:07, Chris Elvidge wrote: Works OK here. -c [+]13 includes the trailing newline (see hexdump below) Version here is built via ./configure DEFAULT_POSIX2_VERSION=199209 and that changes behaviour. Dropping it makes things work as expected. Thanks. -- Arkadiusz Miśkiewicz, a

bug#60667: Split pathchk's -p into multiple flags?

Hi, I'd like to enforce the POSIX portable file name character set in my projects, which `pathchk -p` does, but I don't want to enforce the POSIX maximum path component length of 14 characters, which it also does. Would it be useful to introduce separate flags for the three rules enforced by `-p`?

bug#60667: Close message

Hi tl;dr Please close this. I sent a copy to coreut...@gnu.org after realising that was more appropriate, and I didn't think my bug-coreutils email would be registered since I wasn't a member. Sorry for the noise. Kind regards Victor Engmark

bug#62607: cp --recursive --backup broken in 9.2

Hi After upgrading to coreutils 9.2-2 on Arch Linux the following: mkdir -p src dst touch {src,dst}/bar cp --recursive --backup src/* dst fails with: cp: cannot create regular file 'dst/foo/bar': File exists Running strace on cp I noticed: renameat2(4, "foo/bar", 4, "

  1   2   3   >