Command Utility Belt

Command Utility Belt

[Chris Johnson]

I'm finding that I have a lot of semi-often used commands that aren't
exactly appropriate for aliasing -- they need minor editing each time I
call on them.  Furthermore, they're cryptic enough that it would be nice
to able to recall these commands easily (for editing).  I wonder if
anyone knows a good solution.

Two ideas I've had work okay.  The first is to assign the command to an
alias that does 'print -z' on the command.  For example:

   alias my_command='print -z prog arg1 arg2 arg3 ...'

The drawback to this is that it introduces a superfluous accept-line.

The second is to assign the plain old command to an alias and bind a key
to _expand_alias.  This will of course expand the alias and keep the
line active for editing.  The drawback to this one is that I have to
have the cursor on the alias itself to expand it.  I've fashioned a
widget to allow arbitrary alias expansion:

   expand-alias() {
      zle beginning-of-line
      zle vi-forward-char
      zle _expand_alias
   }
   zle -N expand-alias

A third solution, which I might prefer but haven't yet attempted, is to
prime the history with these commands.  I think 'print -s' would do
this.

Has anyone else implemented such a "command utility belt" and have
recommendations?  Thanks!

-- 
Chris Johnson
cjohnson@cs.utk.edu
http://www.cs.utk.edu/~cjohnson

Re: Command Utility Belt

[Bart Schaefer]

On Jan 19,  2:37pm, Chris Johnson wrote:
}
} I'm finding that I have a lot of semi-often used commands that aren't
} exactly appropriate for aliasing -- they need minor editing each time I
} call on them.
} 
} [...]
} 
} Has anyone else implemented such a "command utility belt" and have
} recommendations?

I do this with the completion system.

In a directory in my fpath I have a file whose name begins with an
underscore with contents like so:

---- 8< --- snip --- 8< ----
#compdef -k menu-select ^X:
(( CURRENT == 1 )) || return 1
local -a commands
commands=(${(f)"$(cat)"}) <<\EOF
 ... a list of commands here, one per line ...
EOF
compadd -Q "$commands[@]"
---- 8< --- snip --- 8< ----

This installs itself during "compinit" so when I type control-X colon
in "command position" I get a menu of the listed commands.

The reason this is restricted to command position is, completion does
not deal well with matches that contain multiple result words.  It
really wants to operate on a single IFS-delimited word only.  When an
entire command -- which might contain command separators, quotes, and
so on -- gets inserted into the command line by the first pass through
completion, all bets are off on the next iteration.  In the command
position, and with menu selection explicitly invoked, completion does
not have a chance to get confused until after you've committed to a
particular choice.

A potentially useful extension to this would be to store the list of
commands outside the actual function, and have another key binding
to append the current command to the file.  This could probably be
done with the push/pop history mechanism, which didn't exist at the
time I wrote this.

In fact, a possible alternative to using completion is a keybinding
that pushes a new history file and does a recursive edit until you
select a command, then restores the old history and calls accept-line.
I may even fool around with that ...