Re: readline fails to understand options.

[Chet Ramey]

On 12/21/18 12:52 AM, Bize Ma wrote:
> This works:
> 
>      $ bind 'set enable-bracketed-paste on'; bind -v | grep 'bracketed'
>      set enable-bracketed-paste on
> 
> However, almost any variation of the parameter "on" is not understood by
> readline:
> 
>      $ bind 'set enable-bracketed-paste on .'; bind -v | grep 'bracketed'
>      set enable-bracketed-paste off
> 
>      $ bind 'set enable-bracketed-paste "on"'; bind -v | grep 'bracketed'
>      set enable-bracketed-paste off
> 
> Without any error or warning !!

It strips trailing whitespace but not much else.

> It appears to fall to default value, while this:
> 
>      $ bind 'set bell-style on' ; bind -v | grep 'bell-style'
>      set bell-style audible
> 
>      $ bind 'set bell-style onf' ; bind -v | grep 'bell-style'
>      set bell-style audible
> 
> Stays at its last value.

The difference is that the readline parser treats anything other than "on"
or "1" as false/off/0 when it sets boolean variables.


> It seems that the parser for this options is unable to process anything
> after a valid parameter. And it doesn't emit an error or warning either.

Yes, the readline `bind' parser has traditionally been very permissive
in some ways, strict in others. There are more warnings than before, but
still relatively few.

> Since the parser needs some improvement: Could it be possible to add the
> capability to detect  a `#` after the options as a comment ?

Sure, it's a candidate for inclusion in a future version. I wouldn't object
if someone wanted to do a sample implementation, since it changes how the
variable value is parsed.

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