bug-coreutils
[Top][All Lists]
Advanced

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

Re: Should "df --portability" allow thousands separators?


From: Peter D.
Subject: Re: Should "df --portability" allow thousands separators?
Date: Fri, 2 Mar 2007 12:09:34 +1100
User-agent: KMail/1.9.4

On Thursday 01 March 2007 11:33, Paul Eggert wrote:
> "Peter D." <address@hidden> writes:
> >> I also would prefer avoiding a diagnostic if possible.
> >
> > Not even for an intermediate version that says, "That used to
> > work.  It doesn't any more.  Future versions won't even give
> > you this message.".
>
> Yes, I'd prefer to avoid a diagnostic like that too, if we can.
> Diagnostics may be needed in some cases, but we should strive to make
> those cases rare.

I thought that you were going to change df's behavior such that it 
would break a lot of existing code.  That is looking much less 
likely now.  There is much less need to explain why things are 
broken when they are not actually broken.  

> > So the order is;
> > POSIXLY_CORRECT,
> > BLOCKSIZE,
> > BLOCK_SIZE,
> > DF_BLOCK_SIZE,
> > ( -P, --portability),
> > ( -B, --block-size=SIZE, -h, --human-readable, -H, --si, -k) ?
>
> Yes and no.  -P causes BLOCKSIZE, BLOCK_SIZE, and DF_BLOCK_SIZE to
> be ignored.  So it doesn't really override them: it causes them
> to behave as if they weren't there.  Hence if -P is specified, the
> order is POSIXLY_CORRECT, and then -B and the other options.

I'm just trying to satisfy myself that the behavior is both sane 
and consistent with the man and info pages.  I'm satisfied.  

> > Should "-P" give 1k blocks (without thousands separators), unless
> > POSIXLY_CORRECT sets it to 512 (where POSIXLY_CORRECT is a simple
> > flag that can not possibly activate thousands separators), or a
> > command line option (which can activate thousands separators)
> > overrides both?
>
> Yes, that's the intent of the current situtation.
>
> An alternative would be for -P to also cause POSIXLY_CORRECT to be
> ignored, so that with -P the block size defaults to 512 regardless of
> whether POSIXLY_CORRECT is set.  However, this would be a bigger
> change and I worry that it would break existing uses.

I think that that change would also require a change to the 
documentation.  

I'm happy now.  

Thank you.  


-- 
sig goes here...
Peter D.




reply via email to

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