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

[Matt Mackall]

On Wed, 2010-08-04 at 14:18 -0400, Steve Losh wrote:
> On Jul 31, 2010, at 4:39 PM, Matt Mackall wrote:
> 
> > 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
> > ...
> 
> Are you saying this applies to shell aliases as well, or just explaining why hooks behave the way they do?

I'm explaining why it's "a classic anti-pattern to not pass the actual
event name/number to a registered callback in some form". It means you
can't have generic callbacks without adding N stupid wrappers.

> >> Is it confusing to have HG_ARGS include the command name for hooks but not for aliases?
> > 
> > Yes, a bit.
> 
> I agree.  I thought about giving it a new name, but couldn't think of one that fit nearly as well as HG_ARGS.  Any ideas?

Uh, stick with HG_ARGS and include the command name?

-- 
Mathematics is the supreme nostalgia of our time.