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
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
> 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
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
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
