If the motion command used to define the range of a change, yank or
delete fails the whole command should be rejected. BusyBox vi already
handled failed searches in these circumstances. Add some more cases:
- non-existent mark: d'x
- movement beyond end of file: c99999+ or 99999<<
This is implemented using a global variable which is set when a command
error is detected. Unlike the case of motion within a line it's
insufficient to check that the motion command doesn't move the cursor:
this fails to process 'LyL' correctly, for example, as the second 'L'
doesn't move the cursor.
function old new delta
indicate_error 75 82 +7
find_range 686 692 +6
do_cmd 4851 4852 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/0 up/down: 14/0) Total: 14 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In traditional vi and vim line motion commands ('+'/'-'/'j'/'k')
fail if the movement would exceed the bounds of the file. BusyBox vi
allowed such commands to succeed, leaving the cursor on the first or
last character of the file.
Make BusyBox vi work like vi/vim.
For the 'G'/'H'/'L' commands traditional vi treats an out of bounds
result as an error, vim doesn't. BusyBox vi behaves like vim, both
before and after this patch.
function old new delta
do_cmd 4785 4851 +66
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 66/0) Total: 66 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When ESC is entered to leave insert mode any autoindent should only
be removed if there's no content beyond the indent. This may be the
case if a line has been split by entering insert mode and then
entering a CR.
Add a check to ensure there's only a newline after the indent.
function old new delta
char_insert 912 929 +17
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 17/0) Total: 17 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Second reference to a field reallocs/moves Fields[] array, but first ref
still tries to use the element where it was before move.
function old new delta
fsrealloc 94 106 +12
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Testcase:
21 01 01 00 00 00 00 00 e7 01 01 01 ef 00 df b6
00 17 02 10 11 0f ff 00 16 00 00
Unfortunately, the bug is not reliably causing a segfault,
the behavior depends on what's in memory before the buffer.
function old new delta
unpack_lzma_stream 2762 2768 +6
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
...and we did not error-check it, and this is the only use of it:
function old new delta
inet_addr 37 - -37
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Even though it is _meant to be_ an IP address, in the wild servers sometimes
give bogus server ids, like 1.1.1.1
function old new delta
udhcpc_main 2551 2542 -9
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The default tabstop value should be set during early start up,
not reset for each new file.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When no line number is specified ':read' should place the inserted
text after the current line, not before.
This used to be correct but was broken when commit 0c42a6b07
(vi: fix empty line range regression) revealed a bug in commit
7a8ceb4eb (vi: changes to line addresses for colon commands).
function old new delta
colon 3960 3952 -8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-8) Total: -8 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The $RANDOM variable may be disabled on ash compilation but we can safelly use mktemp instead.
Signed-off-by: Sergey Ponomarev <stokito@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
On Sat, Feb 9, 2019 Cristian Ionescu-Idbohrn wrote:
> In my case (at work), I have to watch and prevent people from doing
> unportable things. For me, that's a burden.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Process substitution is a Korn shell feature that's also available
in bash and some other shells. This patch implements process
substitution in ash when ASH_BASH_COMPAT is enabled.
function old new delta
argstr 1386 1522 +136
strtodest - 52 +52
readtoken1 3346 3392 +46
.rodata 183206 183250 +44
unwindredir - 28 +28
cmdloop 365 372 +7
static.spclchars 10 12 +2
cmdputs 380 367 -13
exitreset 86 69 -17
evalcommand 1754 1737 -17
varvalue 675 634 -41
------------------------------------------------------------------------------
(add/remove: 2/0 grow/shrink: 5/4 up/down: 315/-88) Total: 227 bytes
text data bss dec hex filename
953967 4219 1904 960090 ea65a busybox_old
954192 4219 1904 960315 ea73b busybox_unstripped
v2: Replace array of file descriptors with a linked list.
Include tests that were unaccountably omitted from v1.
v3: Update linked list code to the intended version.
v4: Change order of conditional code in cmdputs().
v5: Use existing popredir() mechanism to manage file descriptors.
v6: Rebase to latest version of BusyBox ash. Reduce code churn.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The SOURCE_DATE_EPOCH is an effort of the Reproducible Builds
organization to make timestamps/build dates in compiled tools
deterministic over several repetitive builds.
Busybox shows by default the build date timestamp which changes whenever
compiled. To have a reasonable accurate build date while staying
reproducible, it's possible to use the *date of last source
modification* rather than the current time and date.
Further information on SOURCE_DATE_EPOCH are available online [1].
This patch modifies `confdata.c` so that the content of the
SOURCE_DATE_EPOCH env variable is used as timestamp.
To be independent of different timezones between builds, whenever
SOURCE_DATE_EPOCH is defined the GMT time is used.
[1]: https://reproducible-builds.org/docs/source-date-epoch/
Signed-off-by: Paul Spooren <mail@aparcar.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The original commit 3bef5d89b0 introduced an additional check
for an unset `opt_d` before doing word splitting. I'm unsure
why it's there in the first place, but the commit message also
describes a different behaviour than what -d actually does in
bash, while the code mostly does the right thing.
`opt_d` sets the line delimiter for read to stop reading and
should not affect word splitting.
Testcase:
$ echo qwe rty | { read -d Z a b; echo a:$a b:$b; }
a:qwe b:rty
function old new delta
shell_builtin_read 1314 1304 -10
Signed-off-by: Eicke Herbertz <wolletd@posteo.de>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When include/applets.h is re-generated
it generates code macros in include/applets.h e.g.
IF_XZCAT(APPLET_ODDNAME(xzcat, unxz, BB_DIR_USR_BIN, BB_SUID_DROP, xzcat))
...
IF_CHVT(APPLET_NOEXEC(chvt, chvt, BB_DIR_USR_BIN, BB_SUID_DROP, chvt))
...
sed is used to process source files like below to feed into this header
generation
sed -n 's@^//applet:@@p' "$srctree"/*/*.c "$srctree"/*/*/*.c
this means we let shell decide the order of .c files being fed into sed
tool, applets.h has code snippets thats generated out of code fragments
from these .c files and the order of the generated code depends on the
order of .c files being fed to sed and then piped to generate tool, even
though the generated code is logically same, it does result in re-odered
code in applets.h based on which shell was used during build on exact busybox
sources since sort order is different based on chosen locale and also default shell
being bash or dash
This sets the environment variable LC_ALL to the value C, which will
enforce bytewise sorting, irrespective of the shell
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
"-x vendor:VENDOR" will not be a trivial replacement of it:
(1) by default, we do send a vendor string ("udhcp BB_VER"),
will need code to preserve the default.
(2) -V '' currently disables vendor string. -x vendor:''
would not easily achieve that: it adds no option at all
(string options can't be empty), and default (1) would trigger.
To avoid that, we will need yet another hack to detect
-x vendor:'' and interpret that as "no vendor string at all".
IOW: removing -V is likely to increase code size, not decrease.
function old new delta
udhcpc_main 2563 2555 -8
.rodata 103251 103198 -53
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-61) Total: -61 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
While at it, rename bb_signals_recursive_norestart() to bb_signals_norestart():
"recursive" was implying we are setting SA_NODEFER allowing signal handler
to be entered recursively, but we do not do that.
function old new delta
bb_signals_norestart - 70 +70
startservice 380 394 +14
bb_signals_recursive_norestart 70 - -70
------------------------------------------------------------------------------
(add/remove: 1/1 grow/shrink: 1/0 up/down: 84/-70) Total: 14 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The TERM variable is usually set to "dumb" to indicate that the terminal
does not support any ANSI escape sequences. Presently, ls does not honor
this variable and outputs colors anyhow which results in unreadable
output, unless the user explicitly disables colors using `ls
--color=never`. The rational behind this change is that ls should "just
work" by default, even on dumb terminals.
For this reason, this patch adds a check which additionally consults the
TERM variable before printing any colors. This is analogous to the
existing check for ensuring that standard output is a tty. As such,
colors can still be forced with `--color=force`, even if TERM is set to
dumb.
function old new delta
is_TERM_dumb - 40 +40
ls_main 579 598 +19
.rodata 103246 103251 +5
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 2/0 up/down: 64/0) Total: 64 bytes
Signed-off-by: Sören Tempel <soeren+git@soeren-tempel.net>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Even following current Internet standards, it can be perfectly
legitimate to issue IPv4 addresses that end in .0 or .255 via DHCP --
this can happen whenever the network is larger than /8. For example,
10.3.4.0 and 10.3.4.255 are legitimate host addresses in 10/8 or 10.3/16.
(We also want to be able to issue .0 addresses in smaller networks
following our proposed kernel patch and standards changes.)
This behavior is already fully controllable by the user, simply by
setting start_ip and end_ip correctly. Users who don't want to issue
.0 or .255 should set start_ip greater than .0 or end_ip less than .255
and udhcpd will already respect these bounds. (This is also the case
for other DHCP servers -- the recommended example configurations will
default to a lower bound starting with .1 or some other value, which is
typically appropriate, but the user is still allowed to change this to
.0 -- or to a range that overlaps a .0 or .255 address -- if so desired.)
Signed-off-by: Seth David Schoen <schoen@loyalty.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
SRV lookups are supported since "6b4960155 nslookup: implement support
for SRV records" and should therefore be mentioned as a possible
QUERY_TYPE in the help message.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
