[PATCH 2 of 2 RFC] dispatch: add $@ expansion in shell aliases

Martin Geisler mg at aragost.com
Fri Jul 9 05:44:30 CDT 2010


Steve Losh <steve at stevelosh.com> writes:

> # HG changeset patch
> # User Steve Losh <steve at stevelosh.com>
> # Date 1278641324 14400
> # Node ID 6b673acfd0ab1b37b9ca744002b6eb1e616ee705
> # Parent  1b8db360ae3f5430a6a41c05f26c58c5475e4c81
> dispatch: add $@ expansion in shell aliases
>
> If there are any instances of $@ in a shell alias they will be replaced with
> the arguments given after the command (separated by spaces). If not, the
> arguments will be appended to the end of the command instead:
>
>     [alias]
>     echo = !echo
>     count = !hg log --template='.\n' -r '$@' | wc -l
>     countv = !echo 'Revisions in "$@":' ; hg log --template='.\n' -r '$@' | wc -l
>
>     $ hg echo foo
>     foo
>     $ hg count 'branch(default)'
>            1203
>     $ hg countv 'branch(default)'
>     Revisions in "branch(default)":
>            1203
>     $
>
> Note: *ALL* occurrences of "$@" in the definition are replaced, not just the
> first one, which is why the "countv" example works.

Could we instead let the shell do the substitution using its normal
rules for handling quotes?

I mean, regardless of how the users quoted our command line arguments,
we know how many arguments we got and we can quote them again. So if we
execute

  ['sh', '-c', ALIAS, 'ignored'] + cmdargs

then I think it could work. That is, this little test works:

  sh -c 'ls "$@"' ignored 'a " b' 'c d'

where "works" means that I get

  ls: cannot access a " b: No such file or directory
  ls: cannot access c d: No such file or directory

as output, indicating that the $@ has been expanded correctly into two
arguments for ls.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/


More information about the Mercurial-devel mailing list