Thanks for looking into this. Sorry about my confusion between
strverscmp and filevercmp. As this bug report appears to be about
filevercmp, glibc is not involved; it's only Gnulib and the utilities
using Gnulib's filevercmp module.
As I now understand it, Gnulib filevercmp is intended to be
Ian Jackson writes ("Re: bug#35939: version sort is incorrect with
hyphen-minus"):
> Paul Eggert writes ("Re: bug#35939: version sort is incorrect with
> hyphen-minus"):
> > GNU sort uses the same algorithm as glibc strverscmp, and this algorithm
> > has
> > changed only once since strverscmp
Paul Eggert writes ("Re: bug#35939: version sort is incorrect with
hyphen-minus"):
> GNU sort uses the same algorithm as glibc strverscmp, and this algorithm has
> changed only once since strverscmp was added to glibc in 1997. The change was
> made in 2009, to fix this bug:
>
>
Hello Paul,
On Wed, Jun 26, 2019 at 12:57:14PM -0700, Paul Eggert wrote:
> GNU sort uses the same algorithm as glibc strverscmp,
I think that both sort and ls use 'filevercmp' - a simplified version
that does not support locales (and doesn't fail).
The change (from 'strvercmp') was made in:
On 2019-06-26 12:25:26 -0600, Assaf Gordon wrote:
> "ls -v" and "sort -V" (coreutils' version sort) behaves differently than
> other implementations in regards to minus character:
>
> $ printf "%s\n" abb ab-cd | sort -V
> abb
> ab-cd
>
> $ v1="abb"
> $ v2="ab-cd"
> $ dpkg
Assaf Gordon writes ("Re: bug#35939: version sort is incorrect with
hyphen-minus"):
> Thanks for the report and the clear details.
Hi. I haven't read the original report, but everything you say about
the behaviour of GNU coreutils and dpkg sounds correct.
This is perhaps an unfortunate wrinkle
GNU sort uses the same algorithm as glibc strverscmp, and this algorithm has
changed only once since strverscmp was added to glibc in 1997. The change was
made in 2009, to fix this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=9913
Has the Debian version-comparison algorithm changed
(Adding Ian Jackson for dpkg/debian-version details)
Hello,
On Tue, May 28, 2019 at 02:53:39AM +0200, Vincent Lefevre wrote:
> With GNU coreutils 8.30 under Debian/unstable, I get:
>
> $ LC_ALL=C ls
> ab-cd abb abe
> $ LC_ALL=C ls -v
> abb abe ab-cd
>
> The hyphen-minus character should
Thank you for all your help. I will let you know if I run into any more
issues. For whatever reason, putting the program on verbose has let it run
with no issues that I can determine related to my initial problems.
Thanks,
~ Heather
On Wed, Jun 26, 2019 at 10:56 AM Assaf Gordon wrote:
> tag
tag 35654
close 35654
stop
Hello,
On Thu, May 09, 2019 at 11:53:11PM +0800, st0n3 ss wrote:
> Hello! we have found a vulnerability of command chown, please check it.If
> it is a vulnerability. please request a cve id for use, thank you!chown -h
> bypass
Given Paul's and Bob's detailed answers,
tag 36130 notabug
close 36130
stop
Hello,
On Mon, Jun 10, 2019 at 04:50:20PM -0600, Assaf Gordon wrote:
> On 2019-06-10 12:28 p.m., Heather Wick wrote:
> > Verbose: This seems to have made the same number of files this time; not
> > sure why the other 3-4 times I ran it it did not. They appear
tag 35632 notabug
close 35632
stop
Hello,
(sorry for the delayed reply)
On Wed, May 08, 2019 at 12:57:10PM +0100, Ralph Corderoy wrote:
>
> Using date from coreutils 8.31-1 on Arch Linux.
> This surprised me.
>
> $ TZ=UTC0 /bin/date -d '1pm + 2 hours'
> Wed 8 May 15:00:00 UTC 2019
>
tag 36383 notabug
close 36383
stop
Hello,
On Tue, Jun 25, 2019 at 04:10:07PM -0700, Brian Woods wrote:
> When doing a math operation to a date command it appear to process the
> timezone differently.
[...]
>
> #echo $datNow
> 2019-06-25 15:21:34
>
> #date -d "$datNow + 1 minute" "+%Y-%m-%d
13 matches
Mail list logo
