GNU bug report logs -
#31472
tsort reporting false loop in input. unix2dos fixes the problem.
Previous Next
Reported by: Ivan Ivanov <wankata <at> ivanovi.net>
Date: Wed, 16 May 2018 10:43:04 UTC
Severity: normal
Tags: notabug
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31472 in the body.
You can then email your comments to 31472 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#31472
; Package
coreutils
.
(Wed, 16 May 2018 10:43:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ivan Ivanov <wankata <at> ivanovi.net>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Wed, 16 May 2018 10:43:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all,
tsort is reporting loop in my input file, but the loop doesn't exist
really.
I have checked this manually, examining the contents of the file,
related to the reported loop.
Further more, if I run the input file trhough unix2dos – it works, so I
suspect some strange problem with the unix newlines.
The input file is generated with python script on the Ubuntu 16.04.3 so
all newlines should be the same.
Test environments (acting the same way):
---------------------------------------
Ubuntu 16.04.3 LTS
tsort (coreutils) 8.25
and
Debian GNU/Linux 9 (stretch)
tsort (coreutils) 8.26
Reproduction steps:
---------------------------------------
$ unxz for-tsort-bug-example.txt.xz
$ tsort for-tsort-bug-example.txt > /dev/null
the above command should produce:
tsort: for-tsort-bug-example.txt: input contains a loop:
tsort: 15731101
tsort: 15731102
$ cat for-tsort-bug-example.txt | unix2dos | tsort > /dev/null
should exit properly.
You may choose to first convert the file and than call tsort and it
will exit properly again:
$ unix2dos for-tsort-bug-example.txt
$ tsort for-tsort-bug-example.txt > /dev/null
If you have further questions to investigate the issue, feel free to
write back!
Best wishes,
Ivan Ivanov
[for-tsort-bug-example.txt.xz (application/x-xz, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#31472
; Package
coreutils
.
(Wed, 16 May 2018 12:40:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 31472 <at> debbugs.gnu.org (full text, mbox):
Hi again,
I've digged more into this, and I found that unix2dos doesn't fix
the problem, but just masks the tsort behaviour.
If you point the tsort result into a file, you will notice, that tsort
breaks some of the newline chars. The input file seems to be ok.
I am still looking into this, but I am now a little bit suspicious if
this is really a tsort bug.
If I find something useful, I will share it.
Ivan Ivanov
На Wed, 16 May 2018 12:23:12 +0300
Ivan Ivanov <wankata <at> ivanovi.net> написа:
> Hi all,
>
> tsort is reporting loop in my input file, but the loop doesn't exist
> really.
>
> I have checked this manually, examining the contents of the file,
> related to the reported loop.
>
> Further more, if I run the input file trhough unix2dos – it works, so
> I suspect some strange problem with the unix newlines.
>
> The input file is generated with python script on the Ubuntu 16.04.3
> so all newlines should be the same.
>
> Test environments (acting the same way):
> ---------------------------------------
>
> Ubuntu 16.04.3 LTS
> tsort (coreutils) 8.25
>
> and
>
> Debian GNU/Linux 9 (stretch)
> tsort (coreutils) 8.26
>
>
> Reproduction steps:
> ---------------------------------------
> $ unxz for-tsort-bug-example.txt.xz
> $ tsort for-tsort-bug-example.txt > /dev/null
>
> the above command should produce:
> tsort: for-tsort-bug-example.txt: input contains a loop:
> tsort: 15731101
> tsort: 15731102
>
> $ cat for-tsort-bug-example.txt | unix2dos | tsort > /dev/null
>
> should exit properly.
>
> You may choose to first convert the file and than call tsort and it
> will exit properly again:
> $ unix2dos for-tsort-bug-example.txt
> $ tsort for-tsort-bug-example.txt > /dev/null
>
> If you have further questions to investigate the issue, feel free to
> write back!
>
> Best wishes,
>
> Ivan Ivanov
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#31472
; Package
coreutils
.
(Wed, 16 May 2018 16:17:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 31472 <at> debbugs.gnu.org (full text, mbox):
On 05/16/2018 11:23 AM, Ivan Ivanov wrote:
> Hi all,
>
> tsort is reporting loop in my input file, but the loop doesn't exist
> really.
>
> I have checked this manually, examining the contents of the file,
> related to the reported loop.
>
> Further more, if I run the input file trhough unix2dos – it works, so I
> suspect some strange problem with the unix newlines.
>
> The input file is generated with python script on the Ubuntu 16.04.3 so
> all newlines should be the same.
>
> Test environments (acting the same way):
> ---------------------------------------
>
> Ubuntu 16.04.3 LTS
> tsort (coreutils) 8.25
>
> and
>
> Debian GNU/Linux 9 (stretch)
> tsort (coreutils) 8.26
>
>
> Reproduction steps:
> ---------------------------------------
> $ unxz for-tsort-bug-example.txt.xz
> $ tsort for-tsort-bug-example.txt > /dev/null
>
> the above command should produce:
> tsort: for-tsort-bug-example.txt: input contains a loop:
> tsort: 15731101
> tsort: 15731102
The problematic lines are:
$ grep -E '15731101|15731102' for-tsort-bug-example.txt
15731102 16019755
15731102 15731104
15731102 15731101
15731102 15731105
15731102 15731103
15731101
15731102
Therefore your example reduces to:
$ grep -E '15731101|15731102|16019755|15731104|15731105|15731103' for-tsort-bug-example.txt
15731102 16019755
15731102 15731104
15731102 15731101
15731102 15731105
15731102 15731103
15731101
15731102
> $ cat for-tsort-bug-example.txt | unix2dos | tsort > /dev/null
This replaces "\n" by "\r\n", and of course changes the way tsort works.
If your suspicion was that the file has Windows-style line-endings, then
you would have had to use 'dos2unix'.
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#31472
; Package
coreutils
.
(Thu, 17 May 2018 07:10:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 31472 <at> debbugs.gnu.org (full text, mbox):
> I've digged more into this, and I found that unix2dos doesn't fix
> the problem, but just masks the tsort behaviour.
> If you point the tsort result into a file, you will notice, that tsort
> breaks some of the newline chars. The input file seems to be ok.
OK, I've worked on this. The input file is OK and the line breaks are
correct too.
What I've have seen previously is, that tsort is adding LF in the
result file and is preserving the CRLF, so the file ends up with non
consistent line endings.
So we have two problems here:
1. tsort falsely reports loop
2. When working on input with CRLF it creats a mess with the line
endings in the result file.
I am still curious why tsort doesn't report those loops when I change
the line endings to CRLF.
Hope this helps!
Ivan Ivanov
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#31472
; Package
coreutils
.
(Thu, 17 May 2018 08:55:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 31472 <at> debbugs.gnu.org (full text, mbox):
Hi again,
one last comment on this:
Beyond the CRLF problem, I found that the result, returned by tsort on
the file with dos line endings had duplicates. So it is totally
incorrect.
Than I've tried the followling:
Instead of giving this as an input:
15731102 16019755
15731102 15731104
15731102 15731101
15731102 15731105
15731102 15731103
15731101
15731102
I gave tsort this one:
15731102 16019755
15731102 15731104
15731102 15731101
15731102 15731105
15731102 15731103
15731101 15731101
15731102 15731102
and it works like a charm.
So the problem is only with the format of the single nodes without
dependent ones.
Have a nice day!
Ivan Ivanov
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#31472
; Package
coreutils
.
(Tue, 30 Oct 2018 03:26:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 31472 <at> debbugs.gnu.org (full text, mbox):
tags 31472 notabug
close 31472
stop
Hello,
On 2018-05-16 10:16 a.m., Bernhard Voelker wrote:
> This replaces "\n" by "\r\n", and of course changes the way tsort
> works. If your suspicion was that the file has Windows-style
> line-endings, then you would have had to use 'dos2unix'.
On 2018-05-17 2:54 a.m., Ivan Ivanov wrote:
> Beyond the CRLF problem, I found that the result, returned by tsort on
> the file with dos line endings had duplicates. So it is totally
> incorrect.
The conclusion of the thread is that dos/windows/mac line endings
will affect "tsort" (as expected - since tsort treats them as normal
characters which change the sorted string).
As such, I'm closing this bug.
Discussion can continue by replying to this thread.
-assaf
Added tag(s) notabug.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 30 Oct 2018 03:26:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
31472 <at> debbugs.gnu.org and Ivan Ivanov <wankata <at> ivanovi.net>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 30 Oct 2018 03:26:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 27 Nov 2018 12:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 150 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.