The memcpy invocations in the subCommand function, modified by this
commit, previously used memcpy with overlapping memory regions. This is
undefined behavior. On Alpine Linux, it causes BusyBox ed to crash since
we compile BusyBox with -D_FORTIFY_SOURCE=2 and our fortify-headers
implementation catches this source of undefined behavior [0]. The issue
can only be triggered if the replacement string is the same size or
shorter than the old string.
Looking at the code, it seems to me that a memmove(3) is what was
actually intended here, this commit modifies the code accordingly.
[0]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13504
Signed-off-by: Sören Tempel <soeren+git@soeren-tempel.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Busybox vi provides the 'ZZ' command to save and close
the similar 'ZQ' command just exits without saving.
function old new delta
do_cmd 4222 4244 +22
Signed-off-by: Grob Grobmann <grobgrobmann@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
fixes https://bugs.busybox.net/show_bug.cgi?id=14781
function old new delta
evaluate 3343 3357 +14
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When the 'cc' command is invoked with autoindent enabled it
should use the indent of the first line being changed.
The size of the indent has to be established before char_insert()
is called as the lines being changed are deleted. Introduce a
new global variable, newindent, to handle this. The indentcol
global is now effectively a static variable in char_insert().
function old new delta
do_cmd 4247 4308 +61
vi_main 416 422 +6
char_insert 891 875 -16
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 67/-16) Total: 51 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Suppose autoindent is enabled and we have a line with an initial
tab where we want to split the words onto separate lines:
split the words
One way to do this is with the sequence 'f r<CR>;r<CR>', but in
BusyBox vi the result is:
split
he
words
This is a regression introduced by commit 9659a8db1 (vi: remove
autoindent from otherwise empty lines). The amount of indentation
is being recorded when the 'r' command inserts a newline but
isn't subsequently reset. A fix is to only record the indent
when in insert or replace mode. Proper handling of the 'o' and
'O' commands then requires them to switch to insert mode before
calling char_insert() to insert a newline.
function old new delta
char_insert 884 891 +7
do_cmd 4243 4247 +4
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/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>
Colon and search commands are entered on the status line. Since
the cursor position wasn't being tracked backspacing over a tab
resulted in a mismatch between the actual and apparent content
of the command.
function old new delta
get_input_line 178 180 +2
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 2/0) Total: 2 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
In replace mode ('R' command) the backspace character should get
special treatment:
- backspace only goes back to the start of the replacement;
- backspacing over replaced characters restores the original text.
Prior to this commit BusyBox vi deleted the characters both before
and after the cursor in replace mode.
function old new delta
undo_pop - 235 +235
char_insert 858 884 +26
indicate_error 81 84 +3
find_range 654 657 +3
static.text_yank 77 79 +2
do_cmd 4486 4243 -243
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 4/1 up/down: 269/-243) Total: 26 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In order to improve compatibility with GNU cmp add support for long
options to busybox cmp.
function old new delta
static.cmp_longopts - 36 +36
cmp_main 589 594 +5
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 1/0 up/down: 41/0) Total: 41 bytes
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Apart from the -p option, POSIX also mandates an -s option which
suppresses the output of byte counts for the e, E, r, and w command.
From these commands, Busybox ed presently only implements the r and w
commands. This commit ensures that these two command do not output any
bytes counts when the -s option is passed. The shell escape command,
also effected by the -s option, is not implemented by Busybox at the
moment.
function old new delta
packed_usage 34096 34115 +19
doCommands 1887 1900 +13
readLines 388 397 +9
.rodata 104196 104200 +4
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 4/0 up/down: 45/0) Total: 45 bytes
Signed-off-by: Sören Tempel <soeren+git@soeren-tempel.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
It is perfectly valid to start a regex with ^ and have other patterns
with \| that can match more than once, e.g. the following example
should print ca, as illustrated with gnu sed:
$ echo 'abca' | sed -e 's/^a\|b//g'
ca
busybox before patch:
$ echo 'abca' | busybox sed -e 's/^a\|b//g'
bca
busybox after patch:
$ echo 'abca' | ./busybox sed -e 's/^a\|b//g'
ca
regcomp handles ^ perfectly well as illustrated with the second 'a' that
did not match in the example, we ca leave the non-repeating to it if
appropriate.
The check had been added before using regcomp and was required at the
time (f36635cec6) but no longer makes sense now.
(tested with glibc and musl libc)
function old new delta
add_cmd 1189 1176 -13
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
POSIX.1-2008 mandates the following regarding the read command:
If the read is successful, and -s was not specified, the number
of bytes read shall be written to standard output in the
following format:
"%d\n", <number of bytes read>
This commit aligns the output of busybox ed with POSIX.1-2008 by
removing the file name from the output for the read command.
This slipped through in 4836a0708fd0aaeb82871a3762b40fcf4b61e812.
function old new delta
.rodata 104203 104196 -7
readLines 409 388 -21
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-28) Total: -28 bytes
Signed-off-by: Sören Tempel <soeren+git@soeren-tempel.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
POSIX.1-2008 mandates the following regarding the file command-line
argument:
If the file argument is given, ed shall simulate an e command
on the file named by the pathname […]
The specification for the e command mandates the following behaviour
regarding the current line number in POSIX.1-2008:
The current line number shall be set to the address of the last
line of the buffer.
However, without this commit, busybox ed will set the current line
number to 1 if a file is given on the command-line and this file is not
empty (lastNum != 0). This is incorrect and fixed in this commit by not
modifying the current line number in ed_main(). As such, the current
line number will be zero for empty files and otherwise be set to the
address of the last line of the buffer.
function old new delta
ed_main 144 128 -16
Signed-off-by: Sören Tempel <soeren+git@soeren-tempel.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The POSIX.1-2008 specification of ed(1) mandates two command-line
options: -p (for specifying a prompt string) and -s (to suppress writing
of byte counts). This commit adds support for the former. Furthermore,
it also changes the default prompt string to an empty string (instead
of ": ") since this is also mandated by POSIX:
-p string Use string as the prompt string when in command mode.
By default, there shall be no prompt string.
function old new delta
ed_main 112 144 +32
packed_usage 34074 34097 +23
doCommands 1889 1887 -2
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 55/-2) Total: 53 bytes
Signed-off-by: Sören Tempel <soeren+git@soeren-tempel.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Add support to for "-n" to cmp in order to compare at most n bytes.
function old new delta
cmp_main 552 589 +37
.rodata 104198 104203 +5
packed_usage 34102 34074 -28
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/1 up/down: 42/-28) Total: 14 bytes
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
POSIX.1-2008 mandates the following regarding the write command:
If the command is successful, the number of bytes written shall
be written to standard output, unless the -s option was
specified, in the following format:
"%d\n", <number of bytes written>
function old new delta
readLines 447 409 -38
doCommands 1940 1889 -51
.rodata 104219 104163 -56
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-145) Total: -145 bytes
Signed-off-by: Sören Tempel <soeren+git@soeren-tempel.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Commit 7d06d6e18 (awk: fix printf %%) can cause awk printf to read
beyond the end of a strduped buffer:
2349 while (*f && *f != '%')
2350 f++;
2351 c = *++f;
If the loop terminates because a NUL character is detected the
character after the NUL is read. This can result in failures
depending on the value of that character.
function old new delta
awk_printf 672 665 -7
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
A refactor of the awk printf code in
e2e3802987
appears to have broken the printf interpretation of two percent signs,
which normally outputs only one percent sign.
The patch below brings busybox awk printf behavior back into alignment
with the pre-e2e380 behavior, the busybox printf util, and other common
(awk and non-awk) printf implementations.
function old new delta
awk_printf 626 672 +46
Signed-off-by: Daniel Thau <danthau at bedrocklinux.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Improved error messages:
- specify when a search fails or a mark isn't set;
- warn when line addresses are out of range or when a range of
lines is reversed.
Addresses are limited to the number of lines in the file so a
command like ':2000000000' (go to the two billionth line) no
longer causes a long pause.
Improved vi compatibility of '+' and '-' operators that aren't
followed immediately by a number:
:4+++= 7
:3-2= 1
:3 - 2= 4 (yes, really!)
In a command like ':,$' the empty address before the separator now
correctly refers to the current line. (The similar case ':1,' was
already being handled.)
And all with a tidy reduction in bloat (32-bit build):
function old new delta
colon 4029 4069 +40
.rodata 99348 99253 -95
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/1 up/down: 40/-95) Total: -55 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Simplify the function print_literal() which is used to format a
string that may contain unprintable characters or control
characters.
- Unprintable characters were being displayed in normal text rather
than the bold used for the rest of the message. This doesn't seem
particularly helpful and it upsets the calculation of the width
of the message in show_status_line(). Use '?' rather than '.' for
unprintable characters.
- Newlines in the string were displayed as both '^J' and '$', which
is somewhat redundant.
function old new delta
not_implemented 199 108 -91
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-91) Total: -91 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The '/' and '?' search commands wrap to the other end of the buffer
if the search target isn't found. When searches are used to specify
addresses in colon commands they should do the same.
(In traditional vi and vim this behaviour is controlled by the
'wrapscan' option. BusyBox vi doesn't have this option and always
uses the default behaviour.)
function old new delta
colon 4033 4077 +44
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 44/0) Total: 44 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Run initialisation commands from ~/.exrc. As with EXINIT these
commands are processed before the first file is loaded.
Commands starting with double quotes are ignored. This is how
comments are often included in .exrc.
function old new delta
vi_main 268 406 +138
colon 4033 4071 +38
.rodata 108411 108442 +31
packed_usage 34128 34118 -10
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/1 up/down: 207/-10) Total: 197 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Rewrite handling of command line arguments so any number of -c
commands will be processed. Previously only two -c commands
were allowed (or one if EXINIT was set).
Process commands from EXINIT before the first file is read into
memory, as specified by POSIX.
function old new delta
run_cmds - 77 +77
.rodata 108410 108411 +1
vi_main 305 268 -37
edit_file 816 764 -52
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 1/2 up/down: 78/-89) Total: -11 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
'; BEGIN {...}' and 'BEGIN {...} ;; {...}' are not accepted by gawk
function old new delta
parse_program 332 353 +21
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Building with FEATURE_VI_REGEX_SEARCH enabled fails.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
When regular expressions are allowed in search commands it becomes
possible to escape the delimiter in search/replace commands. For
example, this command will replace '/abc' with '/abc/':
:s/\/abc/\/abc\//g
The code to split the command into 'find' and 'replace' strings
should allow for this possibility.
VI_REGEX_SEARCH isn't enabled by default. When it is:
function old new delta
strchr_backslash - 38 +38
colon 4378 4373 -5
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 0/1 up/down: 38/-5) Total: 33 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
BusyBox vi has never supported the use of regular expressions in
search/replace (':s') commands. Implement this using GNU regex
when VI_REGEX_SEARCH is enabled.
The implementation:
- uses basic regular expressions, to match those used in the search
command;
- only supports substitution of back references ('\0' - '\9') in the
replacement string. Any other character following a backslash is
treated as that literal character.
VI_REGEX_SEARCH isn't enabled in the default build. In that case:
function old new delta
colon 4036 4033 -3
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-3) Total: -3 bytes
When VI_REGEX_SEARCH is enabled:
function old new delta
colon 4036 4378 +342
.rodata 108207 108229 +22
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 364/0) Total: 364 bytes
v2: Rebase. Code shrink. Ensure empty replacement string is null terminated.
Signed-off-by: Andrey Dobrovolsky <andrey.dobrovolsky.odessa@gmail.com>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Suppose we search for a git conflict marker '<<<<<<< HEAD' using
the command '/^<<<'. Using 'n' to go to the next match finds
'<<<' on the current line, apparently ignoring the '^' anchor.
Set a flag in the compiled regular expression to indicate that the
start of the string should not be considered a beginning-of-line
anchor. An exception has to be made when the search starts from
the beginning of the file. Make a similar change for end-of-line
anchors.
This doesn't affect a default build with VI_REGEX_SEARCH disabled.
When it's enabled:
function old new delta
char_search 247 285 +38
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Both traditional vi and vim use basic regular expressions for
search. Also, they don't allow matches to extend across line
endings. Thus with the file:
123
234
the search '/2.*4$' should find the second '2', not the first.
Make BusyBox vi do the same.
Whether or not VI_REGEX_SEARCH is enabled:
function old new delta
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0) Total: 0 bytes
Signed-off-by: Andrey Dobrovolsky <andrey.dobrovolsky.odessa@gmail.com>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Commit 7b93e317c (vi: enable 'dG' command. Closes 11801) allowed
'G' to be used as a range specifier for change/yank/delete
operations.
Add similar support for 'gg'. This requires setting the 'cmd_error'
flag if 'g' is followed by any character other than another 'g'.
function old new delta
do_cmd 4852 4860 +8
.rodata 108179 108180 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 9/0) Total: 9 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Example where it wasn't working:
awk 'BEGIN { printf "qwe %s rty %c uio\n", "a", 0, "c" }'
- the NUL printing in %c caused premature stop of printing.
function old new delta
awk_printf 593 596 +3
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
