mirrors
/
zsh
mirror of git://git.code.sf.net/p/zsh/code
1
0
Fork 0
Code Releases Activity

43031: Add note to style guide about quoting

This commit is contained in:
dana 2018-06-16 11:50:43 -05:00
parent 4d19645d49
commit 0daeed20e1
2 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
ChangeLog
View File

@ -1,5 +1,8 @@
2018-06-16 dana <dana@dana.is>
* 43031: Etc/completion-style-guide: Add note about quoting/escaping
(cf. 42992)
* 43031: Etc/completion-style-guide: Add note about optional/variant
syntax (cf. 43025)

17
Etc/completion-style-guide
View File

@ -513,3 +513,20 @@ Misc. remarks
completion function would contain the code for the default way to
generate the matches.
See the `_email_addresses', `_rpm' and `_nslookup' files for examples.
9) Be mindful of quoting/escaping edge cases. Notably:
* Elements of the `$words' array are derived verbatim from the user's
command-line input -- if they type an argument in quotes or escaped
by backslashes, that is how it appears in the array.
* Option-arguments are stored in `$opt_args` the same way. Further,
since multiple arguments to the same option are represented in a
colon-delimited fashion, backslashes and colons passed by the user
are escaped. For instance, the option-arguments parsed from
`-afoo -a "bar" -a 1:2:3' appear in `$opt_args[-a]` as
`foo:"bar":1\:2\:3'.
* The `_call_program` helper used by many completion functions is
implemented using `eval', so arguments to it must be quoted
accordingly. As mentioned above, most of the user's own input comes
pre-escaped, but you may run into problems passing file names or
data derived from another command's output to the helper. Consider
using some variation of the `q` expansion flag to deal with this:
`_call_program vals $words[1] ${(q-)myfile}'