This patch only affects prompts with newlines.
We redraw the prompt [+ input] occasionally, e.g. during tab completion,
history browsing or search, etc, and we expect it to align with prior
redraws, such that the visible effect is that only the input changes.
With multi-line PS1, redraw always printed the prompt some lines below
the old one, which resulted in terminal scroll during every redraw.
Now we only redraw the last PS1 line, so vertical alignment is easier to
manage (we already calculated it using only the last line, but re-drew
all lines - that was the culprit), which fixes those extra scrolls.
Notes:
- We now use the full prompt for the initial draw, after clear-screen (^L),
and after tab-completion choices are displayed. Everything else now
redraws using the last/sole prompt line.
- During terminal resize we now only redraw the last[/sole] prompt line,
which is arguably better because it's hard to do right (and we never did).
- Good side effect for reverse-i-search: its prompt now replaces only the
last line of the original prompt - like other shells do.
function old new delta
put_prompt_custom - 66 +66
draw_custom - 66 +66
parse_and_put_prompt 766 806 +40
read_line_input 3867 3884 +17
input_tab 1069 1076 +7
cmdedit_setwidth 61 63 +2
redraw 59 47 -12
put_prompt 46 - -46
------------------------------------------------------------------------------
(add/remove: 2/1 grow/shrink: 4/1 up/down: 198/-58) Total: 140 bytes
Signed-off-by: Avi Halachmi <avihpit@yahoo.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
(1) restore entire sigaction, not only signal handler function
(2) do not use stdio when not sure WINCH did not interrupt a printf() or such.
function old new delta
cmdedit_setwidth - 81 +81
read_line_input 3682 3722 +40
lineedit_read_key 138 155 +17
put_prompt 55 51 -4
win_changed 93 47 -46
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 2/2 up/down: 138/-50) Total: 88 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
These key combinations should repeat correctly when the keys are
pressed and held.
Before this change, they do this erratically - many repeats are "eaten"
because they are treated as unrecognized ESC seqs:
ESC 0x7f is treated by Alt+baskspace, but ESC 0x7f ESC 0x7f ESC 0x7f
is unrecognized.
Escape sequences corresponding to these key combinations are moved from
read_line_input to lineedit_read_key.
Also, these key sequences are now enabled regardless of whether
FEATURE_EDITING_VI is set, since Vim does not actually support these key
combinations, but they are present in readline library.
function old new delta
static.esccmds 93 103 +10
read_line_input 3737 3687 -50
Signed-off-by: Rostislav Skudnov <rostislav@tuxera.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In standalone shell mode search the applet table as well as PATH
when tab completing a command.
Use a stupid linear search: we're also about to read all the
directories on PATH so efficiency isn't a big concern.
function old new delta
add_match - 53 +53
complete_cmd_dir_file 687 724 +37
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 1/0 up/down: 90/0) Total: 90 bytes
Signed-off-by: Ron Yorston <rmy@frippery.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In vi-mode lineedit tries to detect some escape sequences.
After the ESC it reads the next character to check for certain
values. This read should have a timeout or a user-entered ESC to
switch to command mode doesn't properly handle the next character.
Signed-off-by: Ron Yorston <rmy@tigress.co.uk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In vi mode, the 'p' and 'P' commands caused a segfault when nothing had
been put in the buffer yet because the delptr was not initialized.
Signed-off-by: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When CONFIG_FEATURE_EDITING_SAVE_ON_EXIT is set to y, the histfile
will get cleared if the total amount of history lines is less than MAX_HISTORY.
Only if the histfile is not empty _and_ the amount of lines currently
in memory are equal to or greater than MAX_HISTORY, history saving will
work as expected with this feature enabled.
Output from defconfig + CONFIG_FEATURE_EDITING_SAVE_ON_EXIT=y:
$ echo "foo" > ~/.ash_history
$ ./busybox ash
~/busybox/a $ echo "bar" > /dev/null
~/busybox/a $ exit
$ cat ~/.ash_history
$
Output with the patch applied and same config as above:
$ echo "foo" > ~/.ash_history
$ ./busybox ash
~/busybox/b $ echo "bar" > /dev/null
~/busybox/b $ exit
$ cat ~/.ash_history
foo
echo "bar" > /dev/null
exit
$
Signed-off-by: Dennis Groenen <tj.groenen at gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
First change fixes "read -n NUM". Apparently poll() won't report
data availability if cc[VMIN] > 1 until there are at least cc[VMIN] bytes.
function old new delta
read_line_input 3885 3877 -8
shell_builtin_read 1097 1087 -10
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-18) Total: -18 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Using ash in busybox git version dea28e1e, tab completion doesn't seem
to work properly for filenames that have special characters (such as
spaces) in them. For example, with filenames "foo bar" and "foo zap",
typing "ls fo<TAB>" correctly expands to "ls foo\ ", but then
continuing to type "b<TAB>" will produce "ls foo\ bbar", which is not
correct (the 'b' is duplicated).
Signed-off-by: Mike Shal <marfey@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
