I'm writing a zsh completion for some program, and parts of it involves completing resource routes (/they/look/like/this).
I have a command mycmd that I can use to generate some completion candidates of resource routes, and provide completions for my program, using:
_multi_parts '/' "($(mycmd /some/resource/id))"
Now, I would like to implement a specific behavior to match resources that contain the last identifier in my query, not only those that start with it.
For example, $(mycmd "/resource/identifier/bc") gives completions like :
/resource/identifier/abc456/
/resource/identifier/123abcXYZ/
We get resource names whose identifier contains bc, which is the intended behavior.
Now here is the problem: zsh completion prevents these completions from showing up, because none of them matches "/resource/identifier/bc*", the default pattern for zsh.
I read the documentation for ZSH _multi_parts , compadd. It appears that using -M <pattern> described in compadd doc and available for _multi_parts could do the trick, by specifying a custom pattern for completion as described in ZSH Matching Control documentation. However this doc is lacking useful examples and is overall very obscure to me.
I spent hours of trials and errors to find the right pattern argument for _multi_parts -M <pattern> to achieve what I want with no success. Any hint on this would be much appreciated.
EDIT: actually, simply ignoring the last resource identifier bc would also work. I did not manage to do this either using -M.
Finally found out how to do this. The correct specification is:
_multi_parts -M 'l:|=*' '/' $completions
The pattern l:|=* allows to recognize matches which contain extra character after the string on the command line.
Looking at zsh completion log below (C-x ?), we find that it also uses patterns r:|/=* r:|=*.
In my understanding, using both r:|=* and l:|=* allows recognizing any completion candidate -- which is fine in my case, since filtering relevant suggestions is done with $mycmd.
Extract from ZSH completion log:
+_multi_parts:94> compadd -O tmp1 -M 'r:|/=* r:|=* l:|=*' - ENSG00000170615_SLC26A5_NT
+_multi_parts:96> [[ 1 -eq 0 ]]
+_multi_parts:99> [[ 1 -eq 1 ]]
+_multi_parts:106> [[ SLC = */* ]]
+_multi_parts:109> matches=( ENSG00000170615_SLC26A5_NT/ )
+_multi_parts:111> PREFIX=/run/echolocation_example/SLC
+_multi_parts:112> SUFFIX=''
+_multi_parts:114> [[ 0 -ne 0 ]]
+_multi_parts:115> zstyle -t :completion::complete:pelican:argument-2: expand suffix
+_multi_parts:119> (( 1 ))
+_multi_parts:120> compadd -p /run/echolocation_example/ -r / -S / -M 'r:|/=* r:|=* l:|=*' - ENSG00000170615_SLC26A5_NT
Related
I spent a long time searching but cannot find the answer.
I am using an "astronomy-aware" perl script which is super useful for calculations on the command line and in scripts. The problem is that parentheses have to be escaped:
calc.pl (1+1)/(2+2)
zsh: unknown file attribute: 2
calc.pl \(1+1\)/\(2+2\)
0.5
The best alternative to escaping each one is using single quotes to enclose the entire expression like this:
calc.pl '(1+1) / (2+2)'
0.5
How can I define a zsh alias (like alias calc="${HOME}/bin/calc.pl") that encloses the expression that comes after the call to the script within the single quotes as shown in the second example?
The solution linked by Barmar works! Thank you so much!
It was provided by (aloxaf) here:
https://superuser.com/questions/1508079/auto-quote-arguments-in-zsh
I defined the following in my .zshrc and it works.
function quote-accept-line() {
local -a starts_with=("calc.pl ")
for str ($starts_with) {
if [[ ${(M)BUFFER#$str} ]] {
BUFFER=$str${(qq)BUFFER#$str}
}
}
zle accept-line
}
zle -N quote-accept-line
# bind it to "Enter"
bindkey "^M" quote-accept-line
The special noglob command modifier can be used for this:
% calc.pl (1+1) / (2+2)
zsh: unknown file attribute: 1
% noglob calc.pl (1+1) / (2+2)
0.5
Typing noglob all the time will probably get boring fast, so you can create an alias for this in your zshrc:
% alias calc.pl='noglob calc.pl'
% calc.pl (1+1) / (2+2)
0.5
The difference between the "auto quoter" is that something like this:
% calc.pl 2' * 3
won't work, as the quotes are still interpreted. I have never run in to issues with this though, as I can't recall ever having used quotes in a calculation, but maybe your Perl script accepts some syntax for that.
Either way, it's a much simpler solution which is probably enough for your purpose.
Bonus: zsh comes with the zcalc module, which provides a calculator; I have no idea how this compares to your Perl script, but the way I have this set up is like this:
autoload -U zcalc # Get quick results for "zc 6 * 6", or just use "zc" to get zcalc
alias zc >/dev/null && unalias zc
zc() { if (( $# )); then zcalc -e ${(j: :)#}; else zcalc; fi }
alias zc='noglob zc'
By default zcalc will throw you in to a REPL unless you use -e, which I find a bit annoying; this way you can type zc (1.0+1) / (2+2) and get your results quickly.
[The question originally asked for a bash solution and was originally tagged bash.]
You're missing the point of the quotes or escapes. It's for the benefit of the shell, not calc.pl. (calc.pl doesn't even see them; it gets (1+1)/(2+2) when you execute the shell command calc.pl \(1+1\)/\(2+2\).)
The issue is that ( ... ) and spaces have special meaning to the shell, so escapes and/or quotes are used to change how the shell interprets them.
You can't do anything about that after the shell has already interpreted them incorrectly, so your request has no solution.
[While the above is still true in zsh, one can hook into zsh's command line editor as shown in the other answer. This allows the command to be edited before zsh sees it.]
I discovered this little navigation trick the other day, which allows me to trigger menu completions by number when I enter 'cd -'
~ cd -
0 -- ~/home
1 -- ~/home/stuff
2 -- ~/downloads
3 -- ~/wallpaper
Shell scripting syntax still reads like a foreign language to me, but to get this functionality my directory stack history is piped into the function below.
DIRSTACKSIZE=9
DIRSTACKFILE=~/.zdirs
if [[ -f $DIRSTACKFILE ]] && [[ $#dirstack -eq 0 ]];
then dirstack=( ${(f)"$(< $DIRSTACKFILE)"} )
[[ -d $dirstack[1] ]] && cd $dirstack[1] && cd $OLDPWD
fi
chpwd() {
print -l $PWD ${(u)dirstack} >$DIRSTACKFILE
}
The magical part is being able to choose from the list by number, but I have come to learn that this is probably
because the functionality for navigation by number is baked in to the 'cd -' command. Still, I'd like to use this everywhere.
Any tips writing a wrapper function (or something like that, I guess) for the completion menu that pipes in completions from the menu when it is triggered
and displays them in a numbered list where those numbers select the corresponding element?
I've gotten started reading the manual and what not, but everything remains rather opaque. Thanks!
First off, the code snippet you show has nothing to do with completion. Instead, what it does is to record the directory stack to a file in order to preserve it between zsh sessions. (Personally, I'm not even sure this is a good idea.)
A good place to start investigating zsh completions is the _complete_help ZLE widget. This is bound by default to ^Xh in zsh's viins (vi insert) keyboard map, but is unbound by default in the emacs keymap. If you want to use it in the emacs keymap (the default for many people), you have to bind it:
bindkey -M emacs "^Xh" _complete_help
Now you can type cd - (or cd +) and follow it by CTRL-Xh instead of TAB. You should see the following output:
tags in context :completion::complete:cd::
directory-stack (_directory_stack _cd)
(At this point I'll admit we're getting close to the limits of my knowledge of the zsh completion system.)
Now you can see the completer functions for the directory-stack tag in this particular context. The one you're probably interested in is _directory_stack, and you can see the content of that function with:
functions _directory_stack
…which is where those leading numbers are actually generated.
Arguably it's possible to write similar completion functions for other completion contexts, and apply the using zstyle. However, this is non-trivial completion magic, and beyond anything I have attempted
I used the have the following tmux shortcut function defined in a separate script and aliased, which worked fine but was messy. I decided to move it to my .zshrc where it naturally belongs, and encountered a problem I wasn't able to figure out.
function t () {re='^[0-9]+$'
if [ "$1" == "kill" ]
then
tmux kill-session -t $2
elif [[ "$1" =~ "$re" ]]
then
tmux attach-session -d -t $1
fi}
I source my .zshrc, call the function, and get:
t:1: = not found
I know the function is defined:
╭─bennett#Io [~] using
╰─○ which t
t () {
re='^[0-9]+$'
if [ "$1" == "kill" ]
then
tmux kill-session -t $2
elif [[ "$1" =~ "$re" ]]
then
tmux attach-session -d -t $1
fi
}
I'm assuming this is complaining about the first line of the function. I've tried shifting the first line of the function down several lines, which doesn't change anything except which line the error message refers to. Any clue what's going on? I haven't found anything relating to this specific issue on SO.
The command [ (or test) only supports a single = to check for equality of two strings. Using == will result in a "= not found" error message. (See man 1 test)
zsh has the [ builtin mainly for compatibility reasons. It tries to implement POSIX where possible, with all the quirks this may bring (See the Zsh Manual).
Unless you need a script to be POSIX compliant (e.g. for compatibility with other shells), I would strongly suggest to use conditional expressions, that is [[ ... ]], instead of [ ... ]. It has more features, does not require quotes or other workarounds for possibly empty values and even allows to use arithmetic expressions.
Wrapping the first conditional in a second set of square-brackets seemed to resolve the issue.
More information on single vs double brackets here:
Is [[ ]] preferable over [ ] in bash scripts?
I am attempting to bend zsh, my shell of choice, to my will, and am completely at a loss on the syntax and operation of completions.
My use case is this: I wish to have completions for 'ansible-playbook' under the '-e' option support three variations:
Normal file completion: ansible-playbook -e vars/file_name.yml
Prepended file completion: ansible-playbook -e #vars/file_name.yml
Arbitrary strings: ansible-playbook -e key=value
I started out with https://github.com/zsh-users/zsh-completions/blob/master/src/_ansible-playbook which worked decently, but required modifications to support the prefixed file pathing. To achieve this I altered the following lines (the -e line):
...
"(-D --diff)"{-D,--diff}"[when changing (small files and templates, show the diff in those. Works great with --check)]"\
"(-e --extra-vars)"{-e,--extra-vars}"[EXTRA_VARS set additional variables as key=value or YAML/JSON]:extra vars:(EXTRA_VARS)"\
'--flush-cache[clear the fact cache]'\
to this:
...
"(-D --diff)"{-D,--diff}"[when changing (small files and templates, show the diff in those. Works great with --check)]"\
"(-e --extra-vars)"{-e,--extra-vars}"[EXTRA_VARS set additional variables as key=value or YAML/JSON]:extra vars:__at_files"\
'--flush-cache[clear the fact cache]'\
and added the '__at_files' function:
__at_files () {
compset -P #; _files
}
This may be very noobish, but for someone that has never encountered this before, I was pleased that this solved my problem, or so I thought.
This fails me if I have multiple '-e' parameters, which is totally a supported model (similar to how docker allows multiple -v or -p arguments). What this means is that the first '-e' parameter will have my prefixed completion work, but any '-e' parameters after that point become 'dumb' and only allow for normal '_files' completion from what I can tell. So the following will not complete properly:
ansible-playbook -e key=value -e #vars/file
but this would complete for the file itself:
ansible-playbook -e key=value -e vars/file
Did I mess up? I see the same type of behavior for this particular completion plugin's '-M' option (it also becomes 'dumb' and does basic file completion). I may have simply not searched for the correct terminology or combination of terms, or perhaps in the rather complicated documentation missed what covers this, but again, with only a few days experience digging into this, I'm lost.
If multiple -e options are valid, the _arguments specification should start with * so instead of:
"(-e --extra-vars)"{-e,--extra-vars}"[EXTR ....
use:
\*{-e,--extra-vars}"[EXTR ...
The (-e --extra-vars) part indicates a list of options that can not follow the one being specified. So that isn't needed anymore because it is presumably valid to do, e.g.:
ansible-playbook -e key-value --extra-vars #vars/file
My zshenv file has a bunch of lines like
if [[ -d "$HOME/bin" ]]; then
path=($HOME/bin $path)
fi
I thought I’d try to factor this pattern out into a function. I replaced it with
function prepend_to_path_if_exists() {
if [[ -d $1 ]]; then
path=($1 $path)
fi
}
prepend_to_path_if_exists("$HOME/bin")
but this gives the error
/Users/bdesham/.zshenv:8: missing end of string
where line 8 is the one where I’m calling prepend_to_path_if_exists. What exactly is causing this error, and how can I make this function work? I’m using zsh 5.0.5 on OS X 10.10.1.
You could call functions as with usual command executions like this (without ()):
prepend_to_path_if_exists "$HOME/bin"
It seems that zsh try to expand the glob prepend_to_path_if_exists(…) rather than to call the function.
TL;DR: Prepending emelemnts to $path would be accomplished by a little cryptic way:
(I'm not quite sure that the below form is preferable for anyone though.)
# `typeset -U` uniqify the elements of array.
# It could be good for $path.
typeset -U path
# prepending some paths unconditionally,
path[1,0]=(\
$HOME/bin \
$HOME/sbin \
)
# then filtering out unnecessary entries afterward.
path=(${^path}(-/N))
The $path[x,0]=… is prepending(splicing) element(s) to array taken from the below:
So that's the same as VAR[1,0]=(...) ? It doesn't really "look" very
much like prepend to me.
-- Greg Klanderman (http://www.zsh.org/mla/workers/2013/msg00031.html)
The ${^path}(-/N) expands the glob qualifires -/N on the each $path elements.
(Without ^ in the parameter expansion, the last elements of array will be evaluated, so it is mandatory in this case.)
The glob qualifires -/N means that "symbolic links and the files they point to"(-) the "directory"(/). And when it does not match anything do not raise errors (N).
In short, it would keep exsisting directories only for $path.