bug#49716: no -print0 for ls?
On 7/26/21 12:52 PM, Bernhard Voelker wrote: The following options don't work well with --null, because they output other, additional information or transform/escape the file names: ... -l use a long listing format I don't see a problem with -l, as --null can be a win with -l because file names are more-reliably parsed in output from -l --null than they are from plain -l. More generally, I don't see a problem with -F, --file-type, --full-time, -g, --indicator-style, -i, -l, -n, -o, -p, -R, -s, or -Z. In all those cases it can be a win to use --null so that file names are unambiguous and easily parsed. I do see a problem for -b, -C, --color, -q, -Q, --quoting-style, -x. Pádraig made a similar point. I'll look into this and into his other points. this would IMO warrant a new utility rather than blowing ls(1). Oh I don't know, ls seems to be a natural home for "Do what 'ls' does, except with NUL instead of newline."
bug#49716: no -print0 for ls?
On 7/26/21 5:00 PM, Pádraig Brady wrote: > The patch set looks good thanks. Wait - I see another reason why we didn't add it earlier: The --null option is not compatible with about half of the other options of ls(1); at least the actual output is more than questionable, and not usable in programmatic context. The -R option is the first one which obviously can't work as such. The following options don't work well with --null, because they output other, additional information or transform/escape the file names: -b, --escape print C-style escapes for nongraphic characters -C list entries by columns --color[=WHEN] colorize the output; WHEN can be 'always' (default if omitted), 'auto', or 'never'; more info below -F, --classify append indicator (one of */=>@|) to entries --file-typelikewise, except do not append '*' --full-timelike -l --time-style=full-iso -g like -l, but do not list owner --indicator-style=WORD append indicator with style WORD to entry names: none (default), slash (-p), file-type (--file-type), classify (-F) -i, --inodeprint the index number of each file -l use a long listing format -m fill width with a comma separated list of entries -n, --numeric-uid-gid like -l, but list numeric user and group IDs -o like -l, but do not list group information -p, --indicator-style=slash append / indicator to directories -q, --hide-control-chars print ? instead of nongraphic characters -Q, --quote-name enclose entry names in double quotes --quoting-style=WORD use quoting style WORD for entry names: literal, locale, shell, shell-always, shell-escape, shell-escape-always, c, escape (overrides QUOTING_STYLE environment variable) -R, --recursivelist subdirectories recursively -s, --size print the allocated size of each file, in blocks -x list entries by lines instead of by columns -Z, --context print any security context of each file While the actual change is small - i.e., change the newline to a '\0' for the eolchar, I'm afraid that it will become quite hairy to discuss the actual problems of future users of that option when combining it with one of the above options. I really have some qualms with adding --null to ls(1). If this is about listing files in the current directory in a certain sort order for a processing purpose, then this would IMO warrant a new utility rather than blowing ls(1). Have a nice day, Berny
bug#49716: no -print0 for ls?
On 26/07/2021 09:05, Paul Eggert wrote: On 7/25/21 10:10 AM, Pádraig Brady wrote: Right we should be especially careful of short options with ls. A long only option should suffice OK, I installed the attached to implement 'ls --null'. (The last patch is the actual change; the other patches are cleanups.) This addresses the problem raised in the bug report. Is there any pattern as to why some coreutils programs have a --null option and others have a --zero option? The two options seem to mean the same thing. Should we work toward standardizing on one spelling or the other (of course maintaining backward compatibility). The patch set looks good thanks. Note we were consolidating on --zero rather than --null $ grep -l -F -- --zero src/*.c | fmt src/basename.c src/comm.c src/cut.c src/dirname.c src/head.c src/id.c src/join.c src/md5sum.c src/numfmt.c src/paste.c src/readlink.c src/realpath.c src/shred.c src/shuf.c src/sort.c src/tail.c src/uniq.c $ grep -l -F -- --null src/*.c | fmt src/du.c src/env.c src/ls.c src/printenv.c So I'd have a slight preference for --zero. Also what about having --zero imply: --quoting-style=literal --show-control-chars --format=single-column That seems like a fine shortcut given that would be correct in the vast majority of cases, and that the need for the above may not be obvious to users. Also a small point; should --dired disable --null as it may then be non parseable? thanks, Pádraig. p.s. I installed a trivial patch to avoid syntax-check issues
bug#49741: basenc --base64url decoding bug
Hi! I seem to have encountered a bug in basenc. While decoding a large base64url-encoded JSON blob, the decoder drops some characters, rendering the output invalid JSON. I've verified against Python's built-in base64url decoder, which correctly produces the expected result while basenc does not. I've attached the test case, which I've tried to minimize as much as I can. All my attempts to remove more of the JSON values have made the bug not trigger, or at least not as easily detectable. Reproduction instructions: $ uname -a Linux HOST 5.13.4-arch1-1 #1 SMP PREEMPT Tue, 20 Jul 2021 16:58:51 + x86_64 GNU/Linux $ basenc --version basenc (GNU coreutils) 8.32 $ cat expected-output.txt | sha256sum fdb9a77c44e9cd612ad3a3cc210e03ea9782e342bb8293b49530e032b2e4ed0e - $ cat actual-output.txt | sha256sum 86bce7aa1d0c2da8432cfbb6da4ad2e559012dadbd1abde711e96b2c518d2b11 - $ basenc -d --base64 input.txt | sha256sum 86bce7aa1d0c2da8432cfbb6da4ad2e559012dadbd1abde711e96b2c518d2b11 - $ diff actual-output.txt expected-output.txt 160c160 < "minor: 0 --- > "minor": 0 Installed from Arch Linux official repos, package version coreutils 8.32-1. Thanks for making basenc, and please let me know if I can do anything more to help! /Emil ewogICJlbnRyaWVzIjogWwogICAgewogICAgICAiYWFpZCI6ICI0ZTRlIzQwMDUiLAogICAgICAibWV0YWRhdGFTdGF0ZW1lbnQiOiB7CiAgICAgICAgImFhaWQiOiAiNGU0ZSM0MDA1IiwKICAgICAgICAiYXR0YWNobWVudEhpbnQiOiBbCiAgICAgICAgICAiaW50ZXJuYWwiCiAgICAgICAgXSwKICAgICAgICAiYXR0ZXN0YXRpb25Sb290Q2VydGlmaWNhdGVzIjogW10sCiAgICAgICAgImF0dGVzdGF0aW9uVHlwZXMiOiBbCiAgICAgICAgICAiYmFzaWNfc3Vycm9nYXRlIgogICAgICAgIF0sCiAgICAgICAgImF1dGhlbnRpY2F0aW9uQWxnb3JpdGhtcyI6IFsKICAgICAgICAgICJyc2FfZW1zYV9wa2NzMV9zaGEyNTZfcmF3IgogICAgICAgIF0sCiAgICAgICAgImF1dGhlbnRpY2F0b3JWZXJzaW9uIjogMjU2LAogICAgICAgICJkZXNjcmlwdGlvbiI6ICJUb3VjaCBJRCwgRmFjZSBJRCwgb3IgUGFzc2NvZGUiLAogICAgICAgICJrZXlQcm90ZWN0aW9uIjogWwogICAgICAgICAgImhhcmR3YXJlIiwKICAgICAgICAgICJ0ZWUiCiAgICAgICAgXSwKICAgICAgICAibGVnYWxIZWFkZXIiOiAiaHR0cHM6Ly9maWRvYWxsaWFuY2Uub3JnL21ldGFkYXRhL21ldGFkYXRhLXN0YXRlbWVudC1sZWdhbC1oZWFkZXIvIiwKICAgICAgICAibWF0Y2hlclByb3RlY3Rpb24iOiBbCiAgICAgICAgICAidGVlIgogICAgICAgIF0sCiAgICAgICAgInByb3RvY29sRmFtaWx5IjogInVhZiIsCiAgICAgICAgInB1YmxpY0tleUFsZ0FuZEVuY29kaW5ncyI6IFsKICAgICAgICAgICJyc2FfMjA0OF9yYXciCiAgICAgICAgXSwKICAgICAgICAic2NoZW1hIjogMywKICAgICAgICAidGNEaXNwbGF5IjogWwogICAgICAgICAgImFueSIKICAgICAgICBdLAogICAgICAgICJ0Y0Rpc3BsYXlDb250ZW50VHlwZSI6ICJ0ZXh0L3BsYWluIiwKICAgICAgICAidXB2IjogWwogICAgICAgICAgewogICAgICAgICAgICAibWFqb3IiOiAxLAogICAgICAgICAgICAibWlub3IiOiAwCiAgICAgICAgICB9LAogICAgICAgICAgewogICAgICAgICAgICAibWFqb3IiOiAxLAogICAgICAgICAgICAibWlub3IiOiAxCiAgICAgICAgICB9CiAgICAgICAgXSwKICAgICAgICAidXNlclZlcmlmaWNhdGlvbkRldGFpbHMiOiBbCiAgICAgICAgICBbCiAgICAgICAgICAgIHsKICAgICAgICAgICAgICAiY2FEZXNjIjogewogICAgICAgICAgICAgICAgImJhc2UiOiAxMCwKICAgICAgICAgICAgICAgICJibG9ja1Nsb3dkb3duIjogNjAsCiAgICAgICAgICAgICAgICAibWF4UmV0cmllcyI6IDUsCiAgICAgICAgICAgICAgICAibWluTGVuZ3RoIjogNAogICAgICAgICAgICAgIH0sCiAgICAgICAgICAgICAgInVzZXJWZXJpZmljYXRpb25NZXRob2QiOiAicGFzc2NvZGVfaW50ZXJuYWwiCiAgICAgICAgICAgIH0KICAgICAgICAgIF0sCiAgICAgICAgICBbCiAgICAgICAgICAgIHsKICAgICAgICAgICAgICAiYmFEZXNjIjogewogICAgICAgICAgICAgICAgImJsb2NrU2xvd2Rvd24iOiAwLAogICAgICAgICAgICAgICAgIm1heFJldHJpZXMiOiA1LAogICAgICAgICAgICAgICAgIm1heFRlbXBsYXRlcyI6IDAsCiAgICAgICAgICAgICAgICAic2VsZkF0dGVzdGVkRkFSIjogMC4wLAogICAgICAgICAgICAgICAgInNlbGZBdHRlc3RlZEZSUiI6IDAuMAogICAgICAgICAgICAgIH0sCiAgICAgICAgICAgICAgInVzZXJWZXJpZmljYXRpb25NZXRob2QiOiAiZmluZ2VycHJpbnRfaW50ZXJuYWwiCiAgICAgICAgICAgIH0KICAgICAgICAgIF0KICAgICAgICBdCiAgICAgIH0sCiAgICAgICJzdGF0dXNSZXBvcnRzIjogWwogICAgICAgIHsKICAgICAgICAgICJlZmZlY3RpdmVEYXRlIjogIjIwMTgtMDUtMTkiLAogICAgICAgICAgInN0YXR1cyI6ICJOT1RfRklET19DRVJUSUZJRUQiCiAgICAgICAgfQogICAgICBdLAogICAgICAidGltZU9mTGFzdFN0YXR1c0NoYW5nZSI6ICIyMDE4LTA1LTE5IgogICAgfSwKICAgIHsKICAgICAgImFhZ3VpZCI6ICJjNWVmNTVmZi1hZDlhLTRiOWYtYjU4MC1hZGViYWZlMDI2ZDAiLAogICAgICAibWV0YWRhdGFTdGF0ZW1lbnQiOiB7CiAgICAgICAgImFhZ3VpZCI6ICJjNWVmNTVmZi1hZDlhLTRiOWYtYjU4MC1hZGViYWZlMDI2ZDAiLAogICAgICAgICJhdHRhY2htZW50SGludCI6IFsKICAgICAgICAgICJleHRlcm5hbCIsCiAgICAgICAgICAid2lyZWQiCiAgICAgICAgXSwKICAgICAgICAiYXR0ZXN0YXRpb25Sb290Q2VydGlmaWNhdGVzIjogWwogICAgICAgICAgIk1JSURIakNDQWdhZ0F3SUJBZ0lFRzBCVDl6QU5CZ2txaGtpRzl3MEJBUXNGQURBdU1Td3dLZ1lEVlFRREV5TlpkV0pwWTI4Z1ZUSkdJRkp2YjNRZ1EwRWdVMlZ5YVdGc0lEUTFOekl3TURZek1UQWdGdzB4TkRBNE1ERXdNREF3TURCYUdBOHlNRFV3TURrd05EQXdNREF3TUZvd0xqRXNNQ29HQTFVRUF4TWpXWFZpYVdOdklGVXlSaUJTYjI5MElFTkJJRk5sY21saGJDQTBOVGN5TURBMk16RXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDL2p3WXVoQlZscWFpWVdFTXNyV0Zpc2dKK1B0TTkxZVNycEk0VEs3VTUzbXdDSWF3U0RIeTh2VW1rNU4yS0FqOWFidlQ5TlA1U01TMWhRaTN1c3hvWUdvblhRZ2ZPNlpYeVVBOWErS0FrcWRGbkJubHl1Z1NlQ09lcDhFZFpGZnNhUkZ0TWprd3o1R2N6MlB5NHZJWXZDZE1IUHR3YXowYlZ1em5ldWVJRXo2VG5RakU2M1JkdDJ6YnduZWJ3VEc1WnliZVdTd2J6eStCSjM0WkhjVWhQQVk4OXlKUVh1RTBJek1aRmNFQmJQTlJiV0VDUktnanEvL3FUOW5tRE9GVmxTUkN0MndpcVBTemx1d24rditzdVFFQnNValRHTUVkMjV0S1hYVGtOVz
bug#49716: no -print0 for ls?
On 7/25/21 10:10 AM, Pádraig Brady wrote:
Right we should be especially careful of short options with ls.
A long only option should suffice
OK, I installed the attached to implement 'ls --null'. (The last patch
is the actual change; the other patches are cleanups.) This addresses
the problem raised in the bug report.
Is there any pattern as to why some coreutils programs have a --null
option and others have a --zero option? The two options seem to mean the
same thing. Should we work toward standardizing on one spelling or the
other (of course maintaining backward compatibility).
From 3753c706b7ccd756db955e850175b79f22911d57 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 17 Jul 2021 15:07:29 -0500
Subject: [PATCH 1/7] env: fix usage typo
* src/env.c (usage): Fix pluralization typo.
---
src/env.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/env.c b/src/env.c
index 5a30696d9..685c24adb 100644
--- a/src/env.c
+++ b/src/env.c
@@ -141,7 +141,7 @@ Set each NAME to VALUE in the environment and run COMMAND.\n\
--default-signal[=SIG] reset handling of SIG signal(s) to the default\n\
"), stdout);
fputs (_("\
- --ignore-signal[=SIG] set handling of SIG signals(s) to do nothing\n\
+ --ignore-signal[=SIG] set handling of SIG signal(s) to do nothing\n\
"), stdout);
fputs (_("\
--list-signal-handling list non default signal handling to stderr\n\
--
2.30.2
From 5622ab450e2402570cef48a5fed0eb0b4523b264 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 18 Jul 2021 00:12:29 -0500
Subject: [PATCH 2/7] maint: fix white space
---
configure.ac | 23 +---
m4/jm-macros.m4 | 4 +-
src/dd.c | 2 +-
src/expand.c | 2 +-
src/factor.c | 143 ---
src/set-fields.c | 24
src/stdbuf.c | 2 +-
src/unexpand.c | 2 +-
8 files changed, 105 insertions(+), 97 deletions(-)
diff --git a/configure.ac b/configure.ac
index c4d8ec0b6..6960b486a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -287,7 +287,8 @@ void unset_TZ (void)
if (! (to[0][0] == 'T' && to[0][1] == 'Z' && to[0][2] == '='))
to++;
}
-int main()
+int
+main ()
{
time_t now = time ((time_t *) 0);
int hour_GMT0, hour_unset;
@@ -529,10 +530,11 @@ AC_LINK_IFELSE(
[AC_LANG_SOURCE([[
#include
-int main(void)
+int
+main (void)
{
unsigned int eax, ebx, ecx, edx;
- __get_cpuid(1, &eax, &ebx, &ecx, &edx);
+ __get_cpuid (1, &eax, &ebx, &ecx, &edx);
return 1;
}
]])
@@ -551,10 +553,11 @@ AC_COMPILE_IFELSE(
[AC_LANG_SOURCE([[
#include
-int main(void)
+int
+main (void)
{
__m128i a, b;
- a = _mm_clmulepi64_si128(a, b, 0x00);
+ a = _mm_clmulepi64_si128 (a, b, 0x00);
return 1;
}
]])
@@ -580,10 +583,11 @@ AC_LINK_IFELSE(
[AC_LANG_SOURCE([[
#include
-int main(void)
+int
+main (void)
{
unsigned int eax = 0, ebx = 0, ecx = 0, edx = 0;
- __get_cpuid_count(7, 0, &eax, &ebx, &ecx, &edx);
+ __get_cpuid_count (7, 0, &eax, &ebx, &ecx, &edx);
return 1;
}
]])
@@ -600,10 +604,11 @@ AC_COMPILE_IFELSE(
[AC_LANG_SOURCE([[
#include
-int main(void)
+int
+main (void)
{
__m256i a, b;
- a = _mm256_sad_epu8(a, b);
+ a = _mm256_sad_epu8 (a, b);
return 1;
}
]])
diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4
index fb66907f4..8ae9edf6c 100644
--- a/m4/jm-macros.m4
+++ b/m4/jm-macros.m4
@@ -1,4 +1,4 @@
-#serial 113 -*- autoconf -*-
+#serial 114 -*- autoconf -*-
dnl Misc type-related macros for coreutils.
@@ -164,7 +164,7 @@ AC_DEFUN([coreutils_MACROS],
[[#include
]],
[[#ifdef __i386__
- fpsetprec(FP_PE);
+ fpsetprec (FP_PE);
#else
# error not required on 64 bit
#endif
diff --git a/src/dd.c b/src/dd.c
index fc5108f8b..06be4b04e 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -1037,7 +1037,7 @@ quit (int code)
}
/* Return LEN rounded down to a multiple of IO_BUFSIZE
- (to minimize calls to the expensive posix_fadvise(,POSIX_FADV_DONTNEED),
+ (to minimize calls to the expensive posix_fadvise (,POSIX_FADV_DONTNEED),
while storing the remainder internally per FD.
Pass LEN == 0 to get the current remainder. */
diff --git a/src/expand.c b/src/expand.c
index dd9d2981a..4e32bfcbb 100644
--- a/src/expand.c
+++ b/src/expand.c
@@ -227,7 +227,7 @@ main (int argc, char **argv)
finalize_tab_stops ();
- set_file_list ( (optind < argc) ? &argv[optind] : NULL);
+ set_file_list ((optind < argc) ? &argv[optind] : NULL);
expand ();
diff --git a/src/factor.c b/src/factor.c
index d1a6bb8e7..62a269fcf 100644
--- a/src/factor.c
+++ b/src/factor.c
@@ -265,10 +265,10 @@ static void factor (uintmax_t, uintmax_t, struct factors *);
__x2 = (uintmax_t) __uh * __vl;
