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

[Steve Losh]

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?

> 
>> 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?

> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> 
>