bug#41622: [PATCH] tests: Change gnulib commit to compile make check
When I ran make check after building the master branch commit aefd434e, I got a compilation error. test-explicit_bzero.c:132:1: error: no previous declaration for 'do_secret_stuff' [-Werror=missing-declarations] 132 | do_secret_stuff (volatile int pass) | ^~~ test-explicit_bzero.c:148:1: error: no previous declaration for 'test_stack' [-Werror=missing-declarations] 148 | test_stack (void) | ^~ I noticed the gnulib repo had a detached HEAD at b3c04ecec. I tried switching the gnulib repo to master and running make check again. I got a different error. test-sameacls.c: In function 'main': test-sameacls.c:58:17: error: too many arguments to function 'read_file' 58 | contents1 = read_file (file1, 0, ); | ^ In file included from test-sameacls.c:36: ../lib/read-file.h:29:14: note: declared here 29 | extern char *read_file (const char *filename, size_t * length); | ^ test-sameacls.c:65:17: error: too many arguments to function 'read_file' 65 | contents2 = read_file (file2, 0, ); | ^ In file included from test-sameacls.c:36: ../lib/read-file.h:29:14: note: declared here 29 | extern char *read_file (const char *filename, size_t * length); | ^ Here, coreutils and gnulib having conflicting declarations of read_file and the wrong one is included. This may require future changes. Poking around in the git logs for gnulib, I found commit a305580f, which fixes the first problem before introducing the second. File test-explicit_bzero.c now declares do_secret_stuff and test_stack static to appease -Werror=missing-declarations. --- gnulib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnulib b/gnulib index b3c04ecec..a305580f0 16 --- a/gnulib +++ b/gnulib @@ -1 +1 @@ -Subproject commit b3c04ecec58ea687423f5c709410e6ecee4abd9b +Subproject commit a305580f09ada2674c0509389b1674c7b32dce67 -- 2.26.2
bug#37702: Suggestion for 'df' utility
On 5/30/20 4:49 AM, Erik Auerswald wrote: > I concur that a command line option to override config file (or env var) > settings seems useful if a config file and/or env var approach is used. In other utilities we've been moving away from environment variables and/or config files for the usual security and other-hassle reasons. So I'd prefer having 'df' just do the "right" thing by default, and to have an option to override that. The "right" thing should be to ignore all these pseudofilesystems that hardly anybody cares about.
bug#37702: Suggestion for 'df' utility
Hi all, On 30.05.20 05:18, Bryce Harrington wrote: On Fri, Oct 11, 2019 at 12:56:20PM -0700, Paul Eggert wrote: On 10/11/19 11:20 AM, Pádraig Brady wrote: if you want to exclude nested file systems like that, you could try: alias df='df -x squashfs' On my Fedora 30 workstation that option doesn't make any difference. Regardless of whether '-x squashfs' is used, I see this output from 'df': Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 4065704 04065704 0% /dev tmpfs 4081560 366164044944 1% /dev/shm tmpfs 4081560 16964079864 1% /run tmpfs 4081560 04081560 0% /sys/fs/cgroup /dev/sda559614116 16910684 39645412 30% / tmpfs 4081560 1244081436 1% /tmp /dev/sda2 1849433716 207781976 1547682948 12% /home /dev/sda1 50950402444684572044 6% /boot tmpfs 81631260 816252 1% /run/user/1000 and most of these lines are useless. In the above example, it seems useful to exclude tmpfs as well: alias df='df -x tmpfs -x squashfs' That does remove the "useless" lines from df output on my Ubuntu 18.04 system, to be concrete. What I do not like about this approach is the lack of an "unexclude" option to add an excluded filesystem back in. One could, e.g., use \df to not use the alias, or use a different name for the alias (e.g., dfx), though. I do remember a time when at least some distributions by default used tmpfs for /tmp. In that situation just this tmpfs filesystem should probably not be excluded from the default df output. For many years we've put up with the problem of too many filesystems in the default plain 'df' output, and now's as good a time as any to fix that. [...] We can add a flag or two for the rare people who want to see these normally-useless lines. [...] I'd like to help in fixing this issue. [...] I've taken a stab at a proof-of-concept implementation of #3, by adding an environment variable DF_EXCLUDE_FSTYPES. [...] > Further, even with a config file users would probably want a cli switch and/or env var to override the config file settings. I concur that a command line option to override config file (or env var) settings seems useful if a config file and/or env var approach is used. Just as it seems useful to me to allow unsuppressing of output that has been suppressed as useless by a possible new df default behavior. HTH, Erik
bug#41518: Bug in od?
On Mai 29 2020, Yuan Cao wrote: > It just feels strange because the order does not reflect the order of the > characters in the file. But that's not true. It reflects exactly how 2-byte numbers are stored in memory on your system. If you want to make a connection with characters, you need to think about UCS-2 characters. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
