On Sat, Mar 28, 2020 at 05:11:59PM -0700, Junio C Hamano wrote:
> > - we do use it in t9010, which is /bin/sh (and have since 2010). I
> > thought it might not be run on obscure platforms because it's
> > svn-related, but I think it doesn't actually require svn.
>
> I do not think I ran git-svn stuff myself for the past 10 years,
> though, after a few projects that matter to me migrated away from
> svn ;-)
Me either. I don't even run the git-svn tests, usually. t9010 is about
the svn fast-importer, though. We've all been running its tests for
years, even though AFAIK it's not really used for anything.
> The largest issue (which is not that large, though) I felt with the
> approach when I saw the patch for the first time was that we need
> the big warning comment before the helper, i.e.
>
> > +# Note that data containing NULs must be given on stdin,...
>
> But after thinking about it a bit more, I think it is probably OK.
> I do not think you can assign a string with NUL in it to a variable
> and you can use "$(command substitution)" as an argument to the
> helper to pass such a string, either (not portably anyway). If such
> a string cannot be made into "$*", ${#packet} won't have to worry
> about counting bytes in a string with NUL in it to begin with, so
> the above note won't even be necessary (it would have to say "you
> cannot pass data containing NULs as arguments---you are welcome to
> try, but you won't be able to do so, not portably anyway"), anyway
> ;-).
Yes. You could probably screw yourself with:
packetize "$(printf "0020git-upload-pack\0host=example.com")"
but presumably you'd quickly notice when your test fails (both dash and
bash just drop the NUL byte entirely, and bash even issues a warning).
-Peff
