git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 6/6] t: teach lint that RHS of 'local VAR=VAL' needs to be quoted

From
Jeff King <peff@peff.net>
Date
Apr 8, 2024, 20:40 UTC
Message-ID
<20240408204036.GA1639295@coredump.intra.peff.net>
In-Reply-To
<xmqqa5m3damh.fsf@gitster.g>
On Mon, Apr 08, 2024 at 10:31:34AM -0700, Junio C Hamano wrote:
Show 27 quoted lines
> > Hmm. Just porting over my comment from the other thread (before I
> > realized you'd written this series), this misses:
> >
> >   local foo=bar/$1
> >
> > etc. Should we look for the "$" anywhere on the line? I doubt we can get
> > things foolproof, but requiring somebody to quote:
> >
> >   local foo=$((1+2))
> >
> > does not seem like the worst outcome. I dunno.
> 
> Looking at the output from
> 
>     $ git grep -E -e 'local [a-zA-Z0-9_]+=[^"]*[$]' t/
> 
> the listed ones in the proposed commit log message are the false
> positives.  Luckily we didn't have anything that tries to
> concatenate parameter reference to something else.
> 
> But with the pattern we do miss
> 
>     local var=$*
> 
> and possibly many others.  So I am not sure.  The false positives
> do look moderately bad, so I'd rather start with the simplest one
> proposed in the patch.

Yeah, I think a regex is probably going to end up with either false positives or false negatives. It probably does not matter too much which way we err, if we expect them to be rare on either side.

My thinking was mostly that false negatives are worse, because they only matter on old buggy versions of dash (and only if the tests actually pass a value with spaces). And so most developers will not notice them immediately. Whereas false positives, while annoying, are reported to them immediately by the linter. And generally, dealing with problems closer to the time of writing means less work overall.

But I am happy to take your series as-is and we can see which cases (if any!) we miss in practice.

I do hope that eventually we could just say "that buggy version of dash does not matter anymore", but I think it is too soon for that (it sounds like it is still being used in CI).

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 21 of 23 in “local VAR="VAL"”
  1. 0/6 local VAR="VAL"Junio C Hamano, Apr 6, 2024
  2. 1/6 CodingGuidelines: describe "export VAR=VAL" ruleJunio C Hamano, Apr 6, 2024
  3. Eric SunshineApr 6, 2024
  4. Junio C HamanoApr 6, 2024
  5. Andreas SchwabApr 6, 2024
  6. Junio C HamanoApr 6, 2024
  7. Eric SunshineApr 6, 2024
  8. 3/6 t: local VAR="VAL" (quote positional parameters)Junio C Hamano, Apr 6, 2024
  9. Patrick SteinhardtApr 8, 2024
  10. Junio C HamanoApr 8, 2024
  11. 2/6 CodingGuidelines: quote assigned value in 'local var=$val'Junio C Hamano, Apr 6, 2024
  12. rsbecker@nexbridge.comApr 6, 2024
  13. Junio C HamanoApr 6, 2024
  14. Eric SunshineApr 6, 2024
  15. Junio C HamanoApr 6, 2024
  16. 4/6 t: local VAR="VAL" (quote command substitution)Junio C Hamano, Apr 6, 2024
  17. 5/6 t: local VAR="VAL" (quote ${magic-reference})Junio C Hamano, Apr 6, 2024
  18. 6/6 t: teach lint that RHS of 'local VAR=VAL' needs to be quotedJunio C Hamano, Apr 6, 2024
  19. Jeff KingApr 7, 2024
  20. Junio C HamanoApr 8, 2024
  21. Jeff KingApr 8, 2024
  22. 7/6 t0610: local VAR="VAL" fixJunio C Hamano, Apr 6, 2024
  23. 8/6 t1016: local VAR="VAL" fixJunio C Hamano, Apr 6, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.