Re: Command Utility Belt

[Bart Schaefer <schaefer@brasslantern.com>]

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