Fix bug in tab completion of directories #16266
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes several bugs in local directory tab completion.
The code currently just performs a glob based on the user's current input. This has a bug that effectively prevents it from ever working. It performs a string concatenation to add an asterisk, which alters the
str
parameter with the in-place-modification methodconcat
. Thestr
parameter is used by the readline library to do its tab completion magic, so suddenly it's got an asterisk on there, and readline's string matching fails. As a practical example:cd t
and press<tab>
str
to give it the valuet*
t*
value, because of the in-place modification that occurred as a result of usingconcat
tools
nortest
start with the literal stringt*
, it finds no matches, and provides no tab completion to the user.Steps to reproduce:
msfconsole
from a directory containing at least two folderscd
and press<tab>
./
<tab>
againExpected behaviour:
The tab completion provides options based on the current directory, or absolute directory specified.
Fix:
A simple fix would be to change
str.concat(*)
tostr + '*'
. However, this leaves another subtle bug in that it doesn't respect glob-meaningful characters such as*
,?
,[
and]
. So if folders actually contain these characters, it would not provide the expected results (as the user is not aware that globbing is used).?
and*
work by coincidence, as globbing will use them as wildcards, which will match the literal characters?
and*
; but it fails in the case of folder names containing brackets. This is probably a rarer situation, but still a bug.You could do all sorts of glob backslash escaping, but that starts to get messy, so instead I just implemented directory searching so as to control this behaviour ourselves, in order to keep it Readline-friendly.
After the fix: