[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Custom word completion, word splitting, bad behavior
From: |
Nick Patavalis |
Subject: |
Re: Custom word completion, word splitting, bad behavior |
Date: |
Tue, 6 Feb 2018 22:52:33 +0200 |
Hi,
Thank you for your reply.
I'm not sure I understand everything, other than basically... "that's
how readline does it".
I don't suggest there's a bug in readline, but I don't understand, for
example, why
foo --bar "baz" aa bb
is ok to be split like:
foo | --bar | "baz" | aa | bb
while
foo --bar="baz" aa bb
cannot be split like:
foo | --bar | = | "baz" | aa | bb
What would be so terrible with this, that isn't with the previous
(with regard to being able to complete inside quotes, and such)
In any case, splitting it like:
foo | --bar | =" | baz" aa bb
(the last part a single word) does not look reasonable to me (even if
it may be convenient in some occasions I cannot think of). It looks
like a mix-up between the roles of " as a quoting character and as a
word break character.
If I replace " with another word-break character (say :), the command
is again split in a reasonable manner:
foo | --bar | =: | baz | : | aa | bb
Actually, " behaves like a word-break character only when it's a part
of a sequence of other word-break characters (from what I can
tell). As, for example, in:
foo bar"baz
foo | bar"baz (and not: foo | bar | " | baz)
Anyway... confusing as it may be, it is as it is.
I guess my question is: how would you suggest I handle completion for
a command, when an option is given like --bar="baz"? After this point,
my completion function stops getting split-up words and effectively
keeps getting a prev being '="' and and a cur being the rest of the
line. The only solution I can think of is to parse / break-up the line
myself... If this is how it's usualy done, then ok
Again, thanks for your answer.
/npat
P.S. It seems that I'm not the only one being bitten by this... I
tried the bash-completion package (ships with many modern Linux
distributions) and, if I'm not mistaken, even for
simple commands like "ls", completion stops working when an option
value is specified with =, and within quotes. Like:
ls --block-size="150K" /[tab] (no completion)
without the quotes, or without the equal, it works fine.
- Custom word completion, word splitting, bad behavior, Nick Patavalis, 2018/02/05
- Re: Custom word completion, word splitting, bad behavior, Chet Ramey, 2018/02/05
- Re: Custom word completion, word splitting, bad behavior,
Nick Patavalis <=
- Re: Custom word completion, word splitting, bad behavior, Chet Ramey, 2018/02/07
- Re: Custom word completion, word splitting, bad behavior, Nick Patavalis, 2018/02/07
- Re: Custom word completion, word splitting, bad behavior, Chet Ramey, 2018/02/14
- Re: Custom word completion, word splitting, bad behavior, Chet Ramey, 2018/02/07
- Re: Custom word completion, word splitting, bad behavior, Nick Patavalis, 2018/02/07
- Re: Custom word completion, word splitting, bad behavior, Chet Ramey, 2018/02/12
- Re: Custom word completion, word splitting, bad behavior, Nick Patavalis, 2018/02/13