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
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
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)
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)
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
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
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
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
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
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
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
Bruno Haible wrote:
Ondřej Vašík wrote:
3) to use/create different function for handling version sort (like
rpmvercmp in rpm/rpmlib.h recommended in glibc strverscmp() bugzilla)
Does rpmvercmp have the above property?
Similar. It separates name, epoch, version, release and architecture
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
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
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 rpm/rpmlib.h recommended in glibc strverscmp() bugzilla)
Does rpmvercmp have the above property?
Similar. It separates name,
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
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)
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
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
[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
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.
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
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.)
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
$ 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;
[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:
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
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
28 matches
Mail list logo
