Bug#791921: coreutils: Add tmux, tmux-256colors terminfos to dircolors database

On 09/07/15 16:03, Víctor Cuadrado Juan wrote: Package: coreutils Version: 8.23-4 Severity: wishlist Dear Maintainer, The commands depending on 'dircolor' ('ls', 'dir', etc) do not output colors when you are using TERM=tmux or TERM=tmux-256color inside of tmux. This happens because

Bug#791921: coreutils: Add tmux, tmux-256colors terminfos to dircolors database

On 09/07/15 17:09, Michael Stone wrote: On Thu, Jul 09, 2015 at 04:38:07PM +0100, Pádraig Brady wrote: May be Debian specific? The following is on Fedora 22: $ TERM=screen-256color tput colors 256 $ TERM=tmux-256color tput colors tput: unknown terminal tmux-256color Fedora

Bug#799131: coreutils: df sometimes skips real entry and reports a bind mount instead

On 15/09/15 23:21, Nye Liu wrote: > Package: coreutils > Version: 8.23-4 > Severity: minor > > Dear Maintainer, > > When using bind mounts, df may have to choose only one of many equivalent > mounts: > > $ mount > /dev/sdb1 on /export/real type ext4 (rw,relatime,data=ordered) > /dev/sdb1 on

Bug#806947: coreutils: improve expr with huge numbers by GMP

On 03/12/15 11:09, Hideki Yamane wrote: > Package: coreutils > Severity: minor > Tags: patch > > Hi, > > Here's a tiny B-D patch to build coreutils with GMP(https://gmplib.org/), > it can manage huge numbers with expr. > > * Without GMP >

Bug#806947: coreutils: improve expr with huge numbers by GMP

On 03/12/15 13:21, Michael Stone wrote: > On Thu, Dec 03, 2015 at 11:43:59AM +0000, Pádraig Brady wrote: >> Another thing to consider is depending on openssl >> and using ./configure --with-openssl which will >> get significantly faster sha*sum implementations. > >

Bug#806321: coreutils: please make the build reproducible (timestamps)

On 26/11/15 13:59, Jérémy Bobbio wrote: > Source: coreutils > Version: 8.23-4 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: timestamps > > Hi! > > While working on the “reproducible builds” effort [1], we have noticed > that coreutils could

Bug#810539: coreutils: /usr/bin/stat (stat -c "%a" returns "0" instead of "000")

On 09/01/16 18:29, lopiuh wrote: > Package: coreutils > Version: 8.23-4 > Severity: normal > > Dear Maintainer, > > stat -c "%a" returns "0" instead of "000" in case of getting octal > permissions of a directory with permissions 000 (no permissions). No > permissions are set in order to

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

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

Bug#813164: coreutils: ls suddenly quotes output

On 29/01/16 16:50, Thorsten Glaser wrote: > Package: coreutils > Version: 8.25-1 > Severity: minor > > tglase@tglase-nb:~ $ mkdir -p foo/{a,b\ c}; cd foo; /bin/ls > > a 'b c' > > ’nuff said… this *should* be: > >

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

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#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

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#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 >

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]

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

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

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

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:

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

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,

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

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

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

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 the breakag

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) >

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#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\ > zira% ls a=b* > 'a=b' 'a=b' >

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' > >

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

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

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

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

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).

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

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

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#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

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

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;

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,

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

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#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 $

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;

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#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#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#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

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 builtin pri

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#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: �:

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#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#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

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

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

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 &quo

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

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

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/ "perhap

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)

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 user

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

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)

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

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

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,

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#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

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#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 |

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=: $

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

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

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

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 32 bit

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

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

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:

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

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

Bug#1063837: coreutils: shred: documentation bug: 3>- should be 3>&-

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

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

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#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#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#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 before installing changes

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#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:

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#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

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

<    1   2   3   >