Make filename completion work with prefixes that contain spaces

[arnoro]

I have the following directory structure

~/hello world
~/hello world/test

Then I start rlwrap with rlwrap -c cat and start typing
~/he<TAB>
completion works as expected
~/hello world/<TAB>
completion does not find test

Is there a possibility to get completion running in such a situation?

[hanslub42]

Completing filenames with spaces is a known problem. Suppose you type

Let's have a look at the following file: /hello world/te<TAB>

(note: I omit the tilde ~ in your example as rlwrap (and 90% of rlwrapped programs) will never interpret this as $HOME)

Of course, any human or intelligent alien will see that you are looking for files like /hello world/test. But it is conceivable that there exists a file named ./file: /hello world/telephone or even ./Let's have a look at the following file: /hello world/telephone under your current directory. So, what prefix should rlwrap complete on? rlwrap (and shells like bash) use a list of word-breaking characters to isolate the prefix. In your problem case, that prefix is world/ (and not /hello world/ as you expected) because spaces are word-breaking, and as there is no file world/test completion will come back empty-handed.

So how do shells and shell-like programs solve this? Lets try that out: bash will complete as follows (notice the backslash!):

~/he<TAB>
~/hello\ world/     

press TAB again:

~/hello\ world/test

As you can see, bash adds a backslash before the space character. It can safely do that because the bash completer knows how bash interprets backslashes. It will also include backslash-escaped word-breaking characters in the prefix (which will be ~/hello\ world/), after which completion will work as expected.

Why can't rlwrap just use this solution? Well, this would unwarrantedly assume that the rlwrapped program understands backslashes the same way as bash does. There is another solution, using quotes, but this has the same drawback.

(cf. this page for a more thorough explanation)

The most general way to solve this is using a filter. A filter will receive the entire input line (not just the prefix) and can decide much more flexibly what to include in the prefix, it could even backtrack through the entire input line to see whether some prefix matches an existing file.

A more user-friendly (but also more complicated) solution would be to give the --complete-filenames option an (optional) argument like BASH_STYLE

For now, I will morph your bug report into a feature request. Thanks for the report!

[arnoro]

Thanks for your reply. I will have a look at the filters. Didn't know them. The BASH_STYLE option would be nice.