[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