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,
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 fla
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
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
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 usin
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).
> >
>
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 (i
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 argume
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 tha
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 S
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
comp
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
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 us
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 nam
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 hop
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 (& => &&)
> a
[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 abo
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
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
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 consid
$ 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";
do
[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 a
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 fac
29 matches
Mail list logo
