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.
