bug#47103: numfmt: invalid suffix 'k'

So Pádraig's patch does allow for parsing lowercase k, but it does not change numfmt to use lowercase k in its output in si mode. As Pádraig has shown, ls uses lowercase k in --si mode. So it uses lowercase k for 1000. I think that numfmt should behave the same for consistency reasons.

bug#47103: numfmt: invalid suffix 'k'

On 25/11/2023 21:27, Sven Köhler wrote: Not only --from=si is broken. Also --to=si is broken: $ numfmt --to=si 3000 3,0K In order to not break backwards compatibility, you probably have to introduce a switch --lowercase-kilo such that --to=si produces proper SI compliant output. Then have

bug#47103: numfmt: invalid suffix 'k'

Not only --from=si is broken. Also --to=si is broken: $ numfmt --to=si 3000 3,0K In order to not break backwards compatibility, you probably have to introduce a switch --lowercase-kilo such that --to=si produces proper SI compliant output. Then have --from=si accept both uppercase and

bug#67160: defect with linux expr command on chromebook build 118

tag 67160 notabug close 67160 stop On 14/11/2023 06:42, r n wrote: I have a lenovo slim 3 chromebook with linux version 5.15.130-etc and when expr encounter an asterisk for multiplying args, it return a syntax error unexpected argument 'code 1'. All other arithmetic operators are correctly

bug#67160: defect with linux expr command on chromebook build 118

I have a lenovo slim 3 chromebook with linux version 5.15.130-etc and when expr encounter an asterisk for multiplying args, it return a syntax error unexpected argument 'code 1'. All other arithmetic operators are correctly interpreted. Please let me know if you need more information to reproduce

bug#62572: Make the errorlevel distinct perhaps?

Hi, from https://bugs.debian.org/1055694 where this broke things where files were deliberately not overwritten (klibc installs its utils but only those busybox (when used) does not provide). In this case not copying the file is absolutely not an error. Perhaps do it like diff(1) and use

bug#66919: ls -l output is misaligned

On Fri, Nov 03, 2023 at 02:20:49PM -0700, Paul Eggert wrote: > Thanks for the quick fix for the bug I introduced. Thank you for the fix!

bug#66835: Heap buffer overread in expr in regexec.c in the check_arrival_add_next_nodes function.

Thanks. This is a bug in the glibc regular expression matcher. It's part of a well known series of bugs. See, for example: https://sourceware.org/bugzilla/show_bug.cgi?id=12896 https://sourceware.org/bugzilla/show_bug.cgi?id=17356 It's not of much practical concern since the attacker should

bug#66919: ls -l output is misaligned

Thanks for the quick fix for the bug I introduced.

bug#66919: ls -l output is misaligned

On 03/11/2023 15:00, Vitaly Chikunov wrote: Hi, coreutils 9.4.0.24.75e248 seems to have regression where ls -l output is misaligned starting from size column. Example: /tmp$ ls -la total 8 drwxrwxrwt 18 root root 380 Nov 3 17:50 . drwxr-xr-x 26 root root 4096 Jul 24 18:44 ..

bug#66919: ls -l output is misaligned

Hi, coreutils 9.4.0.24.75e248 seems to have regression where ls -l output is misaligned starting from size column. Example: /tmp$ ls -la total 8 drwxrwxrwt 18 root root 380 Nov 3 17:50 . drwxr-xr-x 26 root root 4096 Jul 24 18:44 .. drwxrwxrwt 2 root root 40 Nov 2 15:20 .ICE-unix

bug#66835: Heap buffer overread in expr in regexec.c in the check_arrival_add_next_nodes function.

Hi! I was fuzzing expr in coreutils and found a bug. I compiled expr with asan and ubsan. I cloned the repository from https://github.com/coreutils/coreutils and I am using commit f7e25d5bb53e35bcdea8512dd6db07dd7e6cf452 . After compiling expr, just run './expr $(printf "\x30\x98\xc8\x9d") :

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

On 10/25/23 06:27, Pádraig Brady wrote: But thinking about it more we probably should allow lower case for base32. Yes, I'm thinking the same. While thinking (:-) I couldn't resist improving performance a bit by installing the attached. This also fixes an unlikely bug when isxdigit behavior

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

On 25/10/2023 02:30, Paul Eggert wrote: On 10/23/23 06:08, Pádraig Brady wrote: However the default operation should be the most common requirement (and also the RFC documented operation in this case). A similar case I hit very frequently is pasting hex into bc, and it's very annoying to have

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

On 10/23/23 06:08, Pádraig Brady wrote: However the default operation should be the most common requirement (and also the RFC documented operation in this case). A similar case I hit very frequently is pasting hex into bc, and it's very annoying to have to convert to uppercase before doing

bug#66714: [FIXED] Expr substr on plus symbol

On 10/23/23 12:58, petabaud51 wrote: Could you folks please add it to 'man expr'? Man pages are supposed to be terse

bug#66714: [FIXED] Expr substr on plus symbol

NEVERMIND, IT'S ON 'INFO EXPR'. Could you folks please add it to 'man expr'? XXX Greetings, I'm not sure if this is the intended UNIX/POSIX behaviour, but on: < expr substr a 1 2 , I get: a , which is right, but on: < expr substr + 1 2 I get: expr: syntax error: missing argument after ‘2’

bug#66713: Expr substr on plus symbol

Greetings, I'm not sure if this is the intended UNIX/POSIX behaviour, but on: < expr substr a 1 2 , I get: > a , which is right, but on: < expr substr + 1 2 I get: > expr: syntax error: missing argument after ‘2’ On expr "$line_of_text" 1 2, this error is thrown if the line is a simple '+'. A

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

On 23/10/2023 13:50, Niels Möller wrote: Pádraig Brady writes: Will apply the attached later. Marking this as done. Thanks! It would make some sense to me to also have options --upper/--lower; on encoding, they would specify case of the output, on decoding, they would reject the other case

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

Pádraig Brady writes: > Will apply the attached later. > Marking this as done. Thanks! It would make some sense to me to also have options --upper/--lower; on encoding, they would specify case of the output, on decoding, they would reject the other case (with default being to accept either).

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

On 23/10/2023 10:37, Niels Möller wrote: Hi, the docs for basenc --base16 says "hex encoding (RFC4648 section 8)". The referenced section in that RFC says Essentially, Base 16 encoding is the standard case-insensitive hex encoding and may be referred to as "base16" or "hex". I think it

bug#66698: I think hex decoding with basenc -d --base16 should be case-insensitive

Hi, the docs for basenc --base16 says "hex encoding (RFC4648 section 8)". The referenced section in that RFC says Essentially, Base 16 encoding is the standard case-insensitive hex encoding and may be referred to as "base16" or "hex". I think it would be both more useful, and consistent

bug#66519: b2sum, md5sum sha*sum etc broken on filenames including backslash

On Tue, Oct 17, 2023, at 02:22, Simon Richter M. Sc. wrote: > > No that doesn't make sense, this can't be intended behaviour, even if > you escape the backslash there should be no backslash in the beginning > of the checksum! > It is intended and documented as such. From coreutils.info

bug#66519: b2sum, md5sum sha*sum etc broken on filenames including backslash

No that doesn't make sense, this can't be intended behaviour, even if you escape the backslash there should be no backslash in the beginning of the checksum! On 13.10.23 16:21, Pádraig Brady wrote: tag 66519 notabug close 66519 stop On 13/10/2023 13:31, Simon Richter M. Sc. wrote: I noticed

bug#66582: annoying, needless warning messages from [fe]grep

Noah Friedman writes: > Just because a program is considered deprecated or obsolete by a standards > committee, is no reason to actually force that program out of use or > availablity. And since when does GNU adhere strictly to POSIX anyway? grep is not from coreutils. As for the issue you

bug#66582: annoying, needless warning messages from [fe]grep

Just because a program is considered deprecated or obsolete by a standards committee, is no reason to actually force that program out of use or availablity. And since when does GNU adhere strictly to POSIX anyway? So my bug report is this: fgrep and egrep should not emit any warning on stderr

bug#66294: Formal Bug Report in paste.c of Coreutils Version 9.0 by Klee

I looked at the text version of the bug report and don't understand it. Can you please rephrase the bug report so that you tell us how you invoked 'paste' (command line arguments and input file contents), what behavior you expected, and what behavior you observed? Please bear in mind that your

bug#66294: Fwd: bug#66294: Formal Bug Report in paste.c of Coreutils Version 9.0 by Klee

Forwarding this attachment to <66...@debbugs.gnu.org> as it got lost in my spam inbox when it got sent just to me. Forwarded Message Subject: Re: bug#66294: Formal Bug Report in paste.c of Coreutils Version 9.0 by Klee Date: Mon, 02 Oct 2023 10:53:57 + From:

bug#66519: b2sum, md5sum sha*sum etc broken on filenames including backslash

tag 66519 notabug close 66519 stop On 13/10/2023 13:31, Simon Richter M. Sc. wrote: I noticed some broken checksums with leading backslash and wrong filenames in my checksum files because the original filenames contained a backslash. Way to reproduce: % touch test\\test.file % b2sum

bug#66519: b2sum, md5sum sha*sum etc broken on filenames including backslash

I noticed some broken checksums with leading backslash and wrong filenames in my checksum files because the original filenames contained a backslash. Way to reproduce: % touch test\\test.file % b2sum test\\test.file expected output:

bug#66441: df: duplicated NFS4 bind mounts with the same device

I get duplicates on this reproducer with plain df, i.e. without -a. Originally, the issue was reported for RHEL 8 [1] but I can reproduce it even on the latest stable release of coreutils shipped with Fedora Rawhide. $ mkdir -p /original /bind1 /bind2 $ mount.nfs server:/nfs /original -v

bug#66265: Make padding optional with base64

Pushed. Marking this as done. cheers, Pádraig

bug#66265: Make padding optional with base64

On 29/09/2023 15:11, Pádraig Brady wrote: On 29/09/2023 10:46, Paul Millar wrote: Hi, RFC 4648 says[1]: > In some circumstances, the use of padding ("=") in base-encoded data > is not required or used. Currently, the 'base64' application always includes the padding when encoding,

bug#66329: [PATCH] dircolors: recognize “jxl” (JPEG XL) files

--- src/dircolors.hin | 1 + 1 file changed, 1 insertion(+) diff --git a/src/dircolors.hin b/src/dircolors.hin index 353831cdf..a63a97eff 100644 --- a/src/dircolors.hin +++ b/src/dircolors.hin @@ -153,6 +153,7 @@ EXEC 01;32 .avif 01;35 .jpg 01;35 .jpeg 01;35 +.jxl 01;35 .mjpg 01;35 .mjpeg

bug#66294: Formal Bug Report in paste.c of Coreutils Version 9.0 by Klee

Would you please resend your bug report as plain text? Thanks.

bug#66265: Make padding optional with base64

On 29/09/2023 10:46, Paul Millar wrote: Hi, RFC 4648 says[1]: > In some circumstances, the use of padding ("=") in base-encoded data > is not required or used. Currently, the 'base64' application always includes the padding when encoding, and prints an warning/error message (on stderr)

bug#66265: Make padding optional with base64

Hi, RFC 4648 says[1]: > In some circumstances, the use of padding ("=") in base-encoded data > is not required or used. Currently, the 'base64' application always includes the padding when encoding, and prints an warning/error message (on stderr) if padding is omitted when decoding.

bug#66253: sort manpage should be more explicit

On 9/28/23 04:22, Pádraig Brady wrote:   -n, --numeric-sort  compare according to string numerical value.     leading blanks, negative sign, decimal point,     and thousands separators are supported. Although a valiant

bug#66256: sorting NAN values with "general-numeric’

On my long list of things to do is to have sort -g sort more deterministically with NaNs. This could be done with the new totalorder and totalorderl functions in C23 Annex F.10.12.1, if available. The fix would not be portable (a these functions are newly sort-of-standardized and are often not

bug#66256: sorting NAN values with "general-numeric’

On 28/09/2023 11:43, Jorge Stolfi wrote: The full documentation of the "--general-numeric-sort" option of {sort} says that NaN values are sorted "in a consistent but machine-dependent order". This is not good. The point of the IEEE floating-point standard was to make the results of

bug#66253: sort manpage should be more explicit

On 28/09/2023 11:11, Jorge Stolfi wrote: The full documentation of sort explains that numeric sorting (as in "sort -n") accepts a leading "-" sign, decimal points, thousands separators, etc, but does not accept an explicit "+" sign. Values with explicit "+" are treated as numeric 0 and ties are

bug#66256: sorting NAN values with "general-numeric’

The full documentation of the "--general-numeric-sort" option of {sort} says that NaN values are sorted "in a consistent but machine-dependent order". This is not good. The point of the IEEE floating-point standard was to make the results of floating-point computations be independent of

bug#66253: sort manpage should be more explicit

The full documentation of sort explains that numeric sorting (as in "sort -n") accepts a leading "-" sign, decimal points, thousands separators, etc, but does not accept an explicit "+" sign. Values with explicit "+" are treated as numeric 0 and ties are broken by alpha sort. However, the

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

whoops didn't notice the debbugs email reproduced 7 times now, same results. usually 260-280 seconds. On Mon, Sep 25, 2023 at 4:43 PM Jeffrey Cliff wrote: > > Run the full test suite now at least 6 times, same results. Would you > like me to run them more? > > last couple of tests/rm/ext3-perf

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

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

bug#66056: tee Problem in 8.32, O.K in 8.30

tag 66056 notabug close 66056 stop On 17/09/2023 19:37, Pádraig Brady wrote: On 17/09/2023 18:32, Manfred Alfare wrote: Hi! Details described here: https://forums.linuxmint.com/viewtopic.php?t=404074 I don't think anything in tee has changed between 8.30 and 8.32, wrt carriage return

bug#66056: tee Problem in 8.32, O.K in 8.30

On 17/09/2023 18:32, Manfred Alfare wrote: Hi! Details described here: https://forums.linuxmint.com/viewtopic.php?t=404074 I don't think anything in tee has changed between 8.30 and 8.32, wrt carriage return handling, especially on linux. My best guess is that fsarcher has changed to do the

bug#66056: tee Problem in 8.32, O.K in 8.30

Hi! Details described here: https://forums.linuxmint.com/viewtopic.php?t=404074 Regards Manfred Alfaré -- -- Ing. Manfred Alfaré Reichsstraße 52 A 6890 Lustenau E-Mail: manfred.alf...@gmx.at Mobile: +43-680-2079232 Web : www.malfare.name

bug#65992: readutmp should check for sd_booted() and not if /run/utmp exists

Thorsten Kukuk wrote: > Who creates an additional line for "seat0", which no other tools creates > and which it did not create before. Since some display manager writes > wrongly multiple utmp entries To me, that's a feature, not a bug. Systemd has introduced the concept of seats [1], and the

bug#65992: readutmp should check for sd_booted() and not if /run/utmp exists

Sorry, looks like strace confused me (since this checks the existence of /run/utmp) and the problem is a different one. kukuk@rubicon:~> ls /run/utmp ls: cannot access '/run/utmp': No such file or directory kukuk@rubicon:~> w 14:54:41 up 4 days, 4:51, 2 users, load average: 0,11, 0,13, 0,46

bug#65992: readutmp should check for sd_booted() and not if /run/utmp exists

[CCing bug-gnulib, because the readutmp code lives in gnulib] Thorsten Kukuk wrote: > if there is no /run/utmp file, /usr/bin/who falls back correctly to the > systemd-logind interface and shows correct data. > > But there are applications, which don't use the libc interface for >

bug#65992: readutmp should check for sd_booted() and not if /run/utmp exists

Hi, if there is no /run/utmp file, /usr/bin/who falls back correctly to the systemd-logind interface and shows correct data. But there are applications, which don't use the libc interface for reading/writing utmp entries, they have their own implementation. And this implementations create the

bug#65599: mv and cp give a pointless warning when moving/copying a directory

On 2023-09-02 04:18, Bruno Haible wrote: chmod fails with EACCES, hence per POSIX it's buggy. Thanks, I reported the bug with chmod, chown, etc. to the linux-cifs mailing list, here:

bug#65659: RFC: changing printf(1) behavior on %b

Stephane Chazelas wrote in <20230902084912.vdfedsgbnat2w...@chazelas.org>: |2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The \ |Open Group: ... |>|FWIW, a "printf %b" github shell code search returns ~ 29k |>|entries

bug#65697: numproc, add flag to get number of available cores

On 02/09/2023 10:38, Simon Heimberg wrote: Hello Depending on what a process is mainly limited by, the ideal number of processes to run concurrently varies. A frequent use case is to run one process on each _physical_ core (which is available) than on each logical processing unit. I propose to

bug#65599: mv and cp give a pointless warning when moving/copying a directory

Paul Eggert wrote: > Yes please. If chmod also does not work coreutils might need more > workarounds. > > Just to be clear; please try it on a file where chmod should fail > because you don't own the file and you're not root. chmod should fail > with EPERM in this case; it it fails with EACCES

bug#65697: numproc, add flag to get numer of available cores

Hello Depending on what a process is mainly limited by, the ideal number of processes to run concurrently varies. A frequent use case is to run one process on each _physical_ core (which is available) than on each logical processing unit. I propose to introduce a flag --core which returns the

bug#65659: RFC: changing printf(1) behavior on %b

2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The Open Group: [...] > |FWIW, a "printf %b" github shell code search returns ~ 29k > |entries > |(https://github.com/search?q=printf+%25b+language%3AShell=code=Sh\ > |ell) > | > |That likely returns only a small subset of

bug#65659: RFC: changing printf(1) behavior on %b

Stephane Chazelas via austin-group-l at The Open Group wrote in <20230901181024.pwx4plwclz7ij...@chazelas.org>: |2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group: ... |> How many scripts in the wild actually use %b, though? And if there |> are such scripts, anything

bug#65659: RFC: changing printf(1) behavior on %b

On Fri, Sep 1, 2023 at 8:10 PM Stephane Chazelas wrote: > 2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group: > > > FWIW, a "printf %b" github shell code search returns ~ 29k > entries > ( > https://github.com/search?q=printf+%25b+language%3AShell=code=Shell > ) > > Ha

bug#65599: mv and cp give a pointless warning when moving/copying a directory

On 2023-09-01 19:52, Paul Eggert wrote: Yes please. If chmod also does not work coreutils might need more workarounds. Just to be clear; please try it on a file where chmod should fail because you don't own the file and you're not root. chmod should fail with EPERM in this case; it it fails

bug#65599: mv and cp give a pointless warning when moving/copying a directory

On 2023-09-01 16:12, Bruno Haible wrote: Well, you asked me to try it on / but / is an ext4 FS, not a CIFS FS on my system. Should I try it also on a directory inside the CIFS mount? Yes please. If chmod also does not work coreutils might need more workarounds.

bug#65599: mv and cp give a pointless warning when moving/copying a directory

Paul Eggert wrote: > Good, thanks for confirming that the chmod family does not have a > similar bug. Well, you asked me to try it on / but / is an ext4 FS, not a CIFS FS on my system. Should I try it also on a directory inside the CIFS mount? > I installed the attached workaround into

bug#65599: mv and cp give a pointless warning when moving/copying a directory

Paul Eggert wrote: > > If you compile and run the attached > > program on a file that you don't own (e.g., './a.out /'), does it > > incorrectly issue "Permission denied" instead of "Operation not > > permitted" diagnostics? and I replied: > In this case, the diagnostic is "Operation not

bug#65599: mv and cp give a pointless warning when moving/copying a directory

Good, thanks for confirming that the chmod family does not have a similar bug. I installed the attached workaround into coreutils master on Savannah. Please give it a try.From 5f971361608749e1245c5eb12096de2acd32bf83 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 1 Sep 2023 15:05:21

bug#65659: RFC: changing printf(1) behavior on %b

2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group: [...] > > Well in all case %b can not change semantic in the bash script, since it is > > there for so long, even if it depart from python, perl, libc, it is > > unfortunate but that's the way it is, nobody want a semantic

bug#65599: mv and cp give a pointless warning when moving/copying a directory

Paul Eggert wrote: > If you compile and run the attached > program on a file that you don't own (e.g., './a.out /'), does it > incorrectly issue "Permission denied" instead of "Operation not > permitted" diagnostics? In this case, the diagnostic is "Operation not permitted" (from EPERM): $

bug#65599: mv and cp give a pointless warning when moving/copying a directory

On 2023-09-01 08:09, Bruno Haible wrote: It applies to all 4 variants, as can be seen from applying it to a directory: $ ./a.out /media/nas/bruno/dir1 lchown: Permission denied fchownat: Permission denied chown: Permission denied fchown: Permission denied Thanks, for coreutils it'd be helpful

bug#65659: RFC: changing printf(1) behavior on %b

If compatibility with C is really that important, shouldn't we be fixing %c? Its current behaviour as a synonym for %.1s doesn't provide significant utility, and arguably differs from C's "take an int and output the corresponding single byte", not "take the first byte of a string and output that".

bug#65674: (no subject)

Hello Bruno thanks for the fast response and for the update suggestion. Atm we are at openssl-3, but this bug was discovered by chance, because a package I was testing forced the downgrade to openssl-1 Agostino

bug#65659: RFC: changing printf(1) behavior on %b

2023-09-01 07:15:14 -0500, Eric Blake: [...] > > Note that in bash, you need both > > > > shopt -s xpg_echo > > set -o posix > > > > To get a XSI echo. Without the latter, options are still > > recognised. You can get a XSI echo without those options with: > > > > xsi_echo() { > > local IFS='

bug#65599: mv and cp give a pointless warning when moving/copying a directory

Paul Eggert wrote: > it'd be helpful to know whether the bug is limited to fchownat or > (as I suspect) applies also to the other chown variants. Could you try > running the attached program on your platform, to see whether the bug > affects these other variants? It applies to all 4 variants,

bug#65599: mv and cp give a pointless warning when moving/copying a directory

Thanks for the followup. I looked into fixing it in Gnulib and it appears that this would require an extra syscall (or maybe even two) per file when copying to a CIFS filesystem, which I'd rather avoid. So I'm leaning more towards working around the bug in coreutils. Before doing that, it'd be

bug#65674: Build failure with

Sam James wrote: > Forwarding a downstream report at https://bugs.gentoo.org/913368 > of coreutils-9.4 failing to build with openssl-1.1.x: > """ > x86_64-pc-linux-gnu-gcc -I. -I./lib -DHASH_ALGO_BLAKE2=1 -DHAVE_CONFIG_H > -Ilib -I./lib -Isrc -I./src-O2 -march=x86-64 -pipe -pipe >

bug#65659: RFC: changing printf(1) behavior on %b

On Fri, Sep 01, 2023 at 07:19:13AM +0200, Phi Debian wrote: > Well after reading yet another thread regarding libc_printf() I got to > admit that even %B is crossed out, (Yet already choosen by ksh93) > > The other thread also speak about libc_printf() documentting %# as > undefined for things

bug#65659: RFC: changing printf(1) behavior on %b

On Fri, Sep 01, 2023 at 08:59:19AM +0100, Stephane Chazelas wrote: > 2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group: > [...] > > The current POSIX says that %b was added so that on a non-XSI > > system, you could do: > > > > my_echo() { > > printf %b\\n "$*" > > } >

bug#65674: Build failure with

Hello, Forwarding a downstream report at https://bugs.gentoo.org/913368 of coreutils-9.4 failing to build with openssl-1.1.x: """ x86_64-pc-linux-gnu-gcc -I. -I./lib -DHASH_ALGO_BLAKE2=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src-O2 -march=x86-64 -pipe -pipe -frecord-gcc-switches

bug#65659: RFC: changing printf(1) behavior on %b

2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group: [...] > The current POSIX says that %b was added so that on a non-XSI > system, you could do: > > my_echo() { > printf %b\\n "$*" > } That is dependant on the current value of $IFS. You'd need: xsi_echo() ( IFS=' '

bug#65659: RFC: changing printf(1) behavior on %b

2023-09-01 09:44:08 +0300, Oğuz via austin-group-l at The Open Group: > On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote: > > My vote is for posix_printf %B mapping to libc_printf %b > > In the shell we already have bc for base conversion. Does POSIX really > have to support C2x %b in the first

bug#65659: RFC: changing printf(1) behavior on %b

On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote: > My vote is for posix_printf %B mapping to libc_printf %b In the shell we already have bc for base conversion. Does POSIX really have to support C2x %b in the first place?

bug#65659: RFC: changing printf(1) behavior on %b

2023-09-01 07:13:36 +0100, Stephane Chazelas via austin-group-l at The Open Group: > 2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group: > > In today's Austin Group call, we discussed the fact that printf(1) has > > mandated behavior for %b (escape sequence processing

bug#65659: RFC: changing printf(1) behavior on %b

On Thu, Aug 31, 2023 at 9:11 PM Chet Ramey wrote: > > I doubt I'd ever remove %b, even in posix mode -- it's already been there > for 25 years. > > > Neither one is a very good choice, but `#' is the better one. It at least > has a passing resemblence to the desired functionality. > > Why not

bug#65659: RFC: changing printf(1) behavior on %b

Well after reading yet another thread regarding libc_printf() I got to admit that even %B is crossed out, (Yet already choosen by ksh93) The other thread also speak about libc_printf() documentting %# as undefined for things other than a, A, e, E, f, F, g, and G, yet the same thread also talk

bug#65659: RFC: changing printf(1) behavior on %b

2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group: > In today's Austin Group call, we discussed the fact that printf(1) has > mandated behavior for %b (escape sequence processing similar to XSI > echo) that will eventually conflict with C2x's desire to introduce %b > to

bug#65659: RFC: changing printf(1) behavior on %b

On Thu, Aug 31, 2023 at 03:02:22PM -0500, Eric Blake wrote: > On Thu, Aug 31, 2023 at 03:10:58PM -0400, Chet Ramey wrote: > > Why not standardize another character, like %B? I suppose I'll have to look > > at the etherpad for the discussion. I think that came up on the mailing > > list, but I

bug#65659: [PATCH] printf: add %#s alias to %b

On 31/08/2023 19:31, Eric Blake wrote: POSIX Issue 8 will be obsoleting %b (escape sequence interpolation) so that future Issue 9 can change to having %b (binary literal output) that aligns with C2x. But since escape interpolation may still remain useful, POSIX suggested %#s (which is undefined

bug#65659: RFC: changing printf(1) behavior on %b

On Thu, Aug 31, 2023 at 03:10:58PM -0400, Chet Ramey wrote: > On 8/31/23 11:35 AM, Eric Blake wrote: > > In today's Austin Group call, we discussed the fact that printf(1) has > > mandated behavior for %b (escape sequence processing similar to XSI > > echo) that will eventually conflict with C2x's

bug#65659: RFC: changing printf(1) behavior on %b

On 2023-08-31 08:35, Eric Blake wrote: Typing-wise, %#s as a synonym for %b is probably going to be easier (less shell escaping needed). Is there any interest in a patch to coreutils or bash that would add such a synonym, to make it easier to leave that functionality in place for POSIX Issue 9

bug#65659: RFC: changing printf(1) behavior on %b

On 8/31/23 11:35 AM, Eric Blake wrote: In today's Austin Group call, we discussed the fact that printf(1) has mandated behavior for %b (escape sequence processing similar to XSI echo) that will eventually conflict with C2x's desire to introduce %b to printf(3) (to produce 0b000... binary

bug#65659: [PATCH] printf: add %#s alias to %b

POSIX Issue 8 will be obsoleting %b (escape sequence interpolation) so that future Issue 9 can change to having %b (binary literal output) that aligns with C2x. But since escape interpolation may still remain useful, POSIX suggested %#s (which is undefined in all versions of C) as a possible

bug#65659: RFC: changing printf(1) behavior on %b

In today's Austin Group call, we discussed the fact that printf(1) has mandated behavior for %b (escape sequence processing similar to XSI echo) that will eventually conflict with C2x's desire to introduce %b to printf(3) (to produce 0b000... binary literals). For POSIX Issue 8, we plan to mark

bug#65617: coreutils 9.4: seg.fault in readutmp with systemd

Paul Eggert wrote: > I installed the attached patch into Gnulib > and this should appear in the next coreutils release. Unfortunately, this patch introduces a memory leak: If num_sessions == 0 and sessions != NULL (which can happen, according to the man page), we need to call free (sessions).

bug#65599: mv and cp give a pointless warning when moving/copying a directory

Thanks for looking into this, Paul. But there's a big misunderstanding. This is not on Android. It's on Linux with glibc (Ubuntu 22.04, to be precise), as can be seen from the log file: openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 and from the fact that I could

bug#65599: mv and cp give a pointless warning when moving/copying a directory

On 2023-08-29 11:20, Bruno Haible wrote: People say that "chown only works for root anyway" [1] I don't think that is the issue here. fchownat is failing with EACCES, which is supposed to mean that search permission is denied on a component of the path prefix, but in Android I guess EACCES

bug#65617: coreutils 9.4: seg.fault in readutmp with systemd

Thanks for reporting that. I installed the attached patch into Gnulib and this should appear in the next coreutils release.From 1e6a26f9312bb47e070f94b17b14dc1a6ffbb74f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 30 Aug 2023 18:26:52 -0700 Subject: [PATCH] readutmp: fix core dump if

bug#65617: coreutils 9.4: seg.fault in readutmp with systemd

coreutils 9.4 with the --enable-systemd option seg.faults in lib/readutmp.c, line 801: for (session_ptr = sessions; *session_ptr != NULL; session_ptr++) If there is no session, "sessions" is NULL and "*session_ptr" will dereference a NULL pointer. Affected are who, pinky and uptime. A simple

bug#65599: mv and cp give a pointless warning when moving/copying a directory

When I move a directory from an ext4 file system to a CIFS v1 file system, I get a diagnostic mv: failed to preserve ownership for '...': Permission denied although the owner and group of the directory after and before the move are the same. So, there is actually nothing to warn about. $ mv

bug#65423: README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

On 8/22/23 02:58, Osipov, Michael (IN IT IN) wrote: So no action is required anymore. Thanks for confirming that. Closing the bug report.

bug#65423: README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

On 2023-08-21 21:25, Paul Eggert wrote: On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug Reports wrote: in 9.3 year 2038 support with 64 bit time_t was made required [1], here on HP-UX this is a bit problematic, but that's not the actual problem. The diff between 9.2 and 9.3

bug#65423: README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug Reports wrote: in 9.3 year 2038 support with 64 bit time_t was made required [1], here on HP-UX this is a bit problematic, but that's not the actual problem. The diff between 9.2 and 9.3 [2] says how this can be fixed on

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