Hi Martin, Le Saturday 18 January 2014 à 01:38 +0100, Martin Quinson a écrit : > On Fri, Jan 17, 2014 at 10:11:47PM +0100, Jean Delvare wrote: >> Hmm. We incorrectly assumed that portability of this construct wasn't an > > issue because we were using bash. We aren't. The tester is written in > > perl, and except for a few special cases, it blindly execs the commands > > in the test cases. So we get /usr/bin/printf called here, not bash's > > printf. > > > > I am using GNU coreutils 8.12 and 8.21 on my machine. I suppose you are > > using something else on your system. > > Nope, I'm the same. But /bin/sh is an alias to dash here. That might > be why, as the runner script seems to use /bin/sh to start the > commands that need a shell (such as the ones with a redirection).
That would indeed explain it. I installed dash and checked its manual page and it claims that its built-in printf implementation supports octal escapes. I tested it and it indeed works. As dash is a POSIX-compliant shell, this approach should be portable. So we could just use: $ printf "\\002\\000\\001" > test.bin > > $ bash -c "printf '\\x02\\x00\\x01'" > test.bin > > > > Performance-wise it's suboptimal but I suppose we don't really care. > > I did that, and it works. Yeah, the performance drop is not noticable > on this test file ;) OK. My idea to special-case printf and map it to perl's printf was silly (and I failed to implement it), so let's not do that. If any optimisation shall be implemented, it should be on "bash -c", so that we call bash directly instead of calling /bin/sh which in turn calls bash. I'll look into that... -- Jean Delvare Suse L3 Support _______________________________________________ Quilt-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/quilt-dev
