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).
with the trailing newline, others don't so don't make any assumptions
about it when printing. Also print the correct event number (generated),
separate the event number from the event with a tab, and visually encode
the string (don't encode tabs and spaces though).
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.
christos