Russ Allbery wrote: > Raphael Geissert writes: > >> This is what collection/file-index pipes to xargs which later calls >> file(1). > > Oh, okay. I guess you're adding the newlines for readability?
Yes, and left the null character to make it easier to notice where it really ends. > >> Since unit_tests/virusaction-test.s does not exist file(1) fails which >> returns the error code that later aborts the check of that package. > > Right. Okay, I get it now. So for some reason we're still getting > truncated file names out of the pipeline that's generating the list of > files in the package, this time because there's no trailing newline. This > is only affecting the very last line of the index? > Yes, but only in Michael's sample. >> No, you are not. I've read multiple times the code in >> unpack/unpack-src-l1 and see no reason why the generated index has no >> trailing new line; I mean, sort adds it on its own even if missing! >> >> $ echo -n foo | hd >> 00000000 66 6f 6f |foo| >> 00000003 >> >> $ echo -n foo | sort | hd >> 00000000 66 6f 6f 0a |foo.| >> 00000004 >> >> So, like I said: chomp workarounds the bug by simply not removing the >> trailing character which in this case is *not* the, expected, line feed. > > I think what had me confused was that I hadn't realized we were > specifically talking about the final line of the file. > Sorry for not making it clear enough. Any though? there's no env var that could be influencing, is there? Cheers, -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org