Closing it as dead as last message was from over a year ago.

On Wed, Apr 28, 2010 at 09:49:56PM +0000, Ulrich Dangel wrote:

> On Wednesday 28 April 2010 23:07:39 Andras Korn wrote:
> > Well, fwiw, grml already has such wrappers (this is one of the things that
> > make it appealing). For example, ls is by default aliased to:
> > 
> > ls='ls -b -CF --color=auto'
> > 
> > I don't see how this is any different.
> 
> It is different as it only changes the default parameters for a program. 
> In your case you putting the output from df trough column and sed.
> 
> And in addtion the sed command is only useful with the english locale and not 
> any other like for example german http://nopaste.narf.at/show/24/

Yes, I agree that the locale dependency is a con.

> > But I'd be happy with DF() instead of df() if you really think modifying
> > ls(1) is OK but modifying df(1) isn't. :)
> 
> Yes as the alias only adds additional parameters.

That, however, is irrelevant - it changes the behaviour of the utility, and
that's it. :)

But OK, the locale thing convinced me; it'd be possible to make it work with
any locale, but only with a disproportional amount of work.

So, any objections to supplying it as DF()?

-- 
 Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
           Bachelor: A guy who has cheated a woman out of a divorce.

On Wednesday 28 April 2010 23:07:39 Andras Korn wrote:
> Well, fwiw, grml already has such wrappers (this is one of the things that
> make it appealing). For example, ls is by default aliased to:
> 
> ls='ls -b -CF --color=auto'
> 
> I don't see how this is any different.

It is different as it only changes the default parameters for a program. 
In your case you putting the output from df trough column and sed.

And in addtion the sed command is only useful with the english locale and not 
any other like for example german http://nopaste.narf.at/show/24/

> But I'd be happy with DF() instead of df() if you really think modifying
> ls(1) is OK but modifying df(1) isn't. :)

Yes as the alias only adds additional parameters.

Ulrich

On Wed, Apr 28, 2010 at 08:32:07PM +0000, Frank Terbeck wrote:

> I've been asked to comment on this, so here goes:
> I am firmly against adding a wrapper around something that works,
> which requires a certain implementation of the given command and
> only works in certain scenarios (e.g. in a certain locale). And
> especially when its only purpose is to correct some cosmetic
> issues (if you'd even call it an issue).
> 
> Feel free to add this to your .zshrc.local file. IMO, this issue
> should be marked wont-fix for the reasons I gave earlier. (Unless,
> of course, I'm out-voted by a large number of fellow grml-developers.)

Well, fwiw, grml already has such wrappers (this is one of the things that
make it appealing). For example, ls is by default aliased to:

ls='ls -b -CF --color=auto'

I don't see how this is any different.

But I'd be happy with DF() instead of df() if you really think modifying
ls(1) is OK but modifying df(1) isn't. :)

-- 
 Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
                Energizer Bunny arrested. Charged with battery.

Hey there,

I've been asked to comment on this, so here goes:
I am firmly against adding a wrapper around something that works,
which requires a certain implementation of the given command and
only works in certain scenarios (e.g. in a certain locale). And
especially when its only purpose is to correct some cosmetic
issues (if you'd even call it an issue).

Feel free to add this to your .zshrc.local file. IMO, this issue
should be marked wont-fix for the reasons I gave earlier. (Unless,
of course, I'm out-voted by a large number of fellow grml-developers.)

Regards, Frank

On Mon, Apr 26, 2010 at 04:26:40PM +0000, Michael Prokop wrote:

> I like the idea but don't think changing behaviour of traditional
> UNIX commands is a good idea.

So what about the aliases for grep, ls and dir? :)

Like I said, it only alters the behaviour of df in interactive shells.
Normally I'd agree with you, but given this constraint, I don't see the
problem.

> Though I'd ACK this function under a different name, suggestions welcome.

DF() comes to mind as a cheap replacement. But I'd still prefer df()... Is
there an effortless way to poll users about it?

Andras

-- 
 Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/>
           Television is a medium, being neither rare nor well done.

* Andras Korn wrote in grml's BTS on 20100423 / 18:27:

> please consider including this in your zshrc:

> function df() {
> 	/bin/df -a --portability "$@" | column -t | sed
> 's/Mounted[[:space:]]*on/Mounted on/'
> }

> This makes df output a lot more readable by making sure that all information for
> each filesystem is on a single line and still nicely tabulated.

> Observe the difference between the old and new behaviour:
[...]

> Including the -a (which causes "dummy" filesystems to be included) is useful
> especially for chroots and vservers with bind mounted filesystems; if /etc/mtab
> includes an entry where the device doesn't exist, df will by default skip that
> entry in the output, which is the wrong thing to do for bind mounts. I don't
> think there are so many actual dummy filesystems that their inclusion would
> seriously clutter the output of df.

> Placing this function in zshrc would ensure that it's only loaded for
> interactive shells; thus it wouldn't interfere with scripts that attempt to
> parse the output of df(1).

I like the idea but don't think changing behaviour of traditional
UNIX commands is a good idea. Though I'd ACK this function under a
different name, suggestions welcome. :)

regards,
-mika-

Hi,

please consider including this in your zshrc:

function df() {
	/bin/df -a --portability "$@" | column -t | sed
's/Mounted[[:space:]]*on/Mounted on/'
}

This makes df output a lot more readable by making sure that all information for
each filesystem is on a single line and still nicely tabulated.

Observe the difference between the old and new behaviour:

Old:

Filesystem            Size  Used Avail Use% Mounted on
/dev/md0              254M  170M   85M  67% /
tmpfs                 3.9G     0  3.9G   0% /lib/init/rw
udev                   10M  516K  9.5M   6% /dev
tmpfs                 3.9G  2.4M  3.9G   1% /dev/shm
/dev/mapper/unencrypted-tmp
                      1.1G  164M  951M  15% /tmp
/dev/mapper/unencrypted-usr
                      1.8G  757M  1.1G  42% /usr
/dev/mapper/unencrypted-var
                     1014M  162M  853M  16% /var
/dev/mapper/unencrypted-var_log_sv
                      124M   40M   85M  32% /var/log/sv
/dev/mapper/unencrypted-var_cache_apt
                      764M  433M  331M  57% /shared/var_cache_apt
/dev/mapper/encrypted-netflow
                      2.0G  2.0G   67M  97% /var/spool/netflow

New:

Filesystem                               Size   Used  Avail  Use%  Mounted on
/dev/md0                                 254M   170M  85M    67%   /
tmpfs                                    3.9G   0     3.9G   0%    /lib/init/rw
udev                                     10M    516K  9.5M   6%    /dev
tmpfs                                    3.9G   2.4M  3.9G   1%    /dev/shm
/dev/mapper/unencrypted-tmp              1.1G   164M  951M   15%   /tmp
/dev/mapper/unencrypted-usr              1.8G   757M  1.1G   42%   /usr
/dev/mapper/unencrypted-var              1014M  162M  853M   16%   /var
/dev/mapper/unencrypted-var_log_sv       124M   40M   85M    32%   /var/log/sv
/dev/mapper/unencrypted-var_cache_apt    764M   433M  331M   57%  
/shared/var_cache_apt
/dev/mapper/encrypted-netflow            2.0G   2.0G  67M    97%  
/var/spool/netflow

Including the -a (which causes "dummy" filesystems to be included) is useful
especially for chroots and vservers with bind mounted filesystems; if /etc/mtab
includes an entry where the device doesn't exist, df will by default skip that
entry in the output, which is the wrong thing to do for bind mounts. I don't
think there are so many actual dummy filesystems that their inclusion would
seriously clutter the output of df.

Placing this function in zshrc would ensure that it's only loaded for
interactive shells; thus it wouldn't interfere with scripts that attempt to
parse the output of df(1).