The file name matching code in libedit tries to adjust to the presence
of explicit " or ' characters in the input line, but tries too hard.
Remove a conditional that goes overboard, and causes the completion
code to fail if a quoted string is seen before the filename to be
expanded, as in
grep 'foo' bar<TAB>
Before this change, the above would not expand any possible
completions, even if they existed, because it would choose to look for
files whose names started with " bar".
match, the expected space is not being added. Problem observed with
"chronyc" and "sqlite3" tab completion. That functionality got
moved to escape_filename() for the !attempted_completion_function
case, but the non-NULL 'attempted_completion_function' case must
also be handled. (Lonnie Abelbeck)
While there also fix handling character appending in the file completions when
inside quotes. For example when inside a quote, if the completion is a directory then
append a '/' but don't close the quote. On the other hand when inside a quote if the
completion is a file name and it is the only match then we can close the quote.
Quoting of special characters in filename completion was implemented for single match
case, this enables it for multiple matches as well. For example:
$ touch 'foo bar'
$ touch 'foo baz'
$ ls fo<TAB>
autocompletes to =>
$ ls foo\ ba
hitting <TAB> again shows:
foo bar foo baz
This required unescaping escape sequences generated during last completion
in order to find the word to complete.
While there, also update the test to include cases for multiple matches.
Reviewed by christos
If the user supplies a value for the attempted_completion_function parameter
then we cannot be sure if the completion is for filename or something else, in such
a case don't attempt to quote the completion matches.
Reviewed by christos
This should address PR lib/54067
For instance if the file name is "foo bar":
$ ls foo<TAB>
should get autocompleted to:
$ ls foo\ bar
Works for similar other characters too, which need escaping.
Also, add an accompanying test program to ensure the escaping is correct
in various scenarios (within quotes, without quotes, with other special characeters)
Thanks to Christos for reviews, help and feedback.
For example if you do
$mkdir -p /tmp/dir1/dir2
Then:
$ls /tmp/di <TAB> auto completes to
$ls /tmp/dir1/
Hitting <TAB> again auto completes to
$ls /tmp/dir1/dir2
Whereas it should auto complete to
$ls /tmp/dir1/dir2/
Essentially, in cases like above where you have to hit <TAB> twice to get
to the match and there is only one match (because only one file/sub-directory) then
auto complete doesn't work correctly. It doesn't append a trailing slash (in case
of directory) or a space (in case of a file) to the match name.
I have tested file name completion in sh(1) and symbol completion in gdb after
this change.
Let "el.h" include everything needed for struct editline,
and don't include that stuff multiple times. That also improves
consistency, also avoids circular inclusions, and also makes it
easier to follow what is going on, even though not quite as nice.
But it seems like the best we can do...
exposed function. (But note that this function is neither documented
nor declared in any installed header file, and it probably should not
be externally exposed.) Related to PR 44183, closes PR 44186.
skip entries, print (null), run off the end of the array, or occasionally
receive SIGSEGV, and now will, hopefully at least, do none of that.
Based in part on the patch in PR 44183 from Sergio Acereda; I also
did some tidyup and fixed it to print top-to-bottom first like ls(1).
