Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
On Tuesday 02 September 2008 16:01:13 you wrote:
> Would you please amend/squash the patch below into your patch and
> adjust the line lengths of the log message to be <= 72, so that
> the generated ChangeLog lines don't wrap?
No problem, here is (I hope) complete patch. Also thanks for the regexp, it
was helpful for the AWK based test as well.
Kamil
From d402ecc9c1c1657cd5b213758968efd880364831 Mon Sep 17 00:00:00 2001
From: Kamil Dudka <[EMAIL PROTECTED]>
Date: Wed, 3 Sep 2008 10:33:06 +0200
Subject: [PATCH] df: new option: --total to produce grand total
* src/df.c (add_uint_with_neg_flag): New function to add two integral
values with separate negation flag.
(show_dev): New parameter force_fsu to display numbers directly. Collect
summary statistics on each printed device.
(usage): Mention new option --total in --help.
(main): Initialize summary on program start. Handle new option --total.
* tests/df/total: Dummy test case for new --total option.
* tests/df/total-awk: Better test case for new --total option (requires
awk).
* doc/coreutils.texi: Mention new parameter --total.
* NEWS: Mention the change.
* TODO: Removed completed task.
---
NEWS |3 ++
TODO |2 -
doc/coreutils.texi |7
src/df.c | 81
tests/Makefile.am |2 +
tests/check.mk |1 +
tests/df/total | 42 +++
tests/df/total-awk | 78 ++
8 files changed, 208 insertions(+), 8 deletions(-)
create mode 100755 tests/df/total
create mode 100755 tests/df/total-awk
diff --git a/NEWS b/NEWS
index 4979dd5..97e6313 100644
--- a/NEWS
+++ b/NEWS
@@ -42,6 +42,9 @@ GNU coreutils NEWS-*- outline -*-
sort accepts a new option --version-sort (-V, --sort=version),
specifying that ordering is to be based on strverscmp(3).
+ df accepts a new option --total, which produces a grand total of all
+ arguments after all arguments have been processed.
+
** Bug fixes
chcon --verbose now prints a newline after each message
diff --git a/TODO b/TODO
index c7b095c..c964933 100644
--- a/TODO
+++ b/TODO
@@ -66,8 +66,6 @@ Should printf '\0123' print "\n3"?
printf: consider adapting builtins/printf.def from bash
-df: add `--total' option, suggested here http://bugs.debian.org/186007
-
tail: don't use xlseek; it *exits*.
Instead, maybe use a macro and return nonzero.
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 3a04176..be59ae9 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -9692,6 +9692,13 @@ pseudo-file-systems, such as automounter entries.
Scale sizes by @var{size} before printing them (@pxref{Block size}).
For example, @option{-BG} prints sizes in units of 1,073,741,824 bytes.
[EMAIL PROTECTED] --total
[EMAIL PROTECTED] --total
[EMAIL PROTECTED] grand total of disk size, usage and available space
+Print a grand total of all arguments after all arguments have
+been processed. This can be used to find out the total disk size, usage
+and available space of all listed devices.
+
@optHumanReadable
@item -H
diff --git a/src/df.c b/src/df.c
index 0769a1e..0bb3b1e 100644
--- a/src/df.c
+++ b/src/df.c
@@ -108,6 +108,12 @@ static struct mount_entry *mount_list;
/* If true, print file system type as well. */
static bool print_type;
+/* If true, print a grand total at the end. */
+static bool print_grand_total;
+
+/* Grand total data. */
+static struct fs_usage grand_fsu;
+
/* For long options that have no equivalent short option, use a
non-character as a pseudo short option, starting with CHAR_MAX + 1. */
enum
@@ -129,6 +135,7 @@ static struct option const long_options[] =
{"print-type", no_argument, NULL, 'T'},
{"sync", no_argument, NULL, SYNC_OPTION},
{"no-sync", no_argument, NULL, NO_SYNC_OPTION},
+ {"total", no_argument, NULL, 'c'},
{"type", required_argument, NULL, 't'},
{"exclude-type", required_argument, NULL, 'x'},
{GETOPT_HELP_OPTION_DECL},
@@ -247,6 +254,41 @@ df_readable (bool negative, uintmax_t n, char *buf,
}
}
+/* Logical equivalence */
+#define LOG_EQ(a, b) (!(a) == !(b))
+
+/* Add integral value while using uintmax_t for value part and separate
+ negation flag. It adds value of SRC and SRC_NEG to DEST and DEST_NEG.
+ The result will be in DEST and DEST_NEG. See df_readable to understand
+ how the negation flag is used. */
+static void
+add_uint_with_neg_flag (uintmax_t *dest, bool *dest_neg,
+ uintmax_t src, bool src_neg)
+{
+ if (LOG_EQ (*dest_neg, src_neg))
+{
+ *dest += src;
+ return;
+}
+
+ if (*dest_neg)
+*dest = -*dest;
+
+ if (src_neg)
+src = -src;
+
+ if (src < *dest)
+*dest -= src;
+ else
+{
+ *dest = src - *dest;
+ *dest_neg = src_neg;
+}
+
+ if (*dest_neg)
+*dest = -*dest;
+}
+
/* Display a space listing for the disk device with absolute file name DISK.
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Kamil Dudka <[EMAIL PROTECTED]> writes:
> @@ -247,6 +254,41 @@ df_readable (bool negative, uintmax_t n, char *buf,
> }
> }
>
> +/* Logical equivalence */
> +#define LOG_EQ(a, b) (!(a) == !(b))
> +
> +/* Add integral value while using uintmax_t for value part and separate
> + negation flag. It adds value of SRC and SRC_NEG to DEST and DEST_NEG.
> + The result will be in DEST and DEST_NEG. See df_readable to understand
> + how the negation flag is used. */
> +static void
> +add_uint_with_neg_flag (uintmax_t *dest, bool *dest_neg,
> + uintmax_t src, bool src_neg)
> +{
> + if (LOG_EQ (*dest_neg, src_neg))
Since both arguments are already bool I see no need for LOG_EQ (it's the
only use anyway).
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
On Wednesday 03 September 2008 11:03:22 you wrote: > Kamil Dudka <[EMAIL PROTECTED]> writes: > Since both arguments are already bool I see no need for LOG_EQ (it's the > only use anyway). If you are using type bool, there is no guarantee there will be bool (0/1) value inside. It ca be (and mostly is) stored as a number in the memory, so there can be also other values. Kamil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Kamil Dudka <[EMAIL PROTECTED]> writes: > On Wednesday 03 September 2008 11:03:22 you wrote: >> Kamil Dudka <[EMAIL PROTECTED]> writes: >> Since both arguments are already bool I see no need for LOG_EQ (it's the >> only use anyway). > If you are using type bool, there is no guarantee there will be bool (0/1) > value inside. RTFS. It _is_ guaranteed. Even if bool != C99 _Bool. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Andreas Schwab <[EMAIL PROTECTED]> wrote: > Kamil Dudka <[EMAIL PROTECTED]> writes: >> On Wednesday 03 September 2008 11:03:22 you wrote: >>> Kamil Dudka <[EMAIL PROTECTED]> writes: >>> Since both arguments are already bool I see no need for LOG_EQ (it's the >>> only use anyway). >> If you are using type bool, there is no guarantee there will be bool (0/1) >> value inside. > > RTFS. It _is_ guaranteed. Even if bool != C99 _Bool. In general, when using gnulib's replacement via stdbool.in.h, the following comment from that file is relevant: /* Usage suggestions: Programs that use should be aware of some limitations and standards compliance issues. Standards compliance: - must be #included before 'bool', 'false', 'true' can be used. - You cannot assume that sizeof (bool) == 1. - Programs should not undefine the macros bool, true, and false, as C99 lists that as an "obsolescent feature". Limitations of this substitute, when used in a C89 environment: - must be #included before the '_Bool' type can be used. - You cannot assume that _Bool is a typedef; it might be a macro. - Bit-fields of type 'bool' are not supported. Portable code should use 'unsigned int foo : 1;' rather than 'bool foo : 1;'. >>- In C99, casts and automatic conversions to '_Bool' or 'bool' are >> performed in such a way that every nonzero value gets converted >> to 'true', and zero gets converted to 'false'. This doesn't work >> with this substitute. With this substitute, only the values 0 and 1 >> give the expected result when converted to _Bool' or 'bool'. Also, it is suggested that programs use 'bool' rather than '_Bool'; this isn't required, but 'bool' is more common. */ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
On Wednesday 03 September 2008 11:18:37 you wrote: > Kamil Dudka <[EMAIL PROTECTED]> writes: > > On Wednesday 03 September 2008 11:03:22 you wrote: > >> Kamil Dudka <[EMAIL PROTECTED]> writes: > >> Since both arguments are already bool I see no need for LOG_EQ (it's the > >> only use anyway). > > > > If you are using type bool, there is no guarantee there will be bool > > (0/1) value inside. > > RTFS. It _is_ guaranteed. Even if bool != C99 _Bool. Good to know. Thanks! I was warned in school to avoid comparing bool values some time ago :-) But I hope two more exclamation marks will not hurt anyone. Kamil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Jim Meyering <[EMAIL PROTECTED]> writes: > Andreas Schwab <[EMAIL PROTECTED]> wrote: >> Kamil Dudka <[EMAIL PROTECTED]> writes: >>> On Wednesday 03 September 2008 11:03:22 you wrote: Kamil Dudka <[EMAIL PROTECTED]> writes: Since both arguments are already bool I see no need for LOG_EQ (it's the only use anyway). >>> If you are using type bool, there is no guarantee there will be bool (0/1) >>> value inside. >> >> RTFS. It _is_ guaranteed. Even if bool != C99 _Bool. > > In general, when using gnulib's replacement via stdbool.in.h, > the following comment from that file is relevant: It's not relevant here. The source already depends on the current guarantee for pure bool values. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Andreas Schwab <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >> Andreas Schwab <[EMAIL PROTECTED]> wrote: >>> Kamil Dudka <[EMAIL PROTECTED]> writes: On Wednesday 03 September 2008 11:03:22 you wrote: > Kamil Dudka <[EMAIL PROTECTED]> writes: > Since both arguments are already bool I see no need for LOG_EQ (it's the > only use anyway). If you are using type bool, there is no guarantee there will be bool (0/1) value inside. >>> >>> RTFS. It _is_ guaranteed. Even if bool != C99 _Bool. >> >> In general, when using gnulib's replacement via stdbool.in.h, >> the following comment from that file is relevant: > > It's not relevant here. The source already depends on the current > guarantee for pure bool values. It looks relevant to me, since we're using gnulib's stdbool and I think we still care about portability to systems where the nonconforming replacement is used. I presume you're referring to uses of "bool" variables like these (there are many more): if (me_remote & show_local_fs) return; if (me_dummy & !show_all_fs & !show_listed_fs) return; Those uses of "&" should be changed to "&&", so that the code will work even with our stdbool emulation. Thanks for pointing that out. On the other hand, this may be an indication that no one is using df on a system for which that less-functional "bool" emulation is required. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Issue with ls -v / sort -V and strverscmp() usage
Hello, as reported in RH bugzilla #253817 (https://bugzilla.redhat.com/show_bug.cgi?id=253817), there is an issue with ls -v (and there will be same issue with sort -V soon). Problem is with sorting files with extensions or dist-tags (like .tar.gz) because .tar.gz is more than .1.tar.gz. Therefore foo-5.0.tar.gz will be considered as later version than foo-5.0.1.tar.gz . As ls -v and sort -V now use glibc strverscmp() and this function is not going to change (http://sourceware.org/bugzilla/show_bug.cgi?id=3506) , I would like to know your opinion how to solve the issue. I see several possible ways how to solve it: 1) keep it as it is and document those limitations 2) to use gnulib strverscmp() for ls -v and sort -V and to modify it somehow to handle such cases correctly 3) to use/create different function for handling version sort (like rpmvercmp in recommended in glibc strverscmp() bugzilla) Which way do you like? Or do you have different ideas? Greetings, Ondrej Vasik signature.asc Description: Toto je digitálně podepsaná část zprávy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Issue with ls -v / sort -V and strverscmp() usage
Ondřej Vašík wrote: > as reported in RH bugzilla #253817 > (https://bugzilla.redhat.com/show_bug.cgi?id=253817), there is an issue > with ls -v (and there will be same issue with sort -V soon). Problem is > with sorting files with extensions or dist-tags (like .tar.gz) > because .tar.gz is more than .1.tar.gz. Therefore foo-5.0.tar.gz will be > considered as later version than foo-5.0.1.tar.gz . In other words, the property that you expect from the comparison function is that if cmp (s1, s2) < 0 then cmp (concat (prefix, s1, suffix), concat (prefix, s2, suffix)) < 0 for many values of PREFIX and SUFFIX. (At least when SUFFIX starts with a dot.) > 3) to use/create different function for handling version sort (like > rpmvercmp in recommended in glibc strverscmp() bugzilla) Does rpmvercmp have the above property? Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Jim Meyering <[EMAIL PROTECTED]> writes: > I presume you're referring to uses of "bool" variables > like these (there are many more): I'm referring to the use of the very same variables that are used in the patch. If those are not pure boolean then you have a bug anyway. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Issue with ls -v / sort -V and strverscmp() usage
Bruno Haible wrote: > Ondřej Vašík wrote: > > 3) to use/create different function for handling version sort (like > > rpmvercmp in recommended in glibc strverscmp() bugzilla) > > Does rpmvercmp have the above property? Similar. It separates name, epoch, version, release and architecture and compares those. Uses subsections of alphanum segments separated by non-alphanum chars. When same segment have different types, numeric is always considered as newer than alpha or alphanum. This solves issue with suffix, but changes behaviour for prefix (name) - as fully numeric project/file name will be considered as "newer" than alphanum project/file name and will be listed after alphanumeric names. Greetings, Ondrej Vasik signature.asc Description: Toto je digitálně podepsaná část zprávy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> I presume you're referring to uses of "bool" variables
>> like these (there are many more):
>
> I'm referring to the use of the very same variables that are used in the
> patch. If those are not pure boolean then you have a bug anyway.
By "used in the patch" do you mean "introduced by the patch"?
I see no problem with the new global, print_grand_total,
and none with the parameters to add_uint_with_neg_flag.
Please be precise.
Here are some of the changes needed to protect against the substandard
"bool" problem we're talking about. Some of the changes (& => &&)
are unconditional improvements, imho. However, the others are not.
Before I start polluting the code with those "fixes", I'd like
confirmation that this is a problem in more than just theory. Do any
of you know of "reasonable portability targets" that are affected?
Gnulib's documentation says that these systems lack stdbool.h:
AIX 5.1, HP-UX 11, IRIX 6.5, OSF/1 5.1
So they'd use gnulib's replacement.
However, I suspect that most people building on such systems
end up using a working "bool" type, rather than the one warned about
in the code.
diff --git a/src/df.c b/src/df.c
index 0bb3b1e..40d6f71 100644
--- a/src/df.c
+++ b/src/df.c
@@ -185,11 +185,11 @@ print_header (void)
divisible_by_1000 = q1000 % 1000 == 0; q1000 /= 1000;
divisible_by_1024 = q1024 % 1024 == 0; q1024 /= 1024;
}
- while (divisible_by_1000 & divisible_by_1024);
+ while (divisible_by_1000 && divisible_by_1024);
- if (divisible_by_1000 < divisible_by_1024)
+ if (!!divisible_by_1000 < !!divisible_by_1024)
opts |= human_base_1024;
- if (divisible_by_1024 < divisible_by_1000)
+ if (!!divisible_by_1024 < !!divisible_by_1000)
opts &= ~human_base_1024;
if (! (opts & human_base_1024))
opts |= human_B;
@@ -246,7 +246,7 @@ df_readable (bool negative, uintmax_t n, char *buf,
return "-";
else
{
- char *p = human_readable (negative ? -n : n, buf + negative,
+ char *p = human_readable (negative ? -n : n, buf + !!negative,
human_output_opts, input_units, output_units);
if (negative)
*--p = '-';
@@ -323,10 +323,10 @@ show_dev (char const *disk, char const *mount_point,
bool negate_used;
double pct = -1;
- if (me_remote & show_local_fs)
+ if (me_remote && show_local_fs)
return;
- if (me_dummy & !show_all_fs & !show_listed_fs)
+ if (me_dummy && !show_all_fs && !show_listed_fs)
return;
if (!selected_fstype (fstype) || excluded_fstype (fstype))
@@ -419,7 +419,7 @@ show_dev (char const *disk, char const *mount_point,
total = fsu.fsu_blocks;
available = fsu.fsu_bavail;
negate_available = (fsu.fsu_bavail_top_bit_set
- & (available != UINTMAX_MAX));
+ && (available != UINTMAX_MAX));
available_to_root = fsu.fsu_bfree;
grand_fsu.fsu_blocks += input_units * total;
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Jim Meyering <[EMAIL PROTECTED]> writes:
> Andreas Schwab <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>
>>> I presume you're referring to uses of "bool" variables
>>> like these (there are many more):
>>
>> I'm referring to the use of the very same variables that are used in the
>> patch. If those are not pure boolean then you have a bug anyway.
>
> By "used in the patch" do you mean "introduced by the patch"?
Those existing variables where more uses are added in the patch.
> @@ -185,11 +185,11 @@ print_header (void)
> divisible_by_1000 = q1000 % 1000 == 0; q1000 /= 1000;
> divisible_by_1024 = q1024 % 1024 == 0; q1024 /= 1024;
^
> }
> - while (divisible_by_1000 & divisible_by_1024);
> + while (divisible_by_1000 && divisible_by_1024);
Here divisible_by_1000 and divisible_by_1024 are guaranteed to be pure
boolean.
> @@ -246,7 +246,7 @@ df_readable (bool negative, uintmax_t n, char *buf,
> return "-";
>else
> {
> - char *p = human_readable (negative ? -n : n, buf + negative,
> + char *p = human_readable (negative ? -n : n, buf + !!negative,
Here negative is guaranteed to be pure boolean.
> @@ -323,10 +323,10 @@ show_dev (char const *disk, char const *mount_point,
>bool negate_used;
>double pct = -1;
>
> - if (me_remote & show_local_fs)
> + if (me_remote && show_local_fs)
> return;
>
> - if (me_dummy & !show_all_fs & !show_listed_fs)
> + if (me_dummy && !show_all_fs && !show_listed_fs)
Here me_remote and me_dummy are guaranteed to be pure boolean.
> @@ -419,7 +419,7 @@ show_dev (char const *disk, char const *mount_point,
>total = fsu.fsu_blocks;
>available = fsu.fsu_bavail;
>negate_available = (fsu.fsu_bavail_top_bit_set
> - & (available != UINTMAX_MAX));
> + && (available != UINTMAX_MAX));
Here fsu.fsu_bavail_top_bit_set is guaranteed to be pure boolean.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Issue with ls -v / sort -V and strverscmp() usage
Ondřej Vašík <[EMAIL PROTECTED]> writes: > Bruno Haible wrote: >> Ondřej Vašík wrote: >> > 3) to use/create different function for handling version sort (like >> > rpmvercmp in recommended in glibc strverscmp() bugzilla) >> >> Does rpmvercmp have the above property? > > Similar. It separates name, epoch, version, release and architecture and > compares those. Uses subsections of alphanum segments separated by > non-alphanum chars. When same segment have different types, numeric is > always considered as newer than alpha or alphanum. This solves issue > with suffix, but changes behaviour for prefix (name) - as fully numeric > project/file name will be considered as "newer" than alphanum > project/file name and will be listed after alphanumeric names. Do you know if the debian dpkg --compare-versions sort-order is different from the rpm sort-order? In any case, adding a new gnulib module with the documented semantic 'sort filenames in an order that makes sense when comparing software versions' seems appropriate. That allows us to change the logic later if we find examples that sorts incorrectly. Possibly the function could take a parameter to sort in RPM-mode or in DPKG-mode, if those algorithms are substantially different, and both outputs are needed by different applications. /Simon ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Issue with ls -v / sort -V and strverscmp() usage
I propose a simple patch for gnulib/strverscmp, which make this function much
more useful. Note that this patch is not related to any distribution. It just
cut off any postfix after version string.
Current version of coreutils uses strverscmp from gnulib, so if you want to
test this patch, you need to force strverscmp from gnulib to ls or sort.
Maybe it is more useful for sort --version-sort, which has not been released
yet. I am not sure with ls, since this tiny change has impact on known (but
broken) ls -v behavior.
Kamil
On Wednesday 03 September 2008 12:52:57 Ondřej Vašík wrote:
> Hello,
> as reported in RH bugzilla #253817
> (https://bugzilla.redhat.com/show_bug.cgi?id=253817), there is an issue
> with ls -v (and there will be same issue with sort -V soon). Problem is
> with sorting files with extensions or dist-tags (like .tar.gz)
> because .tar.gz is more than .1.tar.gz. Therefore foo-5.0.tar.gz will be
> considered as later version than foo-5.0.1.tar.gz . As ls -v and sort -V
> now use glibc strverscmp() and this function is not going to change
> (http://sourceware.org/bugzilla/show_bug.cgi?id=3506) , I would like to
> know your opinion how to solve the issue. I see several possible ways
> how to solve it:
> 1) keep it as it is and document those limitations
> 2) to use gnulib strverscmp() for ls -v and sort -V and to modify it
> somehow to handle such cases correctly
> 3) to use/create different function for handling version sort (like
> rpmvercmp in recommended in glibc strverscmp() bugzilla)
>
> Which way do you like? Or do you have different ideas?
>
> Greetings,
> Ondrej Vasik
From 321dede6df5a2df1a5a54b65ba5755e7767832a1 Mon Sep 17 00:00:00 2001
From: Kamil Dudka <[EMAIL PROTECTED]>
Date: Wed, 3 Sep 2008 15:29:12 +0200
Subject: [PATCH] more useful strverscmp
* lib/strverscmp.c (strverscmp): Ignore postfix after version string.
---
lib/strverscmp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/lib/strverscmp.c b/lib/strverscmp.c
index f077651..f861b66 100644
--- a/lib/strverscmp.c
+++ b/lib/strverscmp.c
@@ -100,7 +100,7 @@ __strverscmp (const char *s1, const char *s2)
/* Hint: '0' is a digit too. */
state = S_N | ((c1 == '0') + (ISDIGIT (c1) != 0));
- while ((diff = c1 - c2) == 0 && c1 != '\0')
+ while ((c1 - c2) == 0 && c1 != '\0')
{
state = next_state[state];
c1 = *p1++;
@@ -110,6 +110,12 @@ __strverscmp (const char *s1, const char *s2)
state = result_type[state << 2 | ((c2 == '0') + (ISDIGIT (c2) != 0))];
+ if (isalpha(c1) && !isalpha(c2))
+c1 = '\0';
+ if (isalpha(c2) && !isalpha(c1))
+c2 = '\0';
+ diff = c1 - c2;
+
switch (state)
{
case CMP:
--
1.5.4.1
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Kamil Dudka <[EMAIL PROTECTED]> wrote: > On Tuesday 02 September 2008 16:01:13 you wrote: >> Would you please amend/squash the patch below into your patch and >> adjust the line lengths of the log message to be <= 72, so that >> the generated ChangeLog lines don't wrap? > No problem, here is (I hope) complete patch. Also thanks for the regexp, it > was helpful for the AWK based test as well. Thanks. Pushed. The only additional change I made was to move the "df" NEWS entry into alphabetical order in the "New features" section. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
I asked the people on the mailing list of our local LUG to test if chmod changes ctime on non-GNU systems even when there is no difference beteen the mode before and after the chmod. From these few data, the trend seems to be that ctime gets changed. Here are the results thus far (identified by "uname -a"): systems that change ctime: -- AIX 3 4 000650834C00 SunOS 5.8 Generic_108528-29 sun4u sparc SUNW,UltraSPARC-IIi-cEngine OpenBSD 4.1 GENERIC#187 i386 systems that do not change ctime: - FreeBSD 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 -- Erik Rossen OpenPGP key: 2935D0B9 [EMAIL PROTECTED] If you do not know what http://people.linux-gull.ch/rossento do, start with RTFM. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
> > > > I'm referring to the use of the very same variables that are used in the > > patch. If those are not pure boolean then you have a bug anyway. > > Here are some of the changes needed to protect against the substandard > "bool" problem we're talking about. Some of the changes (& => &&) > are unconditional improvements, imho. However, the others are not. > Before I start polluting the code with those "fixes", I'd like > confirmation that this is a problem in more than just theory. My understanding of gnulib's stdbool is that _if_ you guarantee the precondition of only ever assigning 0 or 1 to a bool variable, then all other uses of bool work as in C99 without having to uglify code (& can be more efficient than &&, you don't need to use !! to convert a bool back into a 0/1 value, etc). The portability warning in stdbool.in.h is telling users to avoid assigning non-zero values of anything other than 1 into a bool, so that you don't have to worry about the use of that bool. > @@ -185,11 +185,11 @@ print_header (void) > divisible_by_1000 = q1000 % 1000 == 0; q1000 /= 1000; > divisible_by_1024 = q1024 % 1024 == 0; q1024 /= 1024; Here, you are assigning a bool variable by using the == operator, which guarantees 0/1... > } > - while (divisible_by_1000 & divisible_by_1024); > + while (divisible_by_1000 && divisible_by_1024); > > - if (divisible_by_1000 < divisible_by_1024) > + if (!!divisible_by_1000 < !!divisible_by_1024) ...so patches like this should NOT be applied to coreutils, because they add no value. The portability bugs that you must worry about when using gnulib's bool are not in the use of bool, but in the assignment to bool. That is, bool foo = a & mask; is wrong, you should use one of bool bar = !!(a & mask); bool baz = (a & mask) == 0; But your proposed patch did not correct any bugs in meeting the preconditions of bool. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
[EMAIL PROTECTED] (Eric Blake) wrote: >> > I'm referring to the use of the very same variables that are used in the >> > patch. If those are not pure boolean then you have a bug anyway. >> >> Here are some of the changes needed to protect against the substandard >> "bool" problem we're talking about. Some of the changes (& => &&) >> are unconditional improvements, imho. However, the others are not. >> Before I start polluting the code with those "fixes", I'd like >> confirmation that this is a problem in more than just theory. > > My understanding of gnulib's stdbool is that _if_ you guarantee I agree. The question is how best to *maintain* the precondition in the face of future development. This is sufficiently subtle, and the problem (if a violation occurs) sufficiently hard to reproduce (only on aging proprietary systems) that I do see some value in making the uses immune to future accidental violation of the precondition. On the other hand, I prefer not to pander to substandard systems, so I'm torn. Maybe I won't apply it after all. Other opinions welcome. > the precondition of only ever assigning 0 or 1 to a bool variable, > then all other uses of bool work as in C99 without having to > uglify code (& can be more efficient than &&, you don't need to > use !! to convert a bool back into a 0/1 value, etc). The portability > warning in stdbool.in.h is telling users to avoid assigning > non-zero values of anything other than 1 into a bool, so that you > don't have to worry about the use of that bool. > >> @@ -185,11 +185,11 @@ print_header (void) >>divisible_by_1000 = q1000 % 1000 == 0; q1000 /= 1000; >>divisible_by_1024 = q1024 % 1024 == 0; q1024 /= 1024; > > Here, you are assigning a bool variable by using the == > operator, which guarantees 0/1... > >> } >> - while (divisible_by_1000 & divisible_by_1024); >> + while (divisible_by_1000 && divisible_by_1024); >> >> - if (divisible_by_1000 < divisible_by_1024) >> + if (!!divisible_by_1000 < !!divisible_by_1024) > > ...so patches like this should NOT be applied to coreutils, > because they add no value. The portability bugs that > you must worry about when using gnulib's bool are not > in the use of bool, but in the assignment to bool. That is, > > bool foo = a & mask; > > is wrong, you should use one of > > bool bar = !!(a & mask); > bool baz = (a & mask) == 0; > > But your proposed patch did not correct any bugs in > meeting the preconditions of bool. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Uniq is so tilted to "first"
Uniq is so tilted to "first" $ man uniq|grep compar.*first avoid comparing the first N fields avoid comparing the first N characters $ man uniq|grep -c last 0 All so inflexible. There should be a more general way with ranges. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
test -t
On (info "(coreutils)File type tests", and test(1) man page, we see `-t FD' True if FD is a file descriptor that is associated with a terminal. Well please mention what happens if FD is omitted: $ test -t The answer is it always returns true, no matter what. Test with $ echo 'set -x; for i in 0 1 2 3 ""; do /usr/bin/test -t $i; : $?; done; tty'|at now; sleep 4; mail Same problem with the bash and dash builtin tests and documents. bash is even more freaky: $ t=test #bash builtin $ $t -t; echo $? 0 $ $t -t ''; echo $? 1 $ $t -t ' '; echo $? 0 $ t=/usr/bin/test $ $t -t; echo $? 0 $ $t -t ''; echo $? /usr/bin/test: invalid integer `' 2 $ dash $ t=test $ $t -t; echo $? 0 $ $t -t ''; echo $? test: 3: Illegal number: 2 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] df: new option: --total (-c) to produce grand total (in the same way as du)
Jim Meyering wrote: > Other opinions welcome. I mostly agree with Eric here: gnulib's substitute does not guarantee that values stored in a 'bool' are either 0 or 1, therefore the code that creates 'bool' values must guarantee it. > The question is how best to *maintain* the precondition in > the face of future development. By code inspection. We have no compiler warning for this kind of thing. >> Some of the changes (& => &&) are unconditional improvements, imho. I disagree. The & => && change inserts a conditional branch into the control flow, with the potential to save a single memory access. I count ca. 2 CPU cycles for a memory access and ca. 8 CPU cycles for a conditional jump, therefore I would say that the change slows down the program a bit. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Issue with ls -v / sort -V and strverscmp() usage
Kamil Dudka wrote: > I propose a simple patch for gnulib/strverscmp, which make this function much > more useful. We cannot take this patch, as the gnulib strverscmp function is meant to be a substitute for the glibc function of the same name. (Sorry, the doc was not clear about it until today.) This means, gnulib's strverscmp needs to behave the same as glibc's strverscmp. If you want a behaviour change of gnulib's strverscmp, it needs to be accepted by glibc first. But I think, Jakub Jelinek and Ulrich Drepper already rejected such a proposal. You are welcome to propose a new, different function for gnulib, though. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Issue with ls -v / sort -V and strverscmp() usage
Ondřej Vašík wrote:
> > Does rpmvercmp have the above property?
>
> Similar. It separates name, epoch, version, release and architecture and
> compares those. Uses subsections of alphanum segments separated by
> non-alphanum chars. When same segment have different types, numeric is
> always considered as newer than alpha or alphanum. This solves issue
> with suffix
From this description and from its source code I can still not verify that
this function has these properties which I consider essential:
1) cmp (s1, s2) == 0if and only if s1 and s2 are the same,
(otherwise the 'ls' output would not be deterministic)
2) whenever cmp (s1, s2) < 0 && cmp (s2, s3) < 0 then cmp (s1, s3) < 0
(otherwise the 'ls' output could be sorted differently if a file
is added or removed).
3) cmp (concat (PREFIX, s1, SUFFIX), concat (PREFIX, s2, SUFFIX)) ==
cmp (s1, s2)
for all PREFIXes, and for all SUFFIXes that start with a '.'.
> but changes behaviour for prefix (name) - as fully numeric
> project/file name will be considered as "newer" than alphanum
> project/file name and will be listed after alphanumeric names.
Hmm, indeed, rpmvercmp does not fulfill axiom 3: If I understand it correctly,
rpmvercmp ("0002", "04") < 0
but rpmvercmp ("10002", "104") > 0.
I would find it more reasonable to consider zeroes at the beginning of a
segment as relevant when the segment is the first one.
Bruno
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
date -u vs. CST
$ for i in E C M P; do for i in ${i}ST; do echo -n $i:; date -ud "7:00 $i";
done; done
EST:Wed Sep 3 12:00:00 UTC 2008
CST:Wed Sep 3 13:00:00 UTC 2008
MST:Wed Sep 3 14:00:00 UTC 2008
PST:Wed Sep 3 15:00:00 UTC 2008
$ for i in E C M P; do for i in ${i}ST; do echo -n $i:; date -d "7:00 $i";
done; done
EST:Thu Sep 4 20:00:00 CST 2008
CST:Thu Sep 4 07:00:00 CST 2008 <-UH OH
MST:Thu Sep 4 22:00:00 CST 2008
PST:Thu Sep 4 23:00:00 CST 2008
Why should the China zone kick in and out depending on -u? Note that I
object to it being interpreted differently in the input, not the
output.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: test -t
[EMAIL PROTECTED] wrote: > On (info "(coreutils)File type tests", and test(1) man page, we see > `-t FD' >True if FD is a file descriptor that is associated with a terminal. > > Well please mention what happens if FD is omitted: bash's "help test" explains this, if you know where to look: String operators: ... STRING True if string is not empty. Similar language is in bash's man page and coreutils' info documentation. But it wouldn't hurt to add a note to indicate that if no operand is provided, then "-t" and other operators stop being operators, and are tested as plain strings. > $ t=test #bash builtin > $ $t -t ' '; echo $? > 0 That looks like a bug. bash tries to parse a number from the " " string and ends up with zero, which is a tty. paul ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: test -t
Paul Jarc wrote: > Similar language is in bash's man page and coreutils' info > documentation. But it wouldn't hurt to add a note to indicate that if > no operand is provided, then "-t" and other operators stop being > operators, and are tested as plain strings. This is covered in the man page and info document in the `test' builtin section, where the behavior is detailed based on the number of arguments supplied to `test'. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
bug report in df
Hey, I think I found a bug in the df command. I was searching for information to manage my data and then I saw this FilesystemSize Used Avail Use% Mounted on /dev/sda5 23G 23G 71M 100% /media/DOWNLOADS the program reporting that is uses 100% of the place when in fact I have 0.30146059782608697% of free space. Hope i'm clear, Yochai. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
