When the 'j'/'k' commands or up/down arrow keys are used to move
the cursor vertically 'vi' remembers the original cursor column
and positions the cursor there if possible. Also, if the '$'
command has been used to position the cursor at the end of a line
vertical movements keep the cursor at the end of the line.
Make BusyBox 'vi' do the same.
function old new delta
refresh 674 694 +20
do_cmd 4853 4861 +8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 28/0) Total: 28 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The 'G' command with no target (meaning 'go to last line') should
position the cursor on the first visible character of the line, as
it already does in other cases.
The 'M' command should position the cursor on the first visible
character (as 'H' and 'L' already do).
function old new delta
do_cmd 4842 4853 +11
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 11/0) Total: 11 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If the name of the file being written doesn't match the current
filename and the output file already exists vi should issue a
warning and not overwrite the file.
Because the test only compares the file names it's somewhat over-
protective. If the current file name is 'my_text' and the user tries
to save to './my_text' they'll be prevented from doing so.
function old new delta
colon 3092 3151 +59
.rodata 105118 105146 +28
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 87/0) Total: 87 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Vi places text affected by change/delete/yank operations into a
buffer. The contents of such buffers can be restored with the put
commands, 'p' or 'P'. These behave differently depending on whether
the buffer contains whole lines or partial lines. For whole lines
the text is copied into the file on the line before (P) or after
(p) the current line. For partial lines the text is copied before
or after the current cursor position.
Whether an operation results in whole or partial lines depends on
the command used.
BusyBox vi treats any buffer with a newline as though it contained
whole lines. This is incorrect. Deleting multiple words across
a line boundary results in a buffer with a newline but not having
whole lines.
Rework how buffers are handled to behave more like vi.
function old new delta
static.text_yank 79 99 +20
colon 3092 3097 +5
edit_file 885 887 +2
yank_delete 127 112 -15
.rodata 105139 105101 -38
find_range 514 467 -47
do_cmd 5088 4842 -246
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/4 up/down: 27/-346) Total: -319 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
I was puzzled by code in find_range() which handles forward word
movement. It included a test to see if we're at the start of a
word. Since these are forward word movements surely we'd expect to
be at the start of a word? In fact, the test was intended to fix a
problem with changes to the last word in a file, as discussed in the
thread starting here:
http://lists.busybox.net/pipermail/busybox/2004-January/044552.html
The code can be simplified by testing directly for end of file instead
of indirectly for not being at the start of a word. Since trailing
whitespace is now handled in do_cmd() the code to back up off a newline
is no longer required.
function old new delta
find_range 619 514 -105
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-105) Total: -105 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Commit 4b49422a0 (vi: fix changes to word at end of line. Closes
11796) fixed a problem where an operation on a word at the end of
a line followed by a line starting with whitespace incorrectly
joined the lines. However it also broke the case where operating
on multiple words across a line boundary *should* join the lines.
Fix this by detecting when trailing whitepace in a word operation
includes a newline. Whitespace beyond the newline is excluded
from consideration.
function old new delta
do_cmd 5083 5088 +5
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 5/0) Total: 5 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Fixes bug where commands after the first noXXX command are ignored.
e.g. :set noic tabstop=4
While at it, stop recognizing "notabstop=NNN".
function old new delta
colon 2990 2965 -25
Signed-off-by: Alison Winters <alisonatwork@outlook.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Selection of ranges for change/delete/yank by forward character
motion commands (SPACE or 'l') was incorrect. The range was
always one character whereas vi allows the size of the range to
be specified.
Fix this by executing the motion command the required number of times.
There is a complication when the range is at the end of a line. We need
to distinguish between a range which excludes the last character and
one which includes it. This requires comparing the actual range with
that expected from the command count. (With the additional quirk that
a command count of zero is equivalent to a command count of one.)
function old new delta
find_range 587 619 +32
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 32/0) Total: 32 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Treat the output of printf as binary rather than a null-terminated
string so that NUL characters can be output.
This is considered to be a GNU extension, though it's also available
in mawk and FreeBSD's awk.
function old new delta
evaluate 3487 3504 +17
awk_printf 504 519 +15
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 32/0) Total: 32 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Handling of string searches in colon commands (e.g ':/pat1/,/pat2/cmd')
differ from standard vi:
- As reported in bug 10321 such searches can't be repeated using the
'n' command. This is because the last search pattern isn't updated.
- The search also can't be repeated using the command '://' because
an empty search pattern doesn't imply the use of the last search
pattern.
- Such searches should start on the line after the current line,
otherwise '://' never moves to the next occurrence of the pattern.
This can also affect other cases where line ranges are specified
using search patterns.
Fix these various issues.
function old new delta
get_one_address 325 342 +17
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Back in 2007, commit 0c97c9d437 ("'simple' error message functions by
Loic Grenie") introduced bb_simple_perror_msg() to allow for a lower
overhead call to bb_perror_msg() when only a string was being printed
with no parameters. This saves space for some CPU architectures because
it avoids the overhead of a call to a variadic function. However there
has never been a simple version of bb_error_msg(), and since 2007 many
new calls to bb_perror_msg() have been added that only take a single
parameter and so could have been using bb_simple_perror_message().
This changeset introduces 'simple' versions of bb_info_msg(),
bb_error_msg(), bb_error_msg_and_die(), bb_herror_msg() and
bb_herror_msg_and_die(), and replaces all calls that only take a
single parameter, or use something like ("%s", arg), with calls to the
corresponding 'simple' version.
Since it is likely that single parameter calls to the variadic functions
may be accidentally reintroduced in the future a new debugging config
option WARN_SIMPLE_MSG has been introduced. This uses some macro magic
which will cause any such calls to generate a warning, but this is
turned off by default to avoid use of the unpleasant macros in normal
circumstances.
This is a large changeset due to the number of calls that have been
replaced. The only files that contain changes other than simple
substitution of function calls are libbb.h, libbb/herror_msg.c,
libbb/verror_msg.c and libbb/xfuncs_printf.c. In miscutils/devfsd.c,
networking/udhcp/common.h and util-linux/mdev.c additonal macros have
been added for logging so that single parameter and multiple parameter
logging variants exist.
The amount of space saved varies considerably by architecture, and was
found to be as follows (for 'defconfig' using GCC 7.4):
Arm: -92 bytes
MIPS: -52 bytes
PPC: -1836 bytes
x86_64: -938 bytes
Note that for the MIPS architecture only an exception had to be made
disabling the 'simple' calls for 'udhcp' (in networking/udhcp/common.h)
because it made these files larger on MIPS.
Signed-off-by: James Byrne <james.byrne@origamienergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The 'G' command was omitted from the list of commands that change or
delete whole lines. Add it in the appropriate places so the 'dG',
'cG' and 'yG' commands work, including in cases where an explicit
line number has been supplied.
function old new delta
find_range 534 596 +62
.rodata 175166 175167 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 63/0) Total: 63 bytes
Reported-by: David Kelly <david.kelly@liberica.ch>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
As reported in bug 11796 BusyBox vi incorrectly handles changes
to a word at the end of a line. If the following line starts
with whitespace changing or deleting the last word of a line
with the 'cw' or 'dw' commands causes the lines to be joined.
This happens because the range for the change returned by
find_range() covers all whitespace after the word, including
newlines. The problem can be fixed by setting 'ml' to zero
to indicate to yank_delete() that processing should stop at
the end of the current line.
However, this results in a new problem. 'dw' correctly deletes
all whitespace following the word but so does 'cw', which should
preserve the trailing whitespace. To fix this the code to omit
whitespace from the change is modified to include all whitespace
not just blanks.
function old new delta
do_cmd 5034 5069 +35
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 35/0) Total: 35 bytes
Reported-by: David Kelly <david.kelly@liberica.ch>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If vi is built with FEATURE_VI_USE_SIGNALS disabled and
FEATURE_VI_WIN_RESIZE enabled new_screen() is used without a
declaration. Move the function to avoid this.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This is the last use of "vsprintf" in busybox:
function old new delta
status_line_bold 72 77 +5
status_line 40 45 +5
vsprintf 23 - -23
------------------------------------------------------------------------------
(add/remove: 0/2 grow/shrink: 2/0 up/down: 10/-23) Total: -13 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
On platforms that don't support SIGWINCH vi can be configured
with FEATURE_VI_USE_SIGNALS disabled and FEATURE_VI_WIN_RESIZE
enabled. This allows the user to force an update with ^L when
the screen is resized.
However, because the SIGWINCH handler hasn't run the virtual
screen buffer won't have been updated and the display becomes
corrupted. Fix this by calling new_screen() if necessary.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Commit bb983f30e (vi: fix faulty undo after autoinsert) has a
number of problems:
- The commit message refers to 'autoinsert' when it really means
'autoindent'.
- The indentation of undo_push_insert() was incorrect.
- Most seriously the commit only fixed the problem for cases where
the indentation was exactly one character. This is because undo_push()
only allows single characters to be queued for UNDO_INS_QUEUED.
Lifting this restriction allows the example given in the previous
commit message (with a three character indent) to work.
function old new delta
undo_push 406 435 +29
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 29/0) Total: 29 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Currently if the 'r' command is followed by a carriage return a
literal CR replaces the current character.
Fix this so that:
- a new line is inserted
- the autoindent setting is respected
- the cursor is placed at the start of the new line
function old new delta
do_cmd 5052 5060 +8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 8/0) Total: 8 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Enable autoinsert and enter the following with an indent of three
spaces:
line 1
line 2
Using 'u' to undo the last insert results in:
line1e 2
The insertion of the indent hasn't been properly recorded.
Since recording insertions is a common operation add a convenience
function, undo_push_insert(), to handle this and use it to record
the autoindent correctly.
function old new delta
undo_push_insert - 36 +36
string_insert 133 129 -4
char_insert 518 473 -45
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 0/2 up/down: 36/-49) Total: -13 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If there's any whitespace between w and the filename, parse_file_cmd
writes to the wrong offset when trying to fix up backslashes.
This can be seen in the asan build with busybox sed -e 'w 0\\'
Signed-off-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Unlike exit and return, delete strictly requires an arg, and derefs a
null pointer if executed without one.
Signed-off-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Avoids an uninit pointer deref for some malformed ternary exprs.
Add a test that would crash in busybox before this fix.
Signed-off-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Michał Berger has reported two issues:
- Repeatedly deleting and undoing the deletion of the last line
results in characters being lost from the end of the line.
- Deleting the bottom line twice then attempting to undo each of
these deletions results in a segfault.
The problem seems to be an incorrect test for whether the text buffer
is empty.
Reported-by: Michał Berger <michallinuxstuff@gmail.com>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If busybox is compiled with FEATURE_VI_REGEX_SEARCH enabled, command
":s/x/y/" searches not only in the current line, but continues search
after it. This makes range searches (":1,3s/x/y/") work incorrect. For
example file "./test":
1
2
3
$ vi ./test
:1,2s/3/e/
gives us:
1
2
e
function old new delta
char_search 213 241 +28
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
At worst show_status_line() might be called needlessly when the
user presses ^L/^R, but I don't think we'll get many complaints
about that.
function old new delta
do_cmd 4592 4558 -34
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-34) Total: -34 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Kconfig-language.txt was deleted in commit 4fa499a17b back in 2006.
Move to docs/ as suggested by Xabier Oneca:
http://lists.busybox.net/pipermail/busybox/2014-May/080914.html
Also update references to it everywhere.
Signed-off-by: Kartik Agaram <akkartik@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This fragment did not work right:
temp = bb_get_chunk_from_file(fp, &len);
if (temp) {
/* len > 0 here, it's ok to do temp[len-1] */
char c = temp[len-1];
With "int len" _sign-extending_, temp[len-1] can refer to a wrong location
if len > 0x7fffffff.
Signed-off-by: Quentin Rameau <quinq@fifth.space>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
FEATURE_GETOPT_LONG made dependent on LONG_OPTS.
The folloving options are removed, now LONG_OPTS enables long options
for affected applets:
FEATURE_ENV_LONG_OPTIONS FEATURE_EXPAND_LONG_OPTIONS
FEATURE_UNEXPAND_LONG_OPTIONS FEATURE_MKDIR_LONG_OPTIONS
FEATURE_MV_LONG_OPTIONS FEATURE_RMDIR_LONG_OPTIONS
FEATURE_ADDGROUP_LONG_OPTIONS FEATURE_ADDUSER_LONG_OPTIONS
FEATURE_HWCLOCK_LONG_OPTIONS FEATURE_NSENTER_LONG_OPTS
FEATURE_CHCON_LONG_OPTIONS FEATURE_RUNCON_LONG_OPTIONS
They either had a small number of long options, or their long options are
essential.
Example: upstream addgroup and adduser have ONLY longopts,
we should probably go further and get rid
of non-standard short options.
To this end, make addgroup and adduser "select LONG_OPTS".
We had this breakage caused by us even in our own package!
#if ENABLE_LONG_OPTS || !ENABLE_ADDGROUP
/* We try to use --gid, not -g, because "standard" addgroup
* has no short option -g, it has only long --gid.
*/
argv[1] = (char*)"--gid";
#else
/* Breaks if system in fact does NOT use busybox addgroup */
argv[1] = (char*)"-g";
#endif
xargs: its lone longopt no longer depends on DESKTOP, only on LONG_OPTS.
hwclock TODO: get rid of incompatible -t, -l aliases to --systz, --localtime
Shorten help texts by omitting long option when short opt alternative exists.
Reduction of size comes from the fact that store of an immediate
(an address of longopts) to a fixed address (global variable)
is a longer insn than pushing that immediate or passing it in a register.
This effect is CPU-agnostic.
function old new delta
getopt32 1350 22 -1328
vgetopt32 - 1318 +1318
getopt32long - 24 +24
tftpd_main 562 567 +5
scan_recursive 376 380 +4
collect_cpu 545 546 +1
date_main 1096 1095 -1
hostname_main 262 259 -3
uname_main 259 255 -4
setpriv_main 362 358 -4
rmdir_main 191 187 -4
mv_main 562 558 -4
ipcalc_main 548 544 -4
ifenslave_main 641 637 -4
gzip_main 192 188 -4
gunzip_main 77 73 -4
fsfreeze_main 81 77 -4
flock_main 318 314 -4
deluser_main 337 333 -4
cp_main 374 370 -4
chown_main 175 171 -4
applet_long_options 4 - -4
xargs_main 894 889 -5
wget_main 2540 2535 -5
udhcpc_main 2767 2762 -5
touch_main 436 431 -5
tar_main 1014 1009 -5
start_stop_daemon_main 1033 1028 -5
sed_main 682 677 -5
script_main 1082 1077 -5
run_parts_main 330 325 -5
rtcwake_main 459 454 -5
od_main 2169 2164 -5
nl_main 201 196 -5
modprobe_main 773 768 -5
mkdir_main 160 155 -5
ls_main 568 563 -5
install_main 773 768 -5
hwclock_main 411 406 -5
getopt_main 622 617 -5
fstrim_main 256 251 -5
env_main 198 193 -5
dumpleases_main 635 630 -5
dpkg_main 3991 3986 -5
diff_main 1355 1350 -5
cryptpw_main 233 228 -5
cpio_main 593 588 -5
conspy_main 1135 1130 -5
chpasswd_main 313 308 -5
adduser_main 887 882 -5
addgroup_main 416 411 -5
ftpgetput_main 351 345 -6
get_terminal_width_height 242 234 -8
expand_main 690 680 -10
static.expand_longopts 18 - -18
static.unexpand_longopts 27 - -27
mkdir_longopts 28 - -28
env_longopts 30 - -30
static.ifenslave_longopts 34 - -34
mv_longopts 46 - -46
static.rmdir_longopts 48 - -48
packed_usage 31739 31687 -52
------------------------------------------------------------------------------
(add/remove: 2/8 grow/shrink: 3/49 up/down: 1352/-1840) Total: -488 bytes
text data bss dec hex filename
915681 485 6880 923046 e15a6 busybox_old
915428 485 6876 922789 e14a5 busybox_unstripped
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This is the behaviour observed with standard vim and busybox vi of at
least 1.22.1. It was changed with commit "32afd3a vi: some
simplifications" which happened before 1.23.0.
Mistyping filename on command line happens fairly often and it's better
we restore the old behaviour to avoid a few unnecessary flash writes and
sometimes efforts of debugging bugs caused by those unneeded stray
files.
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Along with it, there are other changes
- Check for uppercase X is removed as the expression will be always false and
:X itself is another totally different command in standard vim
- The status line will show number of written lines instead of lines requested
by the colon command. This is also how the standard vim is doing, though
the difference is that '!' has to be explicitly specified in vim to allow
partial writes
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Redundant help texts (one which only repeats the description)
are deleted.
Descriptions and help texts are trimmed.
Some config options are moved, even across menus.
No config option _names_ are changed.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Fix matching failure when plist is advanced while checking for buffered
lines - the lines in the hunk that are about to be added should be
skipped when checking for matching context.
Also add a valid test case that fails with current busybox and is fixed
by the change.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If we reach the end of plist it means the input has still data while we
are expecting EOF. Fix the log to avoid a crash.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The '' command in vi doesn't currently work because after the first
apostrophe is read, the next character is converted to an integer
between 0 and 25 inclusive (for indexing the array of marks). The
comparison of the converted character with an apostrophe therefore never
succeeds, meaning that '' doesn't do anything.
Based on the patch by Francis Rounds <francis.rounds@4bridgeworks.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
