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
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
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)
> > > >
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
> >---
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.
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
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
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?)
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
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
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
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
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
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
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
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),
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
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
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
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
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':
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' utility output is now quite jumbled
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 messy. My fairly normal system now
28 matches
Mail list logo
