Multi-word aliases?

Multi-word aliases?

[Dominik Vogt]

Background:
-----------

Using git, I want to automatically switch on certain command line
options for certain git subcommands.  For example, "git rebase"
should *always* be silently replaced by "git rebase --keep-empty".
git-config does not help here, because it cannot set the
--keep-empty option.

Now, the shell already has an aliasing mechanism.  For "normal"
commands it would be just somethins like "alias ls='ls -F'" For
now I've settled with a suboptimal approach using alises:

  # force treating the second argument like a command
  alias git="git "
  # aliasing rule for the first argument of git commands
  alias rebase="rebase --keep-empty"

Of course this can have nasty side effects, but it may be good
enough for my immediate task.

Question:
---------

Is there a way to define "multi word" aliases, i.e. to force zsh
to look at the first <n> words for aliasing, not just at the word
in command position?  What I mean is something like this:

  alias "echo foo"="echo foo bar"
  $ echo foo
  foo bar

That would allow to solve this class of problems without help from
the application.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: Multi-word aliases?

[Peter Stephenson]

On Tue, 04 Nov 2014 10:08:38 +0100
Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> Using git, I want to automatically switch on certain command line
> options for certain git subcommands.  For example, "git rebase"
> should *always* be silently replaced by "git rebase --keep-empty".
> git-config does not help here, because it cannot set the
> --keep-empty option.
> 
> Now, the shell already has an aliasing mechanism.  For "normal"
> commands it would be just somethins like "alias ls='ls -F'" For
> now I've settled with a suboptimal approach using alises:
> 
>   # force treating the second argument like a command
>   alias git="git "
>   # aliasing rule for the first argument of git commands
>   alias rebase="rebase --keep-empty"

The usually way of handling this is to add a function that
interprets its arguments and can tweak them before passing
them through.  The tricky bit here is that git can take
options which you need to be able to take account of, so
the obvious trivial

git() {
   case $1 in
   (rebase)
   set -- rebase --keep-empty "${(@)argv[2,-1]}"
   ;;
   esac
   command git "$@"
}

isn't good enough.  But it's a start.

I haven't tried myself, but presumably you tried

   git config --global alias.rebase "rebase --keep-empty"

and that didn't work?

pws

Re: Multi-word aliases?

[Dominik Vogt]

On Tue, Nov 04, 2014 at 09:56:50AM +0000, Peter Stephenson wrote:
> > Now, the shell already has an aliasing mechanism.  For "normal"
> > commands it would be just somethins like "alias ls='ls -F'" For
> > now I've settled with a suboptimal approach using alises:
> > 
> >   # force treating the second argument like a command
> >   alias git="git "
> >   # aliasing rule for the first argument of git commands
> >   alias rebase="rebase --keep-empty"
> 
> The usually way of handling this is to add a function that
> interprets its arguments and can tweak them before passing
> them through.

Yes, I considered this too.  But to get it right it's a lot of
work, which seems to be silly for such a "small" problem.  And
then, if I don't do it right, using the alias approach above is
much simpler and not much worse.  :-/

Just to better understand the situation, is there any technical
reason to limit the scope of aliases to the first word of the
command line?  After all, zsh already has to look everywhere for
global aliases.

Btw., there's no simple way to do regexp search and replace on
command lines like

  s/^(git\w.*\wrebase\w)(.*)/\1 --keep-empty\2/

or is there? (\w is an ad-hoc expression for a token boundary)

> I haven't tried myself, but presumably you tried
> 
>    git config --global alias.rebase "rebase --keep-empty"

According to the man page, you can only define new aliases, not
overwrite subcommands.

  $ man git-config
  ...
  To avoid confusion and troubles with script usage, aliases that
  hide existing git commands are ignored.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: Multi-word aliases?

[Mikael Magnusson]

On Tue, Nov 4, 2014 at 11:43 AM, Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> On Tue, Nov 04, 2014 at 09:56:50AM +0000, Peter Stephenson wrote:
>> > Now, the shell already has an aliasing mechanism.  For "normal"
>> > commands it would be just somethins like "alias ls='ls -F'" For
>> > now I've settled with a suboptimal approach using alises:
>> >
>> >   # force treating the second argument like a command
>> >   alias git="git "
>> >   # aliasing rule for the first argument of git commands
>> >   alias rebase="rebase --keep-empty"
>
>> I haven't tried myself, but presumably you tried
>>
>>    git config --global alias.rebase "rebase --keep-empty"
>
> According to the man page, you can only define new aliases, not
> overwrite subcommands.
>
>   $ man git-config
>   ...
>   To avoid confusion and troubles with script usage, aliases that
>   hide existing git commands are ignored.

Is there a strong reason you don't want to write "git rk" or whatever
at the command line? I'm quite lazy with typing so I have a set of
aliases like git rc, git rs for --continue, --skip, and git amend for
git commit --amend.

As for the global command line regex replace, yes, you can do that if
you hook into the accept-line family of widgets but there's a huge
caveat; it will only do literal replacements (obviously), so if you
want to respect any form of quoting you'll have to reimplement the
full zsh parser in shell script which is probably not fun (eg, to
avoid replacing it in git commit -m "git rebase is very useful"). The
wrapper function Peter mentioned is a much saner alternative here :).

-- 
Mikael Magnusson

Re: Multi-word aliases?

[Dominik Vogt]

On Tue, Nov 04, 2014 at 11:59:09AM +0100, Mikael Magnusson wrote:
> On Tue, Nov 4, 2014 at 11:43 AM, Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> > According to the man page, you can only define new aliases, not
> > overwrite subcommands.
> >
> >   $ man git-config
> >   ...
> >   To avoid confusion and troubles with script usage, aliases that
> >   hide existing git commands are ignored.
> 
> Is there a strong reason you don't want to write "git rk" or whatever
> at the command line?

Yes: I don't want to create my own syntax that nobody understands
but me and then be unable to work on a plain system without silly
"custom" configuration.  I tried it but found the mechanism
awkward and confusing - and the colleagues did not understand what
I was doing.

> I'm quite lazy with typing so I have a set of
> aliases like git rc, git rs for --continue, --skip, and git amend for
> git commit --amend.

I have some handy shell aliases for some lengthy commands that
nobody else would ever use, but I wouldn't bother bother to do
that in an application specific way.  I don't really mind the
typing (because it's usually just "git reb<Up><Up><Return>".
What's really annoying is that rebase silently dumps empty commits
without that option (I use empty commits with comments like "--
ready-to-submit --" or "-- submitted --" in my work repo to sort
patches).

> As for the global command line regex replace, yes, you can do that if
> you hook into the accept-line family of widgets but there's a huge
> caveat; it will only do literal replacements (obviously), so if you
> want to respect any form of quoting you'll have to reimplement the
> full zsh parser in shell script

Ouch!

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: Multi-word aliases?

[Mikael Magnusson]

On Tue, Nov 4, 2014 at 12:33 PM, Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> On Tue, Nov 04, 2014 at 11:59:09AM +0100, Mikael Magnusson wrote:
>> On Tue, Nov 4, 2014 at 11:43 AM, Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
>> > According to the man page, you can only define new aliases, not
>> > overwrite subcommands.
>> >
>> >   $ man git-config
>> >   ...
>> >   To avoid confusion and troubles with script usage, aliases that
>> >   hide existing git commands are ignored.
>>
>> Is there a strong reason you don't want to write "git rk" or whatever
>> at the command line?
>
> Yes: I don't want to create my own syntax that nobody understands
> but me and then be unable to work on a plain system without silly
> "custom" configuration.  I tried it but found the mechanism
> awkward and confusing - and the colleagues did not understand what
> I was doing.

I think in the long run you'll run into more trouble if you expect the
behaviour of commands that do something to be different than it is,
than if you type a command that doesn't exist which then makes you
realize you have to type out the full command. But in this particular
case the resulting difference isn't very life-threatening :).

-- 
Mikael Magnusson

Re: Multi-word aliases?

[Peter Stephenson]

On Tue, 04 Nov 2014 13:32:08 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> I think in the long run you'll run into more trouble if you expect the
> behaviour of commands that do something to be different than it is,
> than if you type a command that doesn't exist which then makes you
> realize you have to type out the full command. But in this particular
> case the resulting difference isn't very life-threatening :).

Indeed, the more life-threatening case is the old "everybody knows rm is
aliased to 'rm -i' so I can just rm any old files and it will be safe
and... oh."

pws

Re: Multi-word aliases?

[Dominik Vogt]

On Tue, 04 Nov 2014 13:32:08 +0100
Mikael Magnusson <mikachu@gmail.com> wrote:
> I think in the long run you'll run into more trouble if you expect the
> behaviour of commands that do something to be different than it is,
> than if you type a command that doesn't exist which then makes you
> realize you have to type out the full command. But in this particular
> case the resulting difference isn't very life-threatening :).

Actually, most of the time when I miss something like that in zsh,
it turns out that once the shell history contains only invocations
of "git rebase" including "--keep-empty" the problem goes away
almost automatically.  That is because I'm way too lazy to type
long commands and instead use history search all the time, usually
after the first or the second letter.  :-)

I don't have a lot of this stuff, but some aliases are useful and
harmless:

alias gdb='gdb -q'
alias ll='ls -l'
alias ls='/bin/ls --color -F -N -T 0 --dereference-command-line-symlink-to-dir
alias pstree='pstree -A'
alias ncal='ncal -M'

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: Multi-word aliases?

[Vincent Lefevre]

On 2014-11-04 13:53:37 +0100, Dominik Vogt wrote:
> On Tue, 04 Nov 2014 13:32:08 +0100
> Mikael Magnusson <mikachu@gmail.com> wrote:
> > I think in the long run you'll run into more trouble if you expect the
> > behaviour of commands that do something to be different than it is,
> > than if you type a command that doesn't exist which then makes you
> > realize you have to type out the full command. But in this particular
> > case the resulting difference isn't very life-threatening :).

I agree.

> Actually, most of the time when I miss something like that in zsh,
> it turns out that once the shell history contains only invocations
> of "git rebase" including "--keep-empty" the problem goes away
> almost automatically.  That is because I'm way too lazy to type
> long commands and instead use history search all the time, usually
> after the first or the second letter.  :-)

Then I suggest:

alias gr='git rebase --keep-empty'

and if this isn't clear for other people, make zsh output the alias
expansion before running the command.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Multi-word aliases?

[Peter Stephenson]

On Tue, 04 Nov 2014 11:43:39 +0100
Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> Just to better understand the situation, is there any technical
> reason to limit the scope of aliases to the first word of the
> command line?  After all, zsh already has to look everywhere for
> global aliases.

Yes, the space triggers the expansion.  Then the resulting token is
passed up to the lexical analyser.  There's no obvious way of having it
expand multi-word aliases without it not being able to parse token by
token. This rather destroys the shell's ability to parse at all.

> Btw., there's no simple way to do regexp search and replace on
> command lines like
> 
>   s/^(git\w.*\wrebase\w)(.*)/\1 --keep-empty\2/
> 
> or is there? (\w is an ad-hoc expression for a token boundary)

I'm not sure if you mean "on a command line passed to a script" or "on a
command line I'm editing".  In context, I'm assuming the former.  In
that case you can do stuff like

  integer index=${argv[(I)rebase]}
  if (( index )); then
    argv[index]=(rebase --keep-empty)
  fi

The way I've done it it's been careful about keeping command line
elements separate; there's no problem with word-splitting.

Tested, for once.  You could do that in a git wrapper, but you still
have the problem that the "rebase" could be some later argument
along the command line (or even an argument to a global option).

pws

Re: Multi-word aliases?

[Stephane Chazelas]

2014-11-04 10:08:38 +0100, Dominik Vogt:
[...]
> Using git, I want to automatically switch on certain command line
> options for certain git subcommands.  For example, "git rebase"
> should *always* be silently replaced by "git rebase --keep-empty".
> git-config does not help here, because it cannot set the
> --keep-empty option.
[...]

See also:
https://unix.stackexchange.com/questions/48862/how-can-i-create-an-alias-for-a-git-action-command-which-includes-spaces

-- 
Stephane