[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: |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Should "df --portability" allow thousands separators?,
Peter D. <=