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

[Peter D.]

On Wednesday 28 February 2007 04:50, Paul Eggert wrote:
> "Peter D." <address@hidden> writes:
> > When an inconsistent set of environment variables and command
> > line options is given then sending a polite informative version
> > of "programming error" to standard error is useful.  However,
> > sending most sensible output to standard out will cause the
> > least grief.
>
> 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.".  

> Also, it 
> seems confusing to pay attention to part of an environment variable,
> but ignore the rest.

True, but it is common practice to make the best of silly 
combinations of command line parameters, typically later 
options override earlier ones.  Sometimes there is a defined 
order of precedence, see below.  

> How about using the following rule instead?
>
>    If -P is used, ignore the DF_BLOCK_SIZE, BLOCK_SIZE, and BLOCKSIZE
>    environment variables.

My sightly old man and info pages state that the environment 
variable POSIXLY_CORRECT has the lowest priority, which is 
overridden in turn by BLOCKSIZE, BLOCK_SIZE, DF_BLOCK_SIZE 
and an explicit command line option of --block-size=SIZE and 
its equivalents.  

So the order is; 
POSIXLY_CORRECT,
BLOCKSIZE, 
BLOCK_SIZE, 
DF_BLOCK_SIZE, 
( -P, --portability), 
( -B, --block-size=SIZE, -h, --human-readable, -H, --si, -k) ?

> This is easier to document and understand (at least for me....).
>
> Here's a proposed patch to do that.
>
> A more-radical option would be to also ignore POSIXLY_CORRECT if -P is
> specified: i.e., the default block size is 512 if -P is used.  This
> would be more "in the spirit of POSIX" but would be less compatible
> with existing GNU practice.

I'm lost now.  

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?  

[big snip]

-- 
sig goes here...
Peter D.