Soren Hansen <soren@ubuntu.com> wrote:
The bzr problem was obviously that vc-list-files didn't support bzr.
Failing with CVS was caused by a bashism in vc-list-files. In Ubuntu, /bin/sh points to dash instead of bash, but vc-list-files had "#!/bin/sh".
This patch fixes both issues:
Hi Soren, Thanks for the patch.
=== modified file 'build-aux/vc-list-files' --- build-aux/vc-list-files 2008-02-01 19:47:07 +0000 +++ build-aux/vc-list-files 2008-04-30 07:43:06 +0000 @@ -39,6 +39,8 @@ exec git ls-files "$dir" elif test -d .hg; then exec hg locate "$dir/*" +elif test -d .bzr; then + exec bzr ls --versioned --kind=file ${*:---from-root}
Unfortunately, the above no longer applies, due to upstream (gnulib) changes to deal with non-srcdir (aka VPATH) builds. I updated libvirt from gnulib just yesterday, and will again, later today. Can you adapt your patch to make bzr work with the newer version?
}}' \ - $(find ${*-*} -name Entries -print) /dev/null; + $(find ${*:-*} -name Entries -print) /dev/null;
Thanks for reporting that. Note though that POSIX appears to require the behavior that bash exhibits, so calling this a bashism doesn't seem right. However, in the spec, just beneath the part that talks about ${parameter-word} there are escape clauses for e.g., ${#parameter} and ${parameter%word} etc.: If parameter is '*' or '@', the result of the expansion is unspecified. but there is no such exemption for the ${parameter-word} syntax. All that to say that this looks more like an infelicity in dash, and since Ubuntu relies on it, you may want to investigate further. However, back to vc-list-files, that awk-based code is so hard to reach for me -- I avoid CVS, and when I do use it, I have cvsu in my path -- that it is rarely tested. Anyhow the use of "*" there is unnecessary, and in addition, there was a subtle (but probably never problematic) quoting bug. Here's the patch I've pushed to gnulib: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=173a9f0c48a16c3507... If you care about the CVS-oriented cases, there are two more patches. Note that the awk+find-based code *still* fails in some pathological cases, e.g., with a file named 'a b/CVS/Entries' in your hierarchy, but the response there is "just don't do that". Or depend on find -print0+xargs -0, but that would be counter-productive just to avoid a warning in such an unlikely scenario. Jim