[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should "df --portability" allow thousands separators?
From: |
Jim Meyering |
Subject: |
Re: Should "df --portability" allow thousands separators? |
Date: |
Mon, 26 Feb 2007 14:24:15 +0100 |
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.
>
> 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.
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)".
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>
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:
$ LC_ALL=en_US BLOCK_SIZE="'1G" ./df -P /t
./df: a block size of 1073741824 conflicts with -P
[Exit 1]
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
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;
- 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 <=
- Re: Should "df --portability" allow thousands separators?, Peter D., 2007/02/26
- 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