On 10/4/21 13:31, Chris Murphy wrote:
Is the primary
target audience for human-readable values humans? Or scripts
Both.
Output columns are at a premium, so there is some advantage to omitting
the units suffix (plus a lot of tradition for omission, outside of
coreutils).
On Fri, Oct 1, 2021 at 12:19 PM Pádraig Brady wrote:
>
> On 01/10/2021 14:28, Danie de Jager wrote:
> > Hi,
> >
> > The output from df -h and df -H is always G or M. Depending on who sends me
> > usage stats I have to ask how the command was run to make sure I calculate
> > usage correctly. System
Hi Paul,
Thanks for your consideration. I understand your concern about causing
confusion with set aliases. In that case I agree, create a new option
instead.
Regards,
Danie
On Fri, 1 Oct 2021 at 23:01, Paul Eggert wrote:
> On 10/1/21 1:30 PM, Danie de Jager wrote:
> > Can we use the same opti
On 10/1/21 2:16 PM, Glenn Golden wrote:
Might it be possible to finesse the already existing envars (BLOCK_SIZE,
DF_BLOCK_SIZE, etc.) to accomplish the desired suffixing mods?
We've been moving away from using those environment variables, for
security and reproducibility reasons.
Paul Eggert [2021-10-01 14:01:14 -0700]:
>
> On 10/1/21 1:30 PM, Danie de Jager wrote:
> > Can we use the same options, but to trigger the longer annotation, we
> > double the characters used to -hh and -HH?
>
> Interesting idea. Normally, later options override earlier, so 'df -h -H' is
> equiv
On 10/1/21 1:30 PM, Danie de Jager wrote:
Can we use the same options, but to trigger the longer annotation, we
double the characters used to -hh and -HH?
Interesting idea. Normally, later options override earlier, so 'df -h
-H' is equivalent to 'df -H'. This is so that one can alias 'df' to '
Thank you for sharing. After reading I agree that changing
existing features could break processes for users.
It would be easy to make mistakes when in a hurry and looking at the
following output:
$ df -h | grep /$
/dev/nvme0n1p1 12G 8.5G 3.6G 71% /
$ df -H | grep /$
/dev/nvme0n1p1 13G 9.
On 10/1/21 6:28 AM, Danie de Jager wrote:
Systems like Amazon EC2 use the explicit GiB suffix.
Are you saying that Amazon EC2's 'df' utility behaves differently from
coreutils' 'df'? If so, could you send us documentation or source code
indicating exactly wha
Danie de Jager [2021-10-01 15:28:10 +0200]:
>
> The output from df -h and df -H is always G or M. Depending on who sends me
> usage stats I have to ask how the command was run to make sure I calculate
> usage correctly. Systems like Amazon EC2 use the explicit GiB suffix.
> Making it easier to kn
On 01/10/2021 14:28, Danie de Jager wrote:
Hi,
The output from df -h and df -H is always G or M. Depending on who sends me
usage stats I have to ask how the command was run to make sure I calculate
usage correctly. Systems like Amazon EC2 use the explicit GiB suffix.
Making it easier to know wha
Hi,
The output from df -h and df -H is always G or M. Depending on who sends me
usage stats I have to ask how the command was run to make sure I calculate
usage correctly. Systems like Amazon EC2 use the explicit GiB suffix.
Making it easier to know what sizes you are looking at.
Can a future rel
On Fri, Jul 10, 2020 at 04:29:21PM -0700, Bryce Harrington wrote:
> On Mon, Jun 01, 2020 at 09:26:14AM -0700, Bryce Harrington wrote:
> > On Mon, Jun 01, 2020 at 09:04:26AM -0700, Bryce Harrington wrote:
> > > On Sun, May 31, 2020 at 01:49:24PM +0100, Pádraig Brady wrote:
> > > > On 31/05/2020 10:3
On Mon, Jun 01, 2020 at 09:26:14AM -0700, Bryce Harrington wrote:
> On Mon, Jun 01, 2020 at 09:04:26AM -0700, Bryce Harrington wrote:
> > On Sun, May 31, 2020 at 01:49:24PM +0100, Pádraig Brady wrote:
> > > On 31/05/2020 10:36, Bernhard Voelker wrote:
> > > > What about to start with this?
> > > >
Paul Eggert wrote:
> 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.
+1! Which I thought I would say because often I am a status quo type
On Mon, Jun 01, 2020 at 09:04:26AM -0700, Bryce Harrington wrote:
> On Sun, May 31, 2020 at 01:49:24PM +0100, Pádraig Brady wrote:
> > On 31/05/2020 10:36, Bernhard Voelker wrote:
> > > What about to start with this?
> > >
> > >$ GIT_PAGER= git -C gnulib diff
> > >diff --git a/lib/mountlis
On Sun, May 31, 2020 at 01:49:24PM +0100, Pádraig Brady wrote:
> On 31/05/2020 10:36, Bernhard Voelker wrote:
> > On 2020-05-31 01:07, Paul Eggert wrote:
> > > 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
On Sunday, May 31, 2020 2:49:24 PM CEST Pádraig Brady wrote:
> On 31/05/2020 10:36, Bernhard Voelker wrote:
> > What about to start with this?
> >
> >$ GIT_PAGER= git -C gnulib diff
> >diff --git a/lib/mountlist.c b/lib/mountlist.c
> >index 7abe0248e..5f6249dec 100644
> >--- a/lib/
Hi John,
On Sun, May 31, 2020 at 06:52:04PM +1000, John Pye wrote:
> The purpose of "df" is to show "disk free". Hence any filesystems that
> are read-only or which are FUSE-mounted one on of the local physical
> filesystems, or similar things (what others?) should be suppressed by
> default.
The
On 31/05/2020 10:36, Bernhard Voelker wrote:
On 2020-05-31 01:07, Paul Eggert wrote:
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.
Just to mention anoth
On 2020-05-31 01:07, Paul Eggert wrote:
> 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.
Just to mention another alternative to control the behavior bes
Hi all
My vote would be on a "df -a" switch to revert to original behaviour of
visibility of all mounts.
The purpose of "df" is to show "disk free". Hence any filesystems that
are read-only or which are FUSE-mounted one on of the local physical
filesystems, or similar things (what others?) should
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 secu
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 opt
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.
On 2019/10/11 12:56, 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.
>
--
I'd sugges
On 10/14/19 1:01 AM, Kamil Dudka wrote:
This is not an excuse to introduce new problems.
I'm not looking for an "excuse". df (through no fault of its own) has
evolved into a bad program that needs fixing. Backward compatibility
concerns are real and we should take them into account, but they sh
On Monday, October 14, 2019 8:06:47 AM CEST Paul Eggert wrote:
> On 10/13/19 3:00 PM, Assaf Gordon wrote:
> > I'm not sure if it's easy to find a set of criteria
> > that would work well while having minimal unexpected side effects of
> > hiding
> > entries people in other systems do expect to see.
On 10/13/19 3:00 PM, Assaf Gordon wrote:
I'm not sure if it's easy to find a set of criteria
that would work well while having minimal unexpected side effects of hiding
entries people in other systems do expect to see.
No matter what we do (even if we do nothing), there will be problems. But
On 2019-10-14 00:13, Assaf Gordon wrote:
> Also in other systems where "/tmp" is a "tmpfs",
> users might want to see how much space is available.
>
> If we hide it by default, they can of course use "df /tmp"
> or "df --all" - it's not about removing this option,
> it is just about making users'
Hello Bernhard,
On 2019-10-13 3:57 p.m., Bernhard Voelker wrote:
On 2019-10-13 23:28, Paul Eggert wrote:
In any sane system there would be only
four lines of non-header output (for tmpfs etc, /, /home, and
/media/eggert/B827-D456), but df is outputting 28 lines.
What is so special about tmpfs
On 2019-10-13 3:28 p.m., Paul Eggert wrote:
[..]
I mean c'mon, here's the output of 'df' on the Ubuntu 18.04.3 LTS
workstation I'm typing this particular message on. In any sane system
there would be only four lines of non-header output (for tmpfs etc, /,
/home, and /media/eggert/B827-D456), bu
On 2019-10-13 23:28, Paul Eggert wrote:
> In any sane system there would be only
> four lines of non-header output (for tmpfs etc, /, /home, and
> /media/eggert/B827-D456), but df is outputting 28 lines.
What is so special about tmpfs so that you would like to see it?
Here on my openSUSE:Tumble
On 10/13/19 2:11 PM, Assaf Gordon wrote:
This thread originated by a request to "clean up" the output on newer
ubuntu machines which use "snap" packages as /dev/loopN .
Let's not turn that into a drastic change
It could certainly be multiple sets of patches. But let's face it, df's utility
f
Hi all,
On 2019-10-13 2:27 p.m., Paul Eggert wrote:
On 10/13/19 2:41 AM, Pádraig Brady wrote:
I wonder could we key (also) on used==0||available==0.
Yes, looking at the sample output I gave earlier, I'd say we could by
default drop filesystems where usage is 1% or less. That would solve the
On 10/13/19 2:41 AM, Pádraig Brady wrote:
I wonder could we key (also) on used==0||available==0.
Yes, looking at the sample output I gave earlier, I'd say we could by default
drop filesystems where usage is 1% or less. That would solve the problem for my
workstation. This is roughly akin to t
On 11/10/2019 20:56, 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 us
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':
Filesy
On 11/10/2019 08:55, John Pye wrote:
Hi there
I got this email address from the 'df' man page. Hope it's still active
and the right place for feedback.
With recent changes to Ubuntu and the increasing use of 'snap' packaging
for all sorts of things, the 'df'
Hi there
I got this email address from the 'df' man page. Hope it's still active
and the right place for feedback.
With recent changes to Ubuntu and the increasing use of 'snap' packaging
for all sorts of things, the 'df' utility output is now quite jumbled
and
Here you go -
~ # ls -l /etc/mtab
lrwxrwxrwx 1 root root 17 Oct 22 2014 /etc/mtab -> /proc/self/mounts
~ #
~ # cat /etc/mtab
devtmpfs /dev devtmpfs
rw,relatime,size=4021028k,nr_inodes=1005257,mode=755 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
tmpfs /run tmpfs rw,nosuid,nodev,relatime,mode=7
erbenton wrote:
> df: ‘/sys/kernel/debug/tracing’: Permission denied
>...
> Still the same issue, using df from a non-root account always
> results in permission denied warning which messes with scripts that
> use df. strace shows that even with -x debugfs or -x sysfs that df
> is still probing /s
On 08/07/15 22:57, erbenton wrote:
> df (GNU coreutils) 8.21
> OpenSuse 13.1
>
> ~>cd $HOME
> ~> df -x debugfs
> df: ‘/sys/kernel/debug/tracing’: Permission denied
Does `sudo df -T /sys/kernel/debug/tracing`
indicate another type to be filtering on?
thanks,
Pádraig.
df (GNU coreutils) 8.21
OpenSuse 13.1
~>cd $HOME
~> df -x debugfs
df: ‘/sys/kernel/debug/tracing’: Permission denied
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 4021028 16 4021012 1% /dev
tmpfs4034396 100 4034296 1% /dev/shm
tmpfs
tag 21011 notabug
close 21011
stop
On 08/07/15 09:39, erbenton wrote:
> Hi,
> The -x option of 'df' doesnt seem to work, when I exclude type sysfs it still
> includes it. I was trying to get around this annoying error using the -x
> option.
> e.g:
>> df
> df: ‘/sys/kernel/debug/tracing’: Permiss
Hi,
The -x option of 'df' doesnt seem to work, when I exclude type sysfs it
still includes it. I was trying to get around this annoying error using
the -x option.
e.g:
> df
df: ‘/sys/kernel/debug/tracing’: Permission denied
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs
Utility: df
Didn't know where to send these suggestions but two things that would be
nice...
1. Colour. Show different file system types (ie nfs) in a different
colour
2. Adjustable width. I have my screen width at about 142 characters
wide.That way the nfs mounts aren't taking up t
46 matches
Mail list logo
