"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. > 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
