Re: df & du should honor $BLOCKSIZE

[Peter Seebach]

In message <address@hidden>, Paul Eggert writes:
>As the 1998 change caused the environment variable to have the same
>interpretation as the "--block-size" long option, I thought it more
>consistent at the time to spell the environment variable "BLOCK_SIZE"
>rather than "BLOCKSIZE".

Makes sense.

>> It seems to me like it would be reasonable to use $BLOCKSIZE if
>> $BLOCK_SIZE isn't set, simply because it's widely used elsewhere.

>Something like that sounds reasonable, except what is BLOCKSIZE
>supposed to mean when it's widely used elsewhere?  Do you have a
>specification somewhere?  I couldn't find one.

The only spec I've found is in the environ(7) manpage on NetBSD, but all
of the BSDs seem to agree on it; they have a standard getbsize(3) which
does the dirty work.

     BLOCKSIZE        The size of the block units used by several commands,
                      most notably df(1), du(1) and ls(1).  BLOCKSIZE may be
                      specified in units of a byte by specifying a number, in
                      units of a kilobyte by specifying a number followed by
                      ``K'' or ``k'', in units of a megabyte by specifying a
                      number followed by ``M'' or ``m'' and in units of a
                      gigabyte by specifying a number followed by ``G'' or
                      ``g''.  Sizes less than 512 bytes or greater than a
                      gigabyte are ignored.

Note that weird values such as "1000000" work fine; this is arguably a feature
for hard drive vendors, I guess.
 
>It seems to me that "ls" etc. should ignore ridiculous settings like
>that, instead of having them be equivalent to BLOCK_SIZE=1024.  Does
>that sound right to you?  If so, I can prepare a patch.  (But this
>might be related to the issue of what BLOCKSIZE actually means on
>those other platforms.)

Well, the documented behavior for BLOCKSIZE on NetBSD is "if it's incoherent,
assume it's 512".  For GNU utilities, I wouldn't be surprised if the answer
were "if it's incoherent, use 512 if POSIXLY_CORRECT, and 1024 otherwise".

-s