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

Re: Weird behavior of shell variables in git aliases

From
Jeff King <peff@peff.net>
Date
Mar 22, 2011, 11:28 UTC
Message-ID
<20110322112832.GB32446@sigill.intra.peff.net>
In-Reply-To
<AANLkTimH+eVUh6D5qK-PbNJGg46XJwaCii5zMg7xyZ_6@mail.gmail.com>
On Tue, Mar 22, 2011 at 11:38:06AM +0100, Lasse Makholm wrote:
Show 16 quoted lines
> > The attached quick hack gives
> >
> >  $ git config alias.silly
> >  !echo hello $1; echo $# args, bye!
> >  $ GIT_TRACE=1 ./git silly world funny
> >  trace: exec: 'git-silly' 'world' 'funny'
> >  trace: run_command: 'git-silly' 'world' 'funny'
> >  trace: run_command: 'sh' '-c' 'echo hello $1; echo $# args, bye'\!'' '-' 'world' 'funny'
> >  trace: exec: 'sh' '-c' 'echo hello $1; echo $# args, bye'\!''
> >  '-' 'world' 'funny'
> >  hello world
> >  2 args, bye!
> 
> That would IMHO be The Right Way to do it. Since the documentation for
> aliases promises to to pass my alias to a shell if I prefix it with
> "!", I shouldn't have to add the "sh -c ... -" myself...
It does pass it to the shell. You can do:
  $ git config alias.autolog --oneline
  !repo=`find-git-repo-for $PWD` && git --git-dir="$repo" log

for an example of a shell-based alias. It just doesn't handle positional parameters the way you want. The typical solution is to invoke another shell, but you can also do:

  $ grep -B1 silly .git/config
  [alias]
          silly = "!foo() { echo hello $1; echo $# args, bye!\n}\nfoo"

which unsurprisingly looks like exactly the same solution one would use in the shell to avoid the fact that shell aliases suck for handling positional parameters.

Show 6 quoted lines
> > but it would penalize a properly written alias that uses "sh -c <it> -"
> > trick itself by double forking, which is not very nice and I am unhappy
> > about.
> 
> A properly written alias that uses a trick? I guess that sums up the
> problem... :-)

Yeah. Though it also penalizes non-tricky aliases. See my other mail in this thread.

> Anyway, doesn't the existing way potentially break when passing funky
> arguments containing spaces/quotes/something? We currently pass the
> arguments to the alias command as a single quoted string. Passing them
> as seperate elements on argv seems a lot more robust...

No, the arguments in the current scheme are properly shell-quoted before they are appended to the shell snippet. So they are equally robust.

-Peff
Previous: Lasse MakholmNext: Lasse Makholm
Message 6 of 20 in “Weird behavior of shell variables in git aliases”
  1. Dun PealMar 21, 2011
  2. Jeff KingMar 21, 2011
  3. Junio C HamanoMar 21, 2011
  4. Junio C HamanoMar 21, 2011
  5. Lasse MakholmMar 22, 2011
  6. Jeff KingMar 22, 2011
  7. Lasse MakholmMar 22, 2011
  8. Ævar Arnfjörð BjarmasonMar 22, 2011
  9. Jeff KingMar 22, 2011
  10. Jeff KingMar 22, 2011
  11. Lasse MakholmMar 22, 2011
  12. Jeff KingMar 22, 2011
  13. Lasse MakholmMar 22, 2011
  14. Dun PealMar 22, 2011
  15. Junio C HamanoMar 22, 2011
  16. Jeff KingMar 22, 2011
  17. Lasse MakholmMar 22, 2011
  18. Junio C HamanoMar 23, 2011
  19. Junio C HamanoMar 22, 2011
  20. Junio C HamanoMar 22, 2011

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.