bug#31335: Fwd: bug#31335: unexpected cp -f behavior
On 16/05/18 00:03, Pádraig Brady wrote: > Agreed. I can't think of a case where replacing a self symlink > is not what you'd want to happen. > > Proposed patch is attached. Now pushed at: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.29-37-gc732388 cheers, Pádraig
bug#31472: tsort reporting false loop in input. unix2dos fixes the problem.
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
bug#31472: tsort reporting false loop in input. unix2dos fixes
> 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
