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

[Paul Eggert]

"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.

> 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.


> 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.