So to sum up the -g option;

* It's new and not used on Solaris / GNU, which doesn't make it
portable to these.  Although, if you're doing a script that must be
portable, you always have to check if the option(s) is available on
the targets, which doesn't make this a problem really.  BLOCKSIZE can
always be used to make sure it works over different unices.

* It won't interfere with other unices since they don't have this
option. Well, until they add -g to do something else.  Then we would
be facing the same problem like "ls -g" on different unices.

* Makes sense since we have -m.  And -h is not enough.

* Well, you do not have to calculate/set BLOCKSIZE, of course.


Well, I guess -g *could* also be used on df(1), but Solaris for example,
uses df -g to print the entire statvfs(2) structure.

A terabyte option, -t would cause problem with df(1) too, -t is used on
both Solaris and NetBSD already.

So, perhaps there's too much problems/collisions with all this...


Regards,
Mattias

gabriel rosenkoetter wrote:
> On Tue, Feb 18, 2003 at 06:09:29PM +0100, Johan Danielsson wrote:
> 
>>gabriel rosenkoetter <gr@eclipsed.net> writes:
>>
>>
>>>Well, okay, then. Guess it's time to rototill my userland.
>>
>>The question remains. Why do we need -g if we have -h? Shouldn't there
>>be -t, -p, -e, -z also?
> 
> 
> We haven't come up on needing those yet. I don't think any of our
> file systems would deal so well above the range of -t, at this
> moment, and adding those later is fairly painless.
> 
> We need -g because the output of -h isn't sort(1)able. Arguably,
> -k's enough for that, but we've already got -m, so -g makes sense.
> 

-- 
Mattias Karlsson
mattias.karlsson@sergei.cc
SysAdm - http://www.sergei.cc/