[Bash-completion-devel] robustness: var=$(cmd1) cmd2 -<tab>

[Ville Skyttä]

On 12/14/2011 02:48 AM, Igor Murzov wrote:
>> The attached patch appears to fix it for _parse_help, without breaking
>> completions for commands from paths containing backslashed chars (e.g.
>> whitespace) or ones starting with a tilde.  _parse_usage is similarly
>> affected, but I'm not applying this to either because all this mess
>> starts to have a strong code smell on it.
> 
> I think your patch is fine. You use eval, so extra quotes are necessary, aren't they?

It's not just the extra quotes that I'm worried about.

I mean, just look at the mess we're going through in order to be able to
invoke a command in _parse_help that was given to us in a completion's
$1, for example ~/foo\ bar/quux .  Put it in quotes in the completion's
_parse_help call, then put it again in quotes and eval/quote() it in
_parse_help, then put the result in quotes and dequote() it, and
remember to put quotes around that dequote() call.  That just reeks.
But... meh, I'll just apply the patch anyway, hopefully we can clean it
up sometime.

By the way, I recently made it possible for _parse_help and _parse_usage
to parse stdin (by passing - as the first arg) instead of invoking the
command that produces the output to be parsed.  I think that's a cleaner
and more flexible approach than telling _parse_* the command and args to
invoke.  I'd actually like to see existing _parse_* calls coverted to
that approach, and deprecate the old way.  Thoughts?

> By the way, "id" is not listed in completions/Makefile.am, is it intentional?

Nope, thanks for finding and fixing it.

>> I'm having a hard time
>> believing that it's really this hard to get stuff to work, are we doing
>> something wrong?  There must be a cleaner way.
> 
> That's what is written in my /usr/share/zsh/4.3.11/_mount:

:)