On Wednesday 28 February 2007 04:50, Paul Eggert wrote: > "Peter D." <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
