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
hrs@ says that
(cbp >= MB_LEN_MAX) condition is necessary for checking invalid
byte sequences. If malicious input was given, libedit would read
byte sequences forever.
hrs@ says that wctomb(3) has an internal shift state,
if wctomb(3) is called outside of libedit,
the internal state can be changed and causes miscalculate multibyte size.
So in this part, wcrtomb(3) should be used.
wcrtomb(3) requires that shift state is given in the argument.
We always initialize the shift state in ct_enc_width() to keep independent
from outside of libedit.
In re_fastputc(), set lastline to the new line, not the previous
line so it gets initialized properly. Fixes a crash in bc with
MALLOC_OPTIONS=UJ. OK deraadt@, committing on behalf of yasuoka@
Initialize "old" screen buffer lines before use; otherwise, they would
never get NUL-terminated and cause read buffer overruns.
This fixes for example segfaults in sftp(1) that could be triggered
by typing in an extremely long string (more than one line - the longer,
the likelier to crash), then hitting backspace once.
Problem reported and patch OK'ed by sthen@.
XXX: pullup-8
don't set unbuffered unless they've already printed the prompt.
This avoids printing the prompt before the application has a chance
to process the input line.
From sjg@
Also, remove a test case which was not supposed to be there.
(While that test case works with the changes I committed, testing that
test case with the test program is not possible in its current form. I'm
working on that.)
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.
Patch from Yen Chi Hsuan in the PR, extracted from Apple's version of
readline.c, then modified by me to be consistent about what the return
value really is.
PR/51518: Jay West: prompt is interleaved with client output
Both these issues are caused by rl_restore_handler not DTRT; fix
it so that it kills the internal libedit state completely. This is
inefficient, but it works.
Also fix:
1. add append_history()/H_NSAVE_FP
2. call the rl_startup_hook before printing the first prompt as documented.
callint it from rl_initialize breaks python, because the callback ends
up being invoked before the readline module is installed, and we end up
dereferencing a NULL pointer.
3. add el_resize_terminal.
With those changes, s/lreadline/ledit/g in python works.
to be (perhaps part of) the "invisible" characters in a prompt, or the
required prompt character which follows the literal sequence (this character
must be one with a printing column width >= 1). The literal indicator
character (which is just a marker, and not printed anywhere) (the PSlit
parameter in sh(1)) can also be a wide char (passed to libedit as a wchar_t,
encoded as that by sh(1) or other applications that support this.)
Note: this has currently only been tested with everything ascii (C locale).
christos