Description of problem: Description sort(1) in coreutils 8.24 has an OPTION to check for strict ordering. -u, --unique with -c, check for strict ordering; without -c, output only the first of an equal run However, df(1) in coreutils 8.24 has no OPTION to check for strict ordering. This is inconsistent considering both df and sort reside in same coreutils package, and generated df output can contain duplicates. Feature Request: The df utility should support strict ordering OPTION (-u). Version-Release number of selected component (if applicable): coreutils-8.24, How reproducible: Always Steps to Reproduce: 1. # cd / 2. Execute these commands: # df * # df /* # df bin lib lib64 sbin 3. Execute these commands: # cd / # df --totals * # df --totals /l* # df --totals bin lib lib64 sbin Expected results: N/A Additional info:
Example of non intuitive output for directory containing 7 files. 7423bfmp:~/workspace/ISO\ ]$ df * --total Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / total 1141084476 967266188 115692976 90% -
Thanks for both BZs, I can see why you request this, but can you please clarify "expected results" so we can prevent possible confusion? In addition, as this is not something what should be solved downstream, I think it would be best to bring this up on upstream mailing list - to see what the upstream community thinks about this enhancement. Can you please send an email about this - either to coreutils or to bug-coreutils (the bugs-coreutils email will automatically create a ticket in bug tracking system? They may have some additional questions and having me as "man in the middle" can slow the things and discussion.
I emailed coreutils asking for comments. The current situation is as follows: 7423bfmp:~/workspace/ISO\ ]$ df * --total Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / total 1141084476 967266188 115692976 90% - IMHO, the desired situation is as follows: 7423bfmp:~/workspace/ISO\ ]$ df * --total -u Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/my_vg-root 163012068 138180884 16527568 90% / total 163012068 138180884 16527568 90% - thanks, Noel
** The only feedback from coreutils is from Bernhard Voelker *** I'm not too enthusiastic for such an option. This is the first time I've seen someone doing "df *". Although it doesn't seem to be explicitly specified by POSIX, I'd assume a consistent behavior like many other tools which do their job for each command line argument regardless whether it may make sense (stat, du) or maybe not (df, dirname). Furthermore, since the introduction of the output field 'file', it really makes sense to not unify the output: $ df -h --out=source,target,file df du mv Filesystem Mounted on File /dev/sda5 /media/big_data df /dev/sda5 /media/big_data du /dev/sda5 /media/big_data mv A --unique option would clash with this output format. Finally, I'm not sure if everyone is aware that also regular files can be a mount point (admittedly, the output of 'findmnt' is a little more useful in this case): $ touch a b c $ mount --bind /proc/cpuinfo b $ mount --bind /sys/kernel/notes c $ df -h a b c Filesystem Size Used Avail Use% Mounted on /dev/sda2 20G 14G 5.2G 73% / proc 0 0 0 - /root/tmp/b sysfs 0 0 0 - /root/tmp/c Still, when 2 lines are really identical (because they are on the same file system and not mounted over), it may be valid to squeeze the output, but I don't think this is following the principle of least suprise: someone might be confused why some lines are missing ... or even relying on that in a script. Anyway, one may simply do that with "... | sort -u" if needed. Have a nice day, Berny
I would also note the inconsistency between df and sort when invoked with "*". # pwd /usr/share # sort * | wc -l sort: read failed: abrt: Is a directory 0 # df -l * | wc -l 233
Due to lack of consensus, I think no action will be taken downstream. Still .. it is open to Linux distribution vendors to consider updating the df(1) man page to explain how '*' globbing can produce output which may not make sense (df * --total) or need further processing (df *) to remove duplicates.
Thanks for bringing it to upstream. Yes, I don't expect this implemented downstream only. Keeping opened for now so we can later come up with some documentation adjustment. Please note that will likely be only adjustment to info documentation , man pages in coreutils are intended to be compact.
Running 'df *' does not make any sense in most of the cases. Did not you want to run 'du *' instead?
Hi Kamil, Thanks for comment. Yes, "du *" is better user space choice, but this BZ is a comment on df behaviour in this case, not choices. However, I would recommend your comment is taken on board in df info-docs. i.e. --- Output from "df *" may be non intuitive. Consider "du *" instead. ---
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
In my opinion, the output of "df *" is not non-intuitive. It is just useless in most of the cases. I am not sure how the info documentation could be improved. You are welcome to send a proposal to the bug-coreutils mailing list.