Re: [PATCH 2/2] test-lib: teach test_seq the -f option

[Todd Zullinger <tmz@pobox.com>]

Jeff King wrote:
> On Mon, Jun 23, 2025 at 01:27:07PM -0400, Todd Zullinger wrote:
>> I don't know whether it's worth the extra code or not.  I
>> just wondered about how it would fail in the face of a minor
>> typo.  It certainly should cause any test to fail if it were
>> to output 1 instead of the intended format string, so it's
>> arguably fine as-is.
> 
> Hmm, maybe. I notice that "seq" itself does this (though it did surprise
> me). I think there it is actually doing the "%" interpolation itself (to
> avoid memory errors by feeding arbitrary strings to printf functions),
> so it's easy to do.
> 
> In our case, we can rely on the shell printf to do something sensible if
> fed garbage. And because we're not parsing ourselves, a pattern like you
> have above isn't totally accurate (e.g., consider what it would with
> "%%d"). But it probably would be enough to catch typos.

Parsing it fully felt like overkill, and a good bit more
code to do it well.  So that was me being lazy.  :)

> It would also disallow:
> 
>   test_seq -f "same line" 50
> 
> to produce repeated lines, though I don't know how valuable that would
> be. So I dunno.

I can see someone using it that way, like a cheap version of
the yes command.

> If people are going to use "-f%d", I think we'd be better off making it
> work than trying to complain about it. But I was hoping we could just
> keep things simple and stupid, given the limited audience.
> 
> So my inclination is to leave the sharp edges and see if anybody gets
> cut, but it's possible that I'm just being lazy.

Sounds good to me.  As you say, it's not going to be exposed
to "normal" users.

The worst thing it can do is allow a test to pass which
shouldn't -- and that's by far the least likely way for the
(not very) sharp edges to cut us.

-- 
Todd