Bug#1082886: cp --sparse defeated by ficlone

On 27/09/2024 18:18, Matthew Wilcox wrote: Package: coreutils Version: 9.4-3.1 strace cp --sparse=always dd dd-sparse [extraneous stuff skipped] openat(AT_FDCWD, "dd", O_RDONLY)= 3 fstat(3, {st_mode=S_IFREG|0755, st_size=134248, ...}) = 0 openat(AT_FDCWD, "dd-sparse", O_WRONLY|O_CREAT|O_

Bug#1076047: coreutils: timeout: doesn't properly intercept all deadly signals

On 09/07/2024 22:21, наб wrote: Package: coreutils Version: 9.1-1 Version: 9.4-3 Severity: normal Dear Maintainer, POSIX.1-2024, XCU, timeout, ASYNCHRONOUS EVENTS: 117587 If the signal specified with the −s option, or any signal whose default action is to terminate 117588 the process, is del

Bug#1075768: coreutils: ls doesn't honour COLUMNS if writing to a teletype

On 04/07/2024 17:29, наб wrote: Package: coreutils Version: 9.1-1 Version: 9.4-3 Severity: normal Dear Maintainer, Quoth POSIX.1-2024: 103406 ENVIRONMENT VARIABLES 103407 The following environment variables shall affect the execution of ls: 103408 COLUMNS Override the system-selected horizo

Bug#1074776: coreutils: $'\t' and $'\123' escapes are real now

On 02/07/2024 21:48, наб wrote: Package: coreutils Version: 9.1-1 Version: 9.4-3 Severity: minor Dear Maintainer, printf(1) says: escaping non-printable characters with the proposed POSIX $'' syntax. this syntax is real as of Issue 8 (POSIX.1-2024). ls is probably also affected by this sinc

Bug#1074334: coreutils: what is the undocumented ls --quoting-style=c-maybe mode?

On 28/06/2024 20:48, наб wrote: On Wed, Jun 26, 2024 at 11:22:07PM +0100, Pádraig Brady wrote: Fixed upstream with: https://github.com/coreutils/coreutils/commit/72588b291 This is wrong. Try: $ > 'a\a' $ ls --quoting-style=c-maybe a\a $ ls --quoting-style=c "

Bug#1074334: coreutils: what is the undocumented ls --quoting-style=c-maybe mode?

On 26/06/2024 19:43, наб wrote: Package: coreutils Version: 9.1-1 Version: 9.4-3 Severity: normal Dear Maintainer, $ ls --quoting-style=qwe ls: invalid argument ‘qwe’ for ‘--quoting-style’ Valid arguments are: - ‘literal’ - ‘shell’ - ‘shell-always’ - ‘shell-escape’ - ‘shell-escap

Bug#1072096: PATCH: PR: src/stat.c to add magic for bcachefs filesystem

On 28/05/2024 12:50, Paul Hedderly wrote: Package: coreutils Version: 9.4-3+b1 Severity: important Tags: patch upstream d-i Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? stat does not currently recognise bc

Bug#1068891: coreutils: is join -t '' just comm -12?

On 12/04/2024 23:59, наб wrote: Package: coreutils Version: 9.1-1 Version: 9.4-3 Severity: normal Dear Maintainer, POSIX.1-202x/D3: −t char Use character char as a separator, for both input and output. Every appearance of char in a line s

Bug#1068889: coreutils: join -t refuses single-character delimiters as "multi-character tab"s

On 12/04/2024 23:42, наб wrote: Package: coreutils Version: 9.1-1 Version: 9.4-1 Severity: normal Dear Maintainer, Yes good: $ cat f1 row1f1 1 urow1 f1 2 $ cat f2 row1f2 1 urow2 f2 2 $ join f? -t ' '

Bug#1068892: coreutils: join -t accepts \0 to mean NUL; doesn't document it

On 13/04/2024 00:10, наб wrote: Package: coreutils Version: 9.1-1 Version: 9.4-3 Severity: normal Dear Maintainer, When trying to decypher -t behaviour for #1068891, the second empty-string semantic I tried was **(argv + optind), but that wasn't it. But what /is/ it is -t '\0'; i.e. given

Bug#1068864: coreutils: join -a3 errors "invalid field number" even when no field number given

On 12/04/2024 14:12, наб wrote: Package: coreutils Version: 9.1-1 Version: 9.4-3 Severity: normal Dear Maintainer, $ join -a3 /dev/null /dev/null join: invalid field number: ‘3’ Not sure where field 3 came from here. Indeed, that looks to be a copy n paste issue in: https://g

Bug#628815: coreutils: pinky makes crazy DNS queries

On 19/03/2024 10:54, deb...@perkelt.hu wrote: I looked into this and found that pinky tries to canonicalize the information in the "Where" column automaticaly, and it has no option to disable this behaviour. see line 285 pinky.c: if (*ut_host) /* See if we can canonicalize

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

On 01/02/2024 00:36, Paul Eggert wrote: On 1/31/24 06:06, Pádraig Brady wrote: To my mind the most protective option takes precedence. That's not how POSIX works with mv -i and mv -f. The last flag wins. I assume this is so that people can have aliases or shell scripts that make -

debian-bugs-dist@lists.debian.org

On 13/02/2024 12:21, Greg Wooledge wrote: Package: coreutils Version: 9.1-1 Severity: minor Tags: upstream The info page for shred includes this example code: i=$(mktemp) exec 3<>"$i" rm -- "$i" echo "Hello, world" >&3 shred - >&3 exec 3>- The last line is i

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

On 30/01/2024 18:31, Paul Eggert wrote: On 2024-01-30 03:18, Pádraig Brady wrote: So we now have the proposed change as:   - revert -n to old silent success behavior   - document -n as deprecated   - Leave --update=none as is (will be synonymous with -n)   - Provide --update=none-fail

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

On 29/01/2024 21:44, Paul Eggert wrote: On 1/29/24 08:11, Pádraig Brady wrote: Right, that's why I'm still leaning towards my proposal in the last mail. Well, I won't insist on doing nothing; however, the proposal needs ironing out and now's a good time to do it befor

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

On 29/01/2024 14:01, Michael Stone wrote: On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote: I'm not sure reverting would be best. It would introduce more confusion, and would make coreutils incompatible with FreeBSD again. Reverting makes more sense than the current situation. I do

Bug#1061612: coreutils: cp -n deprecation warning gives questionable advice

On 27/01/2024 16:02, Michael Stone wrote: On Sat, Jan 27, 2024 at 02:00:14PM +0100, Sven Joachim wrote: Package: coreutils Version: 9.4-3+b1 , | $ cp -n /bin/true tmp | cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead ` The advice to use

Bug#1059616: "wc -l" gives "illegal instruction"

On 29/12/2023 09:52, gates.ocarina...@icloud.com wrote: Package: coreutils Version: 9.1-1 When I run command wc -l, it gives “illegal instruction”. I reinstalled the coreutils package: $ wc -l Illegal instruction $ ls -l | wc -l Illegal instruction $ ls -l | wc -lw       4      29 $

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

On 16/12/2023 21:46, Bernhard Voelker wrote: 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, To clarify my summary a little, there I said that -n now _immediately_ fails.

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

On 15/12/2023 15:56, Michael Stone wrote: I tend to think this was a serious mistake: it breaks the behavior of existing scripts with no deprecation period. A stated advantage is better compatibility with freebsd, but I don't understand why that is more desirable than compatibility with all deplo

Bug#1054559: numfmt: --to lakh ?

On 25/10/2023 22:57, Trent W. Buck wrote: Package: coreutils Version: 9.1-1 Severity: wishlist File: /usr/bin/numfmt Tags: upstream In India it is common to write large numbers using combinations of "lakh" / "L" (10⁷) and "crore" / "cr" (10⁵). https://en.wikipedia.org/wiki/Lakh https:

Bug#1054128: coreutils: cp -p --parent not working

On 17/10/2023 15:54, Georg Borgström wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, This doesn't work in bookworm but works in bullseye: $ mkdir /tmp/newdir $ cp -p --parent /etc/passwd /tmp/newdir cp: ‘etc’: No such file or directory /tmp/newdir/etc gets created b

Bug#1042546: tac: /tmp/tac...: read error: Illegal seek

On 30/07/2023 20:30, наб wrote: On Sun, Jul 30, 2023 at 12:14:10PM +0100, Pádraig Brady wrote: On 30/07/2023 05:09, наб wrote: $ truncate -s 5G 5G $ cat 5G | /bin/tac | wc -c /bin/tac: /tmp/tacOOOwnf: read error: Illegal seek 0 Couldn't repo with 64 bit tac 9.1 Tested on amd64. or 3

Bug#1042546: tac: /tmp/tac...: read error: Illegal seek

On 30/07/2023 05:09, наб wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, $ truncate -s 5G 5G $ cat 5G | /bin/tac | wc -c /bin/tac: /tmp/tacOOOwnf: read error: Illegal seek 0 наб -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy:

Bug#1039488: coreutils: tail: -f fifo broken when splicing to the fifo (uses inotify)

On 26/06/2023 16:03, наб wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, This came out of a linux-fsdevel@ discussion: https://lore.kernel.org/linux-fsdevel/jbyihkyk5dtaohdwjyivambb2gffyjs3dodpofafnkkunxq7bu@jngkdxx65pux/t/#u According to Amir, at least, it is "c

Bug#1038898: coreutils: tail: -fc +{bigger-than-file} file says "file truncated" and dumps the whole file

On 22/06/2023 21:14, наб wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, -- >8 -- $ ls -l sel.c -rw-rw-r-- 1 nabijaczleweli users 193 Jun 24 2021 sel.c $ tail -c +200 -f sel.c tail: sel.c: file truncated #include #include int main() { printf("%d\n", is_seli

Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU

On 13/06/2023 09:38, Axel Beckert wrote: Hi, especially to Pádraig, Pádraig Brady wrote: cksum since v9.0 checks at runtime whether pclmul is supported. It seems that check is not working appropriately on a Xen DomU. The routine in question is pclmul_supported() at: https://github.com

Bug#1037275: dd: regression - posix expression syntax no longer supported

On 11/06/2023 18:29, Jim Meyering wrote: Thanks. The patch looks fine. My only suggestion would be a stylistic one, to change the ">" comparison to be the equivalent "<" one, i.e., change this: + && *suffix == 'B' && (suffix > str && suffix[-1] != 'B')) to this (also dropping the unnecessa

Bug#1037275: dd: regression - posix expression syntax no longer supported

On 10/06/2023 02:45, Marc Lehmann wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, I have a script that was used for some decades on multiple unices. Beginning with bookworm, it stopped working because dd no longer understands POSIX expression syntax for bs=: $ dd

Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU

On 09/06/2023 18:40, Axel Beckert wrote: Package: coreutils Version: 9.1-1 Severity: important X-Debbugs-Cc: a...@debian.org Control: affects -1 aptitude-robot On a Xen DomU running Debian 12, cksum intermittently crashes as follows: # while :; do dd if=/dev/urandom count=1 2> /dev/null | cksum

Bug#1037217: coreutils: od: -S considers printable, not graphic, characters

On 08/06/2023 00:27, наб wrote: Package: coreutils Version: 8.32-4+b1 Version: 9.1-1 Severity: normal Dear Maintainer, isgraph(3): isgraph() checks for any printable character except space. od(1): -S BYTES, --strings[=BYTES] output strings of at lea

Bug#1036827: coreutils: split: --additional-suffix= doesn't always find the /, but also shouldn't look for it?

On 27/05/2023 13:54, наб wrote: Package: coreutils Version: 8.32-4+b1 Version: 9.1-1 Severity: normal Dear Maintainer, $ echo | split --additional-suffix=asd/ split: xaaasd/: Is a directory $ echo | split --additional-suffix=asd/asd/ split: invalid suffix ‘asd/asd/’, contains directo

Bug#1036651: coreutils: split: -n with (some?) devices fails with EOVERFLOW, accepts some chardevs?

On 23/05/2023 20:44, наб wrote: Package: coreutils Version: 9.1-1 Version: 8.32-4+b1 Severity: normal Dear Maintainer, This happens regardless of the blockdev size: $ split -n20 /dev/loop2 split: /dev/loop2: cannot determine file size: Value too large for defined data type and with $

Bug#1035596: coreutils: pr: --number-lines= yields "extra characters or invalid number in the argument: ‘SHELL=/bin/bash’: ERANGE"

On 06/05/2023 01:19, наб wrote: Package: coreutils Version: 8.32-4+b1 Version: 9.1-1 Severity: normal Dear Maintainer, :v Fixed upstream with the attached. cheers, Pádraig From fae65623a92a3f150fd35cfef58dcb3d8533f94c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Sat

Bug#1035531: coreutils: fix regressions in copy dir-relative operations

Package: coreutils Version: 9.1-1 Severity: important There are regressions wrt how some directory-relative operations performed by cp,mv,install as detailed in the following upstream reports: From https://bugs.gnu.org/55910 From https://bugs.gnu.org/63245 These should be addressed by the att

Bug#1035530: coreutils: fix regressions in copy backup operations

Package: coreutils Version: 9.1-1 Severity: important There are regressions wrt how backups are performed by cp,mv,install as detailed in the following upstream reports: From https://bugs.gnu.org/55029 From https://bugs.gnu.org/62607 These should be addressed by the attached patch, Note this h

Bug#1034808: coreutils: pr: -d makes -l $odd enter a busy loop

On 24/04/2023 23:05, наб wrote: Package: coreutils Version: 8.32-4+b1 Version: 9.1-1 Severity: normal Dear Maintainer, Be hold: -- >8 -- $ time timeout 1 pr -dl2 < /dev/null real0m0.004s user0m0.004s sys 0m0.000s $ time timeout 1 pr -dl1 < /dev/null real0m1.003s user0m1.0

Bug#1034429: coreutils: install: -s runs ["strip", $f] instead of ["strip", "--", $f]; should use strip from $STRIP

On 15/04/2023 03:13, наб wrote: Package: coreutils Version: 8.32-4+b1 Version: 9.1-1 Severity: normal Dear Maintainer, -- >8 -- $ install -vs /bin/install -- q removed 'q/install' '/bin/install' -> 'q/install' $ install -vs /bin/install -- -v '/bin/install' -> '-v' Usage: strip in-file(s) Pr

Bug#1034429: coreutils: install: -s runs ["strip", $f] instead of ["strip", "--", $f]; should use strip from $STRIP

On 15/04/2023 15:47, наб wrote: On Sat, Apr 15, 2023 at 02:04:18PM +0100, Pádraig Brady wrote: But perhaps the strip program doesn't handle the convention that -- indicates end of option processing? Inasmuch as "perhaps strip doesn't use getopt(3)" /and/ &q

Bug#1034602: coreutils: nl: resets line numbers on each new section instead of new page, POSIX and SysV violation

On 19/04/2023 13:07, наб wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, POSIX very clearly says (Issue 8 Draft 2.1, same as Issue 7): 100982 The nl utility views the text it reads in terms of logical pages. Line numbering shall be reset at 100983 the start of each

Bug#1034429: coreutils: install: -s runs ["strip", $f] instead of ["strip", "--", $f]; should use strip from $STRIP

On 15/04/2023 03:13, наб wrote: Package: coreutils Version: 8.32-4+b1 Version: 9.1-1 Severity: normal Dear Maintainer, -- >8 -- $ install -vs /bin/install -- q removed 'q/install' '/bin/install' -> 'q/install' $ install -vs /bin/install -- -v '/bin/install' -> '-v' Usage: strip in-file(s) i

Bug#1034416: coreutils: stat.1: are there any shells which actually provide stat as a built-in?

On 14/04/2023 18:25, наб wrote: Package: coreutils Version: 9.1-1 Severity: minor Dear Maintainer, Quoth stat(1): -- >8 -- NOTE: your shell may have its own version of stat, which usually supersedes the version described here. Please refer to your shell's documentation for det

Bug#1034421: coreutils: install(1): says -v only notes directory creation, but also writes regular file creation

On 14/04/2023 20:23, наб wrote: Package: coreutils Version: 8.32-4+b1 Version: 9.1-1 Severity: minor Dear Maintainer, Quoth install(1): -- >8 -- -v, --verbose print the name of each directory as it is created -- >8 -- Compare: -- >8 -- $ install -v $(command -v

Bug#1027100: coreutils: wc: total overflows unchecked

On 28/12/2022 13:38, Pádraig Brady wrote: On 27/12/2022 19:31, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, -- >8 -- $ truncate -s 2E a $ wc -c a a a a a a a | uniq -c 7 2305843009213693952 a 1 16140901064495857664 total $ wc -c a a

Bug#1027413: coreutils: shuf: -i forbids 2^64-1/2^32-1, max value is ...-2?

On 31/12/2022 02:02, наб wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, We all know that for a 4-byte number the maximum value is 2^32-1, and for an 8-byte one ‒ 2^64-1. Even if we accept that for some bizzarre reason shuf wants to be limited to 4-byte numbers, then

Bug#1027412: coreutils: shuf: -i EOVERFLOW when speccing either side of the range >2^32 (ILP32 only: limited to size_t?!?)

On 31/12/2022 01:51, наб wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, On x32 and i386 I observe: -- >8 -- $ shuf -i 9223372036854775800-9223372036854775808 shuf: invalid input range: ‘9223372036854775800’: Value too large for defined data type -- >8 -- But cannot

Bug#1029103: coreutils: csplit: -z misdocumented

Fair point. I'll clarify like: commit 70dc90c579adc972644c9047543ff1dc611b89cc (HEAD -> master) Author: Pádraig Brady Date: Tue Jan 17 21:31:31 2023 + doc: csplit: more accurate --elide-empty-files help * src/csplit.c (usage): Use "suppress" rather than

Bug#1027442: coreutils: stty: soft-wrapping broken, wraps to cols+1

On 31/12/2022 15:12, наб wrote: Package: coreutils Version: 8.30-3 Severity: normal Dear Maintainer, On all three versions, at my usual teletype size, I get: $ COLUMNS=172 stty -a | wc -L 173 good catch! This off by one bug was introduced in v5.3 (2005) I'll apply the following upstream:

Bug#1027101: coreutils: wc: -c no longer optimises to st_size for regular files

On 28/12/2022 13:49, наб wrote: Control: retitle -1 coreutils: wc: -c st_size optimisation broken for files larger than max(size_t) Hi! On Wed, Dec 28, 2022 at 01:31:12PM +, Pádraig Brady wrote: On 27/12/2022 19:38, наб wrote: To repro this, run truncate -s 2E a, then wc -c a; this

Bug#1027100: coreutils: wc: total overflows unchecked

On 27/12/2022 19:31, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, -- >8 -- $ truncate -s 2E a $ wc -c a a a a a a a | uniq -c 7 2305843009213693952 a 1 16140901064495857664 total $ wc -c a a a a a a a a | uniq -c 8 23058430092136939

Bug#1027101: coreutils: wc: -c no longer optimises to st_size for regular files

On 27/12/2022 19:38, наб wrote: Package: coreutils Version: 9.1-1 Severity: normal Dear Maintainer, This is a regression against 8.32-4+b1 (bullseye). To repro this, run truncate -s 2E a, then wc -c a; this completes instantly on bullseye and spins in a read(2) loop on sid. Found as part of #

Bug#1022857: [PATCH] printf: with \U syntax, support all valid unicode points

On 27/10/2022 21:46, Bernhard Voelker wrote: On 10/27/22 16:41, Pádraig Brady wrote: Previously this was restricted to the C standard subset which restricted most values <= 0x9F, as that simplifies the C lexer. However printf(1) doesn't need this restriction. Note also the bash builti

Bug#1022857: [PATCH] printf: with \U syntax, support all valid unicode points

Previously this was restricted to the C standard subset which restricted most values <= 0x9F, as that simplifies the C lexer. However printf(1) doesn't need this restriction. Note also the bash builtin printf already supports all values <= 0x9F. * src/printf.c (main): Relax the restriction on poin

Bug#1022857: coreutils: printf refuses ~all unicode values smaller than 0x7F for \u and \U?

On 27/10/2022 01:23, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, On both of the above versions, on both LC_ALL=en_GB.UTF-8 and LC_ALL=C.UTF-8, I get: -- >8 -- $ for i in $(seq 0 255); do /bin/printf '\U'$(printf '%08X' $i)'\n'; done 2>&1 | paste - - - -

Bug#1022803: base64: URL-safe alphabet

On 26/10/2022 11:22, Jakub Wilk wrote: Package: coreutils Version: 9.1-1 Severity: wishlist RFC 4648 §5 defines an alternative URL-safe alphabet (with "-" and "_" instead of "+" and "/"). Please add an option to base64(1) to use this alphabet.

Bug#1019468: coreutils: stty: changing ispeed/ospeed says "unable to perform all requested operations" but the change sticks

On 10/09/2022 03:03, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, What's happening here? strace confirms that the TCSETSW and TCGETS values are identical in every case: ``` $ stty 134 $ stty 100 $ stty 134 $ stty ispeed 100 stty: 'standard input':

Bug#1018803: coreutils: stty: drain/-drain doesn't interact with -g/-a/default output?

On 31/08/2022 02:31, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, It appears drain/-drain is special, in that, unlike all operands, it does /not/ prevent default output and it does /not/ exclude -a/-g: -- >8 -- $ stty -drain speed 38400 baud; line = 0; -brk

Bug#1018790: coreutils: stty: "ispeed anything" is valid and doesn't seem to do anything

On 30/08/2022 21:40, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, stty ispeed and ospeed don't seem to check that the speed is valid: -- >8 -- $ LD_PRELOAD=$PWD/dumpispeed.so stty ispeed 420 cfsetispeed(0xPOINTER, 4294967295)=-1 $ LD_PRELOAD=$PWD/dumpispee

Bug#1014008: coreutils: comm --output-delimiter= (empty) separates with a single NUL, not the empty string, vice versa for --total

On 01/07/2022 11:29, Pádraig Brady wrote: On 28/06/2022 21:06, наб wrote: retitle -1 1014008 coreutils: comm --output-delimiter= (empty) separates with a single NUL, not the empty string, vice versa for --total thanks The only thing suitable for posting is "lmao". As the

Bug#1017110: coreutils: printf 'X takes X to be a byte, not a character (and missing in manual)?

On 14/08/2022 01:41, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, Consider: -- >8 -- $ /bin/printf %d\\n \'ą /bin/printf: warning: �: character(s) following character constant have been ignored 196 $ /bin/printf %d\\n \'я /bin/printf: warning: �: character

Bug#705566: date does not read the timezone from the environment variable TZ, and there is no other way to view from the CLI times in other timezones.

On 12/08/2022 11:18, Uwe Kleine-König wrote: On Sun, May 05, 2013 at 05:43:38PM -0600, Bob Proulx wrote: severity 705566 normal thanks Laurence Maddox wrote: I get this output: Current default time zone: 'America/Chicago' Local time is now: Tue Apr 16 14:45:29 CDT 2013. Universal Time is

Bug#1016049: coreutils: env --{default,ignore,block}-signal with empty argument is valid and does nothing?

On 26/07/2022 05:46, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: minor Dear Maintainer, Quoth upstream NEWS: -- >8 -- * Noteworthy changes in release 8.31 (2019-03-10) [stable] ** New features env now supports '--default-signal[=SIG]', '--ignore-signal[=SIG]', and '--bloc

Bug#1013924: coreutils: runcon -c getfscon()s program verbatim but execve()s it; trojan moment?

On 27/06/2022 19:13, Pádraig Brady wrote: On 27/06/2022 16:04, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, The strace for runcon -c true true (after a > true) contains getxattr("true", "security.selinux", "unconfined_

Bug#1014008: coreutils: comm --output-delimiter= (empty) separates with a single NUL, not the empty string, vice versa for --total

On 28/06/2022 21:06, наб wrote: retitle -1 1014008 coreutils: comm --output-delimiter= (empty) separates with a single NUL, not the empty string, vice versa for --total thanks The only thing suitable for posting is "lmao". As the title says: $ comm --total --output-delimiter= <(echo a; ec

Bug#1013924: coreutils: runcon -c getfscon()s program verbatim but execve()s it; trojan moment?

On 27/06/2022 16:04, наб wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal Dear Maintainer, The strace for runcon -c true true (after a > true) contains getxattr("true", "security.selinux", "unconfined_u:object_r:user_tmp_t", 255) = 36 execve("/usr/local/sbin/true", ["true",

Bug#1012447: coreutils: tr: tr.1 (and tr --help) falsely claims -t is only valid when translating

On 07/06/2022 13:41, наб wrote: Package: coreutils Version: 8.32-4.1 Severity: minor File: /usr/bin/tr Dear Maintainer, The soup at the end of tr.1 (and tr --help) claims: -t may be used only when translating. This is a very obvious lie: $ tr -tds abcd A aabbccddAA A Of course, -t

Bug#1004476: mv: add reflink option

On 28/01/2022 12:07, Matthias Urlichs wrote: Package: coreutils Version: 8.32-4+b1 Severity: wishlist X-Debbugs-Cc: sm...@smurf.noris.de Moving files between btrfs subvolumes doesn't work because they're different volumes. However, it's possible to reflink the files to their new location, then

Bug#1004476: mv: add reflink option

On 28/01/2022 12:07, Matthias Urlichs wrote: Package: coreutils Version: 8.32-4+b1 Severity: wishlist X-Debbugs-Cc: sm...@smurf.noris.de Moving files between btrfs subvolumes doesn't work because they're different volumes. However, it's possible to reflink the files to their new location, then

Bug#988595: stty: Doesn't work when flow control is on

On 16/05/2021 16:00, Matthias Urlichs wrote: Package: coreutils Version: 8.32-4+b1 Severity: important X-Debbugs-Cc: sm...@smurf.noris.de If terminal output cannot drain, e.g. because of flow control, "stty" does no longer work because it's using TCSETSW instead of TCSETS. See ioctl_tty(2). Fix

Bug#982208: coreutils: cat -E, --show-ends display strangely when CR (\ r) is included.

On 07/02/2021 13:08, KenichiroMATOHARA wrote: Package: coreutils Version: 8.32-4+b1 Severity: minor Dear Maintainer, When I create a text file with a newline code of "\r\n" and `cat` with the `-E, --show-ends` option, "$" is displayed at the beginning of the line. When `-A, --show-all` is used,

Bug#982300: split can cause data corruption with --number=K/N construct

Package: coreutils Version: 8.30-3 split --number=K/N can be used when there isn't enough local storage, and you want to split input to separate output devices in separate runs. Ever since v8.26 (so including centos 8), there is a nasty data corruption issue for any file over 128KiB as part of t

Bug#969664: coreutils: IF_LINT is defined to nothing, so free is never called

On 06/09/2020 20:31, Davide Prina wrote: Package: coreutils Version: 8.30-3+b1 Severity: normal Dear Maintainer, IF_LINT is defined to nothing, so free is never called. $ apt source coreutils This is correct for release builds. The uncalled free() you're seeing is fine, as the process is bei

Bug#959497: dircolors from coreutils is missing glob pattern `TERM putty*`

On 03/05/2020 02:15, Tobias Wendorff wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: coreutils Version: 8.30-3 `src/dircolors.hin` lists TERM entries, which can be glob patterns, to match against the TERM environment variable to determine if it is colorizable. It also lists `TE

Bug#930965: coreutils: seq 84x slower with --equal-width

On 23/06/19 18:05, Barak A. Pearlmutter wrote: > Package: coreutils > Version: 8.30-3 > Severity: normal > > Was using seq to write some data to test that a cheapo enormous SD card > isn't faking its capacity. Thought I'd use seq --equal-width just to > make calculations easier. But jeepers creepe

Bug#915559: 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' > > Down

Bug#895857: coreutils: sha1sum and other hashing tools are compiled without libcrypto support

On 08/02/19 07:12, Matteo Croce wrote: > Hi, > > latest gnulib have support for sendfile and AF_ALG, the kernel crypto > framework, if compiled with --with-linux-crypto. > This allows to have very fast hashing algorythms but without the > libcrypto dependency, > > coreutils$ ./configure --with-li

Bug#911572: coreutils: incorrect and inconsistent quoting in ls output

On 21/10/18 18:13, Vincent Lefevre wrote: > Package: coreutils > Version: 8.30-1 > Severity: normal > Tags: upstream > Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33113 > > I get the following with ls (GNU coreutils) 8.30. > > zira% touch a=b a=b\&c > zira% ls a=b* > 'a=b' 'a=b&c' >

Bug#901752: patch for --reflink=never

On 17/06/18 17:38, Adam Borowski wrote: > Control: tags -1 +patch > > Here's a patch. > > I find upstream's decision to not default to --reflink=auto weird. Not > reflinking when it's supported is harmful: the stated reason of "resiliency" > against disk failures is bogus: common types of failur

Bug#895857: coreutils: Additional information about coreutils from sid

On 16/04/18 16:52, Claudio Giordano wrote: > Package: coreutils > Version: 8.28-1 > Followup-For: Bug #895857 > > Dear Maintainer, > > same compile issue is present also on sid release on newer coreutils version: > > $ ldd /usr/bin/sha1sum > linux-vdso.so.1 (0x7ffc39ca8000) > li

Bug#892356: fslint: findutils on testing breaks fslint recursive search

On 02/04/18 08:57, jEsuSdA 8) wrote: > El 10/03/18 a las 14:09, Pádraig Brady escribió: >> I just tried find from git (not a debian package) >> and I don't see the issue. >> Perhaps it's already fixed in find upstream? >> Can you give more details of t

Bug#894379: coreutils: timeout (hurd, possibly hppa): fails to detect that a program has exited

On 29/03/18 08:31, Eugene V. Lyubimkin wrote: > Package: coreutils > Version: 8.28-1 > Severity: normal > > Control: affects -1 cupt > > > Hello, > > Thank you for maintaining coreutils. I use timeout(1) to conveniently > detect hanging problems in the testsuite of cupt. Unfortunately, on hurd

Bug#892356: fslint: findutils on testing breaks fslint recursive search

On 08/03/18 04:37, jEsuSdA wrote: > Package: fslint > Version: 2.44-2 > Severity: important > > Dear Maintainer, > > Upgrading findutils from stable to testing breaks the fslint-gui recursive > function to search duplicate files. > > I tried to downgrade fslint from 2.44 to 2.42 and the bug pers

Bug#721358: bug#28574: cross compilnng, man pages

On 03/10/17 13:51, Manuel A. Fernandez Montecelo wrote: > Thanks for taking a look into this, I think that it's a good idea. > > In the case that somehow help2man can still end up being used after > applying this, I think that Eleanor's patch (or an equivalent) is > still worth considering, becaus

Bug#721358: bug#28574: cross compilnng, man pages

On 23/09/17 20:18, Peter Bohning wrote: > Cross compiling for aarch64 from amd64 > > Is there no way to disable the man pages in configure options? Thanks. > > https://lists.gnu.org/archive/html/coreutils/2014-11/msg0.html I've seen this issue in various places now (CC'd). We should prob

Bug#859021: dd: document that bs overrides ibs and obs

On 29/03/17 09:04, Chris Davies wrote: > Package: coreutils > Version: 8.25-2+b1 > Severity: minor > > Dear Maintainer, > > The man page for dd does not define an interaction between bs and its more > specific ibs and obs options. POSIX does mandate that bs, if specified, > shall override ibs and

Bug#851934: bug#23035: date: regression in timezone printing (+%Z)

On 17/03/16 17:38, Paul Eggert wrote: > On 03/16/2016 08:51 PM, Assaf Gordon wrote: >> I suspect it has something to do with this commit: >>commit037e3b9847feb46cf6b58d99ce960d3987faaf52 > > You're right, and thanks for that detailed bug report. I installed the > attached patch, which fix

Bug#835904: tail --retry doesn't

On 05/09/16 07:07, Harald Dunkel wrote: > coreutils 8.25-2 seems to have the same problem. Sample: > > > % ps -ef | grep tail > harri 3815 3783 0 Aug30 pts/300:00:00 tail --retry > --max-unchanged-stats=5 -f /var/log/messages > harri11756 11708 0 08:00 pts/400:00:00 grep tail

Bug#835904: tail --retry doesn't

On 29/08/16 08:55, Harald Dunkel wrote: > Package: coreutils > Version: 8.23-4 > > I am running tail in a dedicated window for some days now: > > % ps -ef | grep tai[l] > hdunkel 2928 2915 0 Aug15 pts/100:00:00 tail --retry > --max-unchanged-stats=5 -f /var/log/messages > > Problem: It'

Bug#833948: i18n: stty --help displays bogus block

On 10/08/16 19:01, Andrea Stacchiotti wrote: > Package: coreutils > Version: 8.25-2 > Severity: minor > Tags: l10n > > It follows an invocation of stty --help with the italian locale. > > The starting block of the translation file is printed in the middle of the > output. > Somehow gettext decide

Bug#833932: coreutils: ls -b fails to show Unicode directional characters

On 10/08/16 16:15, Peter Ludikovsky wrote: > > > Am 10.08.2016 um 16:51 schrieb Pádraig Brady: >> On 10/08/16 15:21, Peter Ludikovsky wrote: >>> Package: coreutils >>> Version: 8.23-4 >>> Severity: normal >>> >>> Dear Maintainer, &g

Bug#833932: coreutils: ls -b fails to show Unicode directional characters

On 10/08/16 15:21, Peter Ludikovsky wrote: > Package: coreutils > Version: 8.23-4 > Severity: normal > > Dear Maintainer, > > This came up due to a posting on debian-user-german [1]. Apparently > certain Unicode characters, at least LEFT-TO-RIGHT EMBEDDING [2] and > RIGHT-TO-LEFT EMBEDDING [3] do

Bug#833710: tail -F /var/log/messages missed the rotation

On 08/08/16 08:28, Harald Dunkel wrote: > Package: coreutils > Version: 8.23-4 > > I am running "tail -f --retry /var/log/messages" in a terminal > for >10 days. Since inotify is available the --max-unchanged-stats > option is not set, as recommended in the man page. > > Problem: tail ignored the

Bug#832753: coreutils: stdbuf is not usable for multiarch tools (eg. i386 on amd64)

On 28/07/16 15:20, Norbert Lange wrote: > Package: coreutils > Version: 8.25-2 > Severity: normal > > Dear Maintainer, > > I am trying to use stdbuf tool on a 32bit Binary, this will result > in a failure: > > ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/coreutils/libstdbuf.so' from > LD_PRE

Bug#816703: regression: "mv from to" now fails when both are the same file

On 06/03/16 19:46, Marc Lehmann wrote: On Sun, Mar 06, 2016 at 02:06:47PM -0700, Bob Proulx wrote: The kernel system call rename(2) returns 0 for SUCCESS. And yet the operation definitely did not succeed. It did - this is how rename must behave according to POSIX. I find the above result s

Bug#816703: regression: "mv from to" now fails when both are the same file

On 03/03/16 21:24, Marc Lehmann wrote: Package: coreutils Version: 8.25-2 Severity: normal Dear Maintainer, as an extension, coreutils supported moving one file to another, when both refer to the same file. This support has been lost after upgrading from 8.23-4 (stable) to 8.25-2. That is, in

Bug#813164: coreutils: ls suddenly quotes output

On 12/02/16 01:47, Jaroslav Skarvada wrote: > Hi, > > please revert this ugly change, it's confusing and against GNU coding > standards [1]: > >> Likewise, please don’t make the behavior of a command-line program depend >> on the type of output device it gets as standard output or standard input

Bug#813164: alias ls='ls -N' is not a solution

On 03/02/16 06:05, Adam Borowski wrote: > Also, the proposed workaround, "alias ls='ls -N'" doesn't act reasonably. > It disables _all_ quoting, including nasty unprintable characters. When the > output goes to the terminal, it is meant to be read by a human. Humans can > read spaces and apostrop

Bug#813164: coreutils: ls suddenly quotes output

On 02/02/16 13:19, Jamie Heilman wrote: > This behavior needs to be reverted. There are too many assumptions > being made, the quoting used is shell-specific, and not universally > supported. For example, consider a file who's name contains a tab, > like "ab". > > $ ls > 'a'$'\t''b' > > OK, so

Bug#813164: coreutils: ls suddenly quotes output

On 30/01/16 15:45, Christoph Anton Mitterer wrote: > Hey. > > I've also just stumbled over this... while the idea is nice in > principle, I think it's quite dangerous as well... even if behaviour is > preserved when output goes to a terminal. > > a) The quotation alone doesn't necessarily help wi

  1   2   3   >