[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should "df --portability" allow thousands separators?
From: |
Peter D. |
Subject: |
Re: Should "df --portability" allow thousands separators? |
Date: |
Tue, 27 Feb 2007 11:17:47 +1100 |
User-agent: |
KMail/1.9.4 |
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.
- Should "df --portability" allow thousands separators?, Peter D., 2007/02/24
- Re: Should "df --portability" allow thousands separators?, Paul Eggert, 2007/02/25
- Re: Should "df --portability" allow thousands separators?, Peter D., 2007/02/26
- Re: Should "df --portability" allow thousands separators?, Paul Eggert, 2007/02/26
- Re: Should "df --portability" allow thousands separators?, Peter D., 2007/02/26
- Re: Should "df --portability" allow thousands separators?, Jim Meyering, 2007/02/26
- Re: Should "df --portability" allow thousands separators?,
Peter D. <=
- Re: Should "df --portability" allow thousands separators?, Paul Eggert, 2007/02/27
- Re: Should "df --portability" allow thousands separators?, Jim Meyering, 2007/02/27
- Re: Should "df --portability" allow thousands separators?, Peter D., 2007/02/28
- Re: Should "df --portability" allow thousands separators?, Paul Eggert, 2007/02/28