Bruce Korb wrote: > Hi Jim, > > On 01/03/11 07:17, Jim Meyering wrote: >> I now see that your patch ... combined stderr with the potentially >> mangled output from a failing "cat" command,... >> >> Also, while it's not likely that the file is missing at that point, >> it is possible, since there is a race condition. > > And if the file contains trash exclusive of 0x0A and starts with > 0x30 through 0x39 then you'll get hosed, too. You have to make > a trade off between programming complexity and usefulness. > If "cat" has a read error, the most likely output will be only > to stderr and you won't have junk. "cat" would have to use > multiple reads before it would emit junk data before printing > an error message. It would not make particular sense to read > line-at-a-time. > > This whole series of emails came about because some GIT command > emitted a fatal error message to stderr, git-version-gen ignored
Did you determine which git command failed and why? 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. > the "fatal" error and I was left wondering what happened. > Perhaps the real "best" solution would be to divert all stderr > to a temp file. It would be printed out on real failure and > otherwise simply removed. I would prefer to keep git-version-gen simple, and using a temporary file would induce disproportionate complexity (having to portably do something like mktemp and having to clean up e.g., upon interrupt). > I'll supply that patch, if you like. > 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.
