[PATCH] dispatch: provide an HG_ARGS environment variable to shell aliases

[Matt Mackall]

On Sat, 2010-07-31 at 15:47 -0400, Steve Losh wrote:
> On Jul 30, 2010, at 7:09 PM, Matt Mackall wrote:
> 
> > On Thu, 2010-07-29 at 11:51 +0200, Mads Kiilerich wrote:
> >> On 07/29/2010 05:52 AM, Steve Losh wrote:
> >>> # HG changeset patch
> >>> # User Steve Losh<steve at stevelosh.com>
> >>> # Date 1280375531 14400
> >>> # Node ID eb11d2fb96d16d5b8e55621260ea0e1d49d45aae
> >>> # Parent  84fb29f5e0d29bc95006947a62133032499e3fa3
> >>> dispatch: provide an HG_ARGS environment variable to shell aliases
> >>> 
> >>> This patch changes the functionality of shell aliases to pass the extra command
> >>> line arguments as an HG_ARGS environment variable, instead of simply appending
> >>> them to the command.
> >>> 
> >>> This allows for more flexible shell aliases:
> >>> 
> >>>     [alias]
> >>>     echo = !echo $HG_ARGS
> >>>     count = !hg log -r "$HG_ARGS" --template='.' | wc -c | sed -e 's/ //g'
> >> 
> >> The official way to extend Mercurial is to use extensions. 
> > 
> > ...and hooks. 
> > 
> >> With this we 
> >> take small steps towards introducing another (de facto platform 
> >> specific) way to extend Mercurial. I assume the next steps will be 
> >> positional and optional arguments - and proper handling of 
> >> quoting/escaping. Do we want to go in that direction in core Mercurial?
> > 
> > This is what we currently do for pre- and post- command hooks:
> > 
> >    ret = hook.hook(lui, repo, "pre-%s" % cmd, False, args="
> > ".join(fullargs),
> >                    pats=cmdpats, opts=cmdoptions)
> > 
> > The args bit has been there for ages, the pats and opts bits are more
> > recent.
> 
> One issue: the HG_ARGS variable includes the *full* command line,
> including the name of the command itself.
> 
> I can't think of an instance for a shell alias where this is more
> useful than *just* the arguments, without the alias name in front.
> The patch I sent doesn't put the alias name in front.
> 
> Is there a case I'm missing?

It's a classic anti-pattern to not pass the actual event name/number to
a registered callback in some form. Consider wiring up a helper tool of
some sort that handles three different commands. Without the command
name, you'll need to do:

foo=!helper foo
bar=!helper bar
baz=!helper baz

With, you can simply do:

foo=!helper
...

> Is it confusing to have HG_ARGS include the command name for hooks but not for aliases?

Yes, a bit.

-- 
Mathematics is the supreme nostalgia of our time.