Bruce Korb wrote: > On 01/03/11 09:56, Jim Meyering wrote: >> Did you determine which git command failed and why? > > There was only one git command that did not have stderr redirected: > numcommits=`git rev-list "$vtag"..HEAD | wc -l` > But in truth, *no* git command should have its error output > displayed without proper git-version-gen context. Or "cat" > either, for that matter. > >> The only git commands that git-version-gen should be running >> these days are git describe (it runs git rev-list only to accommodate >> very old versions of git), git update-index, and git diff-index. > > Does that "git diff-index" really need to be run in a separate > shell invocation? >> dirty=`sh -c 'git diff-index --name-only HEAD' 2>/dev/null` || dirty=
Yes. As I recall, that was required in order to ensure that even when the shell fails to find a "git" program, the stderr output is redirected. > How is that different from: >> dirty=`git diff-index --name-only HEAD 2>/dev/null` || dirty= > exported variables get passed through either way..... > > But also note that this script will be run from a tarball > in an environment where there may well be some waaaay out of > date git (assuming git is there at all). The recommended way to run git-version-gen ensures that when run from a just-unpacked tarball, it has a file name argument (.tarball-version), and in that case, the script uses its contents and doesn't even attempt to use git. See the comments at the top of git-version-gen for details. >>> I'll supply that patch, if you like. > > Your "commit_list" patch should fix the issue. > >>> Is it okay to use the post-1977 concept of a shell function? >>> Even the Solaris /bin/sh supports it ..... >> >> Yes, it inherits portability constraints from configure, >> which now uses shell functions. > > Maybe Open Solaris will move /bin/sh to something not over 20 years > old and things can move along? :-D I have ;-) at least in most bourne shell test scripts I write these days, where I now assume "local" works, along with everything POSIX. If you find yourself to be too hamstrung by shell portability constraints, consider the techniques in tests/init.sh, whereby it ensures/finds a "usable-enough" shell and (if needed) re-execs it. gnulib-tool and configure scripts do the same thing, but don't try as hard as init.sh does to find the shell features I now require.
