Re: Should "df --portability" allow thousands separators?

[Peter D.]

On Tuesday 27 February 2007 00:24, Jim Meyering wrote:
> Paul Eggert <address@hidden> wrote:
> > "Peter D." <address@hidden> writes:
> >> I am sufficiently ignorant of POSIX that df could be in completely
> >> compliant and I would not know.
> >
> > It does conform, since you're in an en_US.UTF-8 locale, not the POSIX
> > locale.  Also, POSIX reserves environment variables like BLOCK_SIZE to
> > the implementation; portable POSIX applications are not allowed to set
> > them.

We could interpret "not allowed to set" as "do not change, but 
feel free to ignore".  

> > That being said, it might make sense for -P to ignore BLOCK_SIZE and
> > the like.  Doing this wouldn't be 100% trivial, though; someone will
> > have to think about it.

I'm not offering any code, but I am trying to think.  ;-)  

> It looks like GNU df should ignore at least some part of BLOCK_SIZE,
> since POSIX requires df -P to report "quantities expressed in
> 512-byte units (1024-byte when -k is specified)".

Perhaps BLOCK_SIZE=1k is the only value that should not be ignored, 
and BLOCK_SIZE='1k should be half ignored.  

> Here are some additional requirements:
>
>     These lines shall be formatted as follows:
>       "%s %d %d %d %d%% %s\n", <file system name>, <total space>,
>       <space used>, <space free>, <percentage used>,
>       <file system root>

Is there a POSIX definition of "%d"?  

> That suggests printing thousands separators for -P is not permitted.
>
> I think that it makes sense to allow selecting 512 vs 1024 via the
> environment variable or command line option.  However, all other
> attributes must be ignored.
>
> I've included a patch below that makes this fail:

DANGER!  

There is a tradition of aiming for strict control of output while 
being generous about input.  It tends to make the whole thing more 
robust.  

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.  

>     $ LC_ALL=en_US BLOCK_SIZE="'1G" ./df -P /t
>     ./df: a block size of 1073741824 conflicts with -P
>     [Exit 1]

Send that to standard error, give a non-zero exit value, but 
print the results for 512 byte block size (because 1k was 
not specified) to standard out.  

> Before, it would do this:
>
>     $ LC_ALL=en_US BLOCK_SIZE="'1k" /bin/df -P /t
>     Filesystem         1024-blocks      Used Available Capacity Mounted
> on tmpfs                1,249,280   547,312   701,968      44% /t
>
> but with "'1k", the new version just ignores the request for
> thousands separators:
>
>     $ LC_ALL=en_US BLOCK_SIZE="'1k" ./df -P /t
>     Filesystem         1024-blocks      Used Available Capacity Mounted
> on tmpfs                  1249280    547312    701968      44% /t

That looks sensible.  Would you like to send "thousands separator 
ignored" to standard error?  


> diff --git a/src/df.c b/src/df.c
> index 8bc4a84..cf264b5 100644
> --- a/src/df.c
> +++ b/src/df.c
> @@ -876,6 +876,19 @@ main (int argc, char **argv)
>       }
>      }
>
> +  if (posix_format)
> +    {
> +      if (output_block_size != 512 && output_block_size != 1024)
> +     {
> +       char buf[MAX (LONGEST_HUMAN_READABLE + 1,
> +                     INT_BUFSIZE_BOUND (uintmax_t))];
> +       error (EXIT_FAILURE, 0,
> +              _("a block size of %s conflicts with -P"),
> +              umaxtostr (output_block_size, buf));
> +     }
> +      human_output_opts = 0;
> +    }
> +
>    /* Fail if the same file system type was both selected and excluded. 
> */ {
>      bool match = false;
>
>
> _______________________________________________
> Bug-coreutils mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-coreutils


-- 
sig goes here...
Peter D.