Re: [PATCH 1/2] test-lib-functions: make packetize() more efficient
- From
Jeff King <peff@peff.net>
- Date
- Mar 29, 2020, 14:52 UTC
- Message-ID
- <20200329145224.GA15400@coredump.intra.peff.net>
- In-Reply-To
- <xmqqh7y8c94g.fsf@gitster.c.googlers.com>
On Sat, Mar 28, 2020 at 05:11:59PM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> > - 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.
Show 16 quoted lines
> 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