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 c...@case.edu http://tiswww.cwru.edu/~chet/
