On Thursday 01 March 2007 11:33, Paul Eggert wrote: > "Peter D." <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
