coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] df: Adding a --no-headers option, by request of Bruce Dubbs


From: Assaf Gordon
Subject: Re: [PATCH] df: Adding a --no-headers option, by request of Bruce Dubbs
Date: Thu, 21 Mar 2019 11:32:42 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

Hello,

On 2019-03-21 4:13 a.m., Erik Auerswald wrote:

More general, table headers are useful for interactive use, but often need
to be ignored when the tool output is used programmatically.

That is a very good point.

Note that Bruce's original request[1] was to have a way
to get the number of used blocks programmatically
(I assume for scripting).

[1] https://lists.gnu.org/r/coreutils/2019-03/msg00048.html

While 'df' was always geared towards interactive use
(e.g. the POSIX specification[2] explicitly set the header line,
and the output columns, with "-P" and "-t" option to control the
output).

[2] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/df.html

For example, if you specify multiple fields, 'df' takes the extra effort
to right-align and space-pad the output - that's for interactive use / human consumption, not scripting.


Since the OP's goal was for scripting, perhaps it's good to take a step
back and consider whether other tools could provide better solutions:

stat(1) have this filesystem information, and allows explicit control
of the output.

For example, to get the number of used kilobytes on the system:

  USED=$(stat -f . -c "%s*(%b-%f)/1024" $PWD | bc)

While it's not shorter (because stat(1) doesn't have 'used blocks'
operand and uses blocks instead of kilobytes), it allows might tighter
control of the output.
(perhaps that's a reason to add 'used' operand to stat(1) and/or output
in bytes instead of blocks, but that's a different topic).

also:

On Wed, Mar 20, 2019 at 02:22:42PM -0700, Kaz Kylheku (Coreutils)
wrote:
[...]
"df --no-h" would suffice, use half the processes of the above,
avoid generating data that is read, ignored, and deleted, and avoid
the additional data copies needed to process the data (i.e. do
nothing) in sed. ;-)
These are valid upsides, and Eric nicely explains the downsides [3].
[3] https://lists.gnu.org/r/coreutils/2019-03/msg00049.html

A user who is familiar with "|sed 1d" or "|tail +2" will be know
how to remove headers from any program,  without the need
to learn how to disable headers specifically for each program (compare
'ps' vs 'lsblk' vs '--no-header' vs '--terse').


There's additional cost to adding such options: development and maintenance.

For example, several programs in the util-linux package [4]
(like lsblk, findmnt, lsns, lsmem) have dual role as both interactive
and scriptable programs.
The output formatting code is complicated enough that they created a
dedicated library just for that: libsmartcol [5].

[4] https://github.com/karelzak/util-linux
[5] https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.33/libsmartcols-docs/

In fact, "findmnt" is so versatile in its output options,
you might want to use it:

   UESD=$(findmnt -T $PWD --noheadings --output=USED --bytes)


regards,
 - assaf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]