Special characters not escaped for zsh completion script

[epage]

Issue by iyzana
Saturday Nov 09, 2019 at 18:56 GMT
Originally opened as clap-rs/clap#1596

---

Rust Version

rustc 1.38.0 (625451e37 2019-09-23)

Affected Version of clap

clap 2.33.0

Expected Behavior Summary

Generated Zsh completions correctly complete possible_values even in the presence of characters that have a special meaning for the shell

Actual Behavior Summary

For example, when some string in possible_values contains | (a pipe) the generated completion script fails with

(eval):1: parse error near `|'

when pressing tab for that argument.
That was the problem I ran into. I then tested some other special characters.

A sample of the characters I found to have problems:

• | breaks completion script (eval):1: parse error near `|'
• ; splits completion value into two
• ? makes whole value not show up in completions
• * makes whole value not show up in completions
• " breaks completion script (eval):1: unmatched "
• ` breaks completion script (eval):1: unmatched `
• $ interpreted as https://www.gnu.org/software/bash/manual/html_node/Special-Parameters.html when followed by some other chars
• # makes whole value not show up in completions

There are more special characters, that need to be escaped. The reproduction from the repo tests against all non control ascii characters and some dollar-something strings.

Steps to Reproduce the issue

• Clone reproduction repo git clone https://github.com/succcubbus/clap-zsh-completions-repro
• cd clap-zsh-completions-repro
• cargo run --release > _clap-zsh-completions-repro
• Copy _clap-zsh-completions-repro somewhere into the $fpath of the zsh (e.g. /usr/local/share/zsh/site-functions)
• cargo install --path .
• rehash; compinit (so the zsh picks up the new binary and completions)
• Type clap-zsh-completions-repro and try to complete the argument

Sample Code or Link to Sample Code

https://github.com/succcubbus/clap-zsh-completions-repro

Debug output

https://pastebin.com/KU4yd6FR

[epage]

Comment by dotboris
Sunday Nov 10, 2019 at 01:37 GMT

---

I've hit the same issue in a project, I've had to work around this by rephrasing the about of a subcommand. dotboris/alt@37e3255

[epage]

Comment by Nukesor
Monday Sep 14, 2020 at 07:48 GMT

---

' also breaks completion when using subcommands, which uses " for strings).

[epage]

Comment by alerque
Wednesday Oct 28, 2020 at 19:35 GMT

---

We just hit this in a project too, backticks in a documentation string shouldn't be causing code execution!

In our case we're using the 3.0.0-beta.2 release, so this isn't just 2.x stuff.

theleagueof/fontship#108

[epage]

Comment by pksunkara
Wednesday Oct 28, 2020 at 20:08 GMT

---

Unfortunately I am still unable to get zsh working properly on my computer. So, I am going to have to rely on contribution

[epage]

Comment by alerque
Thursday Oct 29, 2020 at 18:36 GMT

---

Would introducing a dependency for this be acceptable? I had a look at what's available now and this would take quite a bit of coding. Most of the current dependencies are focused on Claps' core function: accepting stuff in from the CLI. Passing stuff out to into the CLI (as opposed to just the TTY) would is a bit of a different problem but it seems reasonable to expect Clap to handle this robustly. As the inital report and demo repository note there are a lot of cases involved here. I haven't confirmed if shell-escape is actually appropriate or if there are better alternatives, but before I research too much lets hear about whether a dependency to safely handle shell escapeing is going to be allowed.

[epage]

Comment by pksunkara
Thursday Oct 29, 2020 at 18:53 GMT

---

Since the generator lives in a separate crate and is always opt-in, I would tentatively say yes.

[epage]

Comment by pksunkara
Thursday Oct 29, 2020 at 18:53 GMT

---

But I don't think there are any crates that do this.