[Top][All Lists]
[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: |
Wed, 28 Feb 2007 23:44:15 +1100 |
User-agent: |
KMail/1.9.4 |
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.
- Should "df --portability" allow thousands separators?, Peter D., 2007/02/24
- Re: Should "df --portability" allow thousands separators?, Paul Eggert, 2007/02/25
- Re: Should "df --portability" allow thousands separators?, Peter D., 2007/02/26
- Re: Should "df --portability" allow thousands separators?, Paul Eggert, 2007/02/26
- Re: Should "df --portability" allow thousands separators?, Peter D., 2007/02/26
- Re: Should "df --portability" allow thousands separators?, Jim Meyering, 2007/02/26
- Re: Should "df --portability" allow thousands separators?, Peter D., 2007/02/26
- Re: Should "df --portability" allow thousands separators?, Paul Eggert, 2007/02/27
- Re: Should "df --portability" allow thousands separators?, Jim Meyering, 2007/02/27
- Re: Should "df --portability" allow thousands separators?,
Peter D. <=
- Re: Should "df --portability" allow thousands separators?, Paul Eggert, 2007/02/28