> I'm trying to connect to a Korenix 3005 switch through telnet
> for management purposes, and all is well except for the backspace character
> - seems like my switch doesn't handle it too well and instead of erasing
> the last character all it does is print some garbage to the screen.
> I've had the same issue before while using putty, but saw a solution that
> suggests to enable "Telnet special commands" in the options menu, and it
> worked.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When crond is built with FEATURE_CROND_SPECIAL_TIMES enabled, it creates
a file called 'crond.reboot' at CONFIG_PID_FILE_PATH, but if
FEATURE_PIDFILE is disabled, this will be an empty string and the file
will be created in the root directory, which is undesirable.
This commit makes PID_FILE_PATH depend on FEATURE_CROND_SPECIAL_TIMES as
well as FEATURE_PIDFILE so that you get sensible behaviour in crond when
FEATURE_PIDFILE is switched off.
Signed-off-by: James Byrne <james.byrne@origamienergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If sub is empty, avoids an infinite loop.
function old new delta
count_strstr 45 63 +18
Signed-off-by: Martin Lewis <martin.lewis.x84@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Changed safe_read to be symmetrical to safe_write, it shall
never return EINTR because it calls read multiple times,
the error is considered transient.
function old new delta
safe_read 44 57 +13
Signed-off-by: Martin Lewis <martin.lewis.x84@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Some 32-bit architectures no longer have the 32-bit time_t syscalls.
Instead they have suffixed syscalls that returns a 64-bit time_t. If
the architecture doesn't have the non-suffixed syscall and is using a
64-bit time_t let's use the suffixed syscall instead.
This fixes build issues when building for RISC-V 32-bit with 5.1+ kernel
headers.
If an architecture only supports the suffixed syscalls, but is still
using a 32-bit time_t report a compilation error. This avoids us have to
deal with converting between 64-bit and 32-bit values. There are
currently no architectures where this is the case.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Some 32-bit architectures no longer have the 32-bit time_t syscalls.
Instead they have suffixed syscalls that returns a 64-bit time_t. If
the architecture doesn't have the non-suffixed syscall and is using a
64-bit time_t let's use the suffixed syscall instead.
This fixes build issues when building for RISC-V 32-bit with 5.1+ kernel
headers.
If an architecture only supports the suffixed syscalls, but is still
using a 32-bit time_t report a compilation error. This avoids us have to
deal with converting between 64-bit and 32-bit values. There are
currently no architectures where this is the case.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Some 32-bit architectures no longer have the 32-bit time_t syscalls.
Instead they have suffixed syscalls that returns a 64-bit time_t. If
the architecture doesn't have the non-suffixed syscall and is using a
64-bit time_t let's use the suffixed syscall instead.
This fixes build issues when building for RISC-V 32-bit with 5.1+ kernel
headers.
If an architecture only supports the suffixed syscalls, but is still
using a 32-bit time_t fall back to the libc call.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The following caused udhcpc to segfault:
busybox udhcpc -i lo -s /dev/null -x 0x3d:
function old new delta
udhcp_str2optset 629 641 +12
Signed-off-by: Michal Kazior <michal@plume.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The output of the command "route -n -A inet6" may be corrupted
due to partially initialized structure snaddr6 in the function
INET6_displayroutes.
Signed-off-by: Tomas Paukrt <tomaspaukrt@email.cz>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
GNU tee does this only with -p, which we don't have yet.
function old new delta
tee_main 306 295 -11
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Without the 'U' unsigned suffix, gcc will throw a "integer constant is
so large that it is unsigned" warning.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Some hosting services like sourceforge perform a lot of relocations
before actually serving the file. Example of current limitation:
busybox wget http://sourceforge.net/projects/fluxbox/files/fluxbox/1.3.7/fluxbox-1.3.7.tar.xz
Connecting to sourceforge.net (216.105.38.13:80)
Connecting to sourceforge.net (216.105.38.13:443)
Connecting to sourceforge.net (216.105.38.13:443)
Connecting to sourceforge.net (216.105.38.13:443)
Connecting to downloads.sourceforge.net (216.105.38.13:443)
wget: too many redirections
Signed-off-by: David Demelier <markand@malikania.fr>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Converted a few 16-bit variables and small arrays to 32-bit.
Stopped pulling desc->FOO members into temporary local variables
in gen_bitlen(): on register-starved arches, this is a loss,
temporaries go into stack slots.
Sprinkled a few "const" on pointer arguments.
function old new delta
pack_gzip 742 745 +3
gen_codes 101 97 -4
build_tree 886 833 -53
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/2 up/down: 3/-57) Total: -54 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
With this change, GNU gzip -n and BusyBox gzip now produce identical output
assuming that CONFIG_GZIP_FAST=2.
>> Excuse me, but I wonder one thing: Why should we follow
>> strictly with gzip on the no-options default behavior?
> First, the default 6 compression level is a de-facto standard. BSD gzip
> and Apple gzip (on macOS) use this default as well. So there is a
> reasonable expectation that different gzip implementations act the same.
> For instance, if the default for busybox gzip becomes 9, then someone
> writing a script using busybox gzip could reasonably expect that the
> compression level will still be 9 when the same script is run on another
> system. That would be wrong. Implementations should not deviate from
> de-facto standards without a strong reason.
>
> Second, the inherent reason for this default has not gone away. While
> processor speeds have exploded since the default was set, so has the
> typical size of compressed files. Multiple gigabytes are nothing unusual
> these days. And gzip is often used for compression on the fly, precisely
> because it offers a good compromise between speed and compression ratio.
> So I believe 6 continues to be a reasonable default.
function old new delta
deflate 939 927 -12
Signed-off-by: Daniel Edgecumbe <git@esotericnonsense.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
With this change and CONFIG_GZIP_FAST=2, CONFIG_FEATURE_GZIP_LEVELS=y,
GNU gzip and BusyBox gzip now produce identical output at each compression
level (excluding 1..3, as BusyBox does not implement these levels).
Signed-off-by: Daniel Edgecumbe <git@esotericnonsense.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Fixes an off-by-one that actually resulted in level 7 being used
Signed-off-by: Daniel Edgecumbe <git@esotericnonsense.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta
xc_program_print 712 735 +23
Signed-off-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta
zxc_vm_process 6884 6891 +7
Signed-off-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This matches the behaviour of both GNU dc (as specified in
its man page), and BSD dc (where stack_popstring() pops
only if the head is a string.)
Add a couple of tests to verify this behavior.
function old new delta
zxc_vm_process 6882 6884 +2
Signed-off-by: Brian Foley <bpfoley@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This prevents first update from showing incorrect CPU usage data
function old new delta
handle_input 620 643 +23
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Commit d1a2fa2a4 (ash: catch error in arithmetic expansion in PS1)
catches all exceptions raised by expandarg(). Some exceptions, such as
the EXEXIT raised when command expansion is used, are expected:
export PS1='$(echo "$ ")'
These should be processed normally or the shell hangs at the prompt.
function old new delta
expandstr 344 353 +9
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/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>
