bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Custom word completion, word splitting, bad behavior


From: Chet Ramey
Subject: Re: Custom word completion, word splitting, bad behavior
Date: Mon, 5 Feb 2018 11:40:46 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2/5/18 2:25 AM, Nick Patavalis wrote:
> I witnessed the following in the word-splitting results passed to
> custom completion functions. The word splitting performed goes haywire
> when it sees the =' (equal, quote) or =" (equal double-quote)
> character sequences. From this point on, practically no word-splitting
> is performed. As these sequences are quite frequent (e.g foo
> --bar="baz"), this forces the writer of custom completion functions to
> do word-splitting himself, something doable, but certainly not trivial.

Word splitting is performed as readline does it, not as the shell does it.


> So, I guess, my questions are:
> 
> 1. Why are ' and " in the default COMP_WORDBREAKS

Because readline understands how to complete inside quoted strings. If
you type "file[TAB] you'd like readline to complete it to "filename",
especially when shell metacharacters are involved.

> 2. Why can't I pass wordbreaks specific to my function when I register
> it with complete

Because you'd like readline and programmable completion to break words
consistently, and readline breaks words before the programmable completion
code is invoked. That's why there's a single mechanism that controls
readline's word breaks whenever they happen.

> 3. Why does readline gets so messed up when it sees a =" and " is in
> COMP_WORDBREAKS?

Because both of those characters are word breaks, and sequences of word
break characters compose a word break.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]