bug#33785: df: don't suppress remote mounts
Hi list,
According to the following commit
commit 2e81e62243409c5c574b899f52b08c000e4d99fd
Author: Pádraig Brady
Date: Wed Oct 29 02:49:17 2014 +
df: only suppress remote mounts of separate exports with --total
...
diff --git a/NEWS b/NEWS
index 5d3bc58bd..2c7e590e0 100644
--- a/NEWS
+++ b/NEWS
@@ -32,6 +32,11 @@ GNU coreutils NEWS
-*- outline -*-
** Changes in behavior
+ df no longer suppresses separate exports of the same remote device, as
+ these are generally explicitly mounted. The --total option does still
+ suppress duplicate remote file systems.
+ [suppression was introduced in coreutils-8.21]
The remote mounts should not be suppressed after this change. However,
it turns out
it doesn't work as the message described. The remote mounts are still
suppressed. And here is
my patch for this problem:
1 From 72be959fc9f49420b07b4df5c5017821232cf498 Mon Sep 17 00:00:00 2001
2 From: Lidong Zhong
3 Date: Tue, 18 Dec 2018 14:24:13 +0800
4 Subject: [PATCH] df: don't suppress remote mounts
5 MIME-Version: 1.0
6 Content-Type: text/plain; charset=UTF-8
7 Content-Transfer-Encoding: 8bit
8
9 This is the fix for the following commit.
10 commit 2e81e62243409c5c574b899f52b08c000e4d99fd
11 Author: Pádraig Brady
12 Date: Wed Oct 29 02:49:17 2014 +
13
14 df: only suppress remote mounts of separate exports with --total
15
16 It doesn't work as the commit message described. The remote mounts
17 are also suppressed after this change.
18 ---
19 src/df.c | 2 +-
20 1 file changed, 1 insertion(+), 1 deletion(-)
21
22 diff --git a/src/df.c b/src/df.c
23 index 55532219f..0246e3df9 100644
24 --- a/src/df.c
25 +++ b/src/df.c
26 @@ -722,7 +722,7 @@ filter_mount_list (bool devices_only)
27 < strlen (me->me_mntroot));
28 if (! print_grand_total
29 && me->me_remote && seen_dev->me->me_remote
30 - && ! STREQ (seen_dev->me->me_devname,
me->me_devname))
31 + && STREQ (seen_dev->me->me_devname, me->me_devname))
32 {
33 /* Don't discard remote entries with different
locations,
34 as these are more likely to be explicitly
mounted.
Please share your opinion.
Regards,
Lidong
bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior
Over the past few years I have has for the ability to set
defaults for my system regarding various behaviors in
coreutil programs. Some of the these behaviors have been
regulated via ENV vars in the past, but I was told that this
was not desirable as gnu was trying to get away from using
ENV vars to regulate a person's util behavior in their
environment. I suggested using a config file in /etc
as an alternative and was told "no way".
However, now I find that /etc/xattr.conf is being used to
regulate behavior in gnu tools.
Given the acceptance of such config files I would like
see a single file /etc/gnu.conf hold configs for any gnu
tool.
In it should be options for configuration by function
and tool, with tool-specific options overriding
function-specific options. An additional selector
should be if the behavior is configured for "interactive"
use vs. "script" use.
Now I suspect that people will want these options to be
configurable by user and not just at a system level -- so
ideally, there would be a '~/.gnurc' file for user overrides.
Examples of configurable items:
Default quoting and sorting
Default TAB expansion (both tab column and expansion to space)
Default aliases for existing long options.
Default algorithm usage (if using depth-first processing,
no pre-processing of names in non-depth-first order).
Default addition of optional path elements ("find" processing)
Default per-unit prefixes and their values.
The above should not be taken as a comprehensive list, but
as possible examples of included items.
Maybe I can go back and resubmit several bugs that would benefit
from this new policy?
L Walsh
bug#33786: Bug: undocumented feature (algorithm) for version-sort (include on manpage)
Recently there was some discussion on inconsistencies in how version sort worked and some people *basically*, said: "it's not our fault, it's Debian's algorithm, you wanna change it, convince them." Um...fine. Except that it is a Gnu tool, not a Debian tool, meaning that if one is going to put a Debian sort into a general purpose tool like "sort", then the algorithm really needs to be documented. This means there is no way to verify consistent behavior from as the utility matures and no way to write an independent, auditable test case to assure that the sort algorithm, operates with consistency from release to release as well as w/r/t other included sort algorithms. The request here is for the algorithm used by 'version-sort' be included in sort's manpage. This should document sort's features for reference and use by users who are using the utility in its native, cmd-line environment. Also of importance: that the documentation should be include with the source and installable with the program executable. thanks, linda
