Upstream email:
This is actually composed of two bugs. First of all our tracking
of quotemark is wrong so anything after "$@" becomes quoted. Once
we fix that then the problem is that the first space character
after "$@" is not recognised as an IFS.
This patch fixes both.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit:
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 9 Mar 2018 23:07:53 +0800
parser: Fix single-quoted patterns in here-documents
The script
x=*
cat <<- EOF
${x#'*'}
EOF
prints * instead of nothing as it should. The problem is that
when we're in sqsyntax context in a here-document, we won't add
CTLESC as we should. This patch fixes it:
Reported-by: Harald van Dijk <harald@gigawatt.nl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This closes 10821.
Upstream patch:
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 9 Mar 2018 00:14:02 +0800
parser: Add syntax stack for recursive parsing
Without a stack of syntaxes we cannot correctly these two cases
together:
"${a#'$$'}"
"${a#"${b-'$$'}"}"
A recursive parser also helps in some other corner cases such
as nested arithmetic expansion with paratheses.
This patch adds a syntax stack allocated from the stack using
alloca. As a side-effect this allows us to remove the naked
backslashes for patterns within double-quotes, which means that
EXP_QPAT also has to go.
This patch also fixes removes any backslashes that precede right
braces when they are present within a parameter expansion context,
and backslashes that precede double quotes within inner double
quotes inside a parameter expansion in a here-document context.
The idea of a recursive parser is based on a patch by Harald van
Dijk.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
var_bash3, var_bash4 and var_bash6 tests are updated
with the output given by bash-4.3.43
With this patch, the following tests now pass for ash:
dollar_repl_slash_bash2.tests
squote_in_varexp2.tests
squote_in_varexp.tests
var_bash4.tests
function old new delta
readtoken1 2615 2874 +259
synstack_push - 54 +54
evalvar 574 571 -3
rmescapes 330 310 -20
subevalvar 1279 1258 -21
argstr 1146 1107 -39
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 1/4 up/down: 313/-83) Total: 230 bytes
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>
Upstream commit:
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Mar 15 18:27:30 2018 +0800
parser: Fix backquote support in here-document EOF mark
Currently using backquotes in a here-document EOF mark is broken
because dash tries to do command substitution on it. This patch
fixes it by checking whether we're looking for an EOF mark during
tokenisation.
Reported-by: Harald van Dijk <harald@gigawatt.nl>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
With added fix for quoted-ness of the EOF mark.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Part of upstream commit:
Date: Thu Mar 8 08:37:11 2018 +0100
Author: Harald van Dijk <harald@gigawatt.nl>
parser: use pgetc_eatbnl() in more places
dash has a pgetc_eatbnl function in parser.c which skips any
backslash-newline combinations. It's not used everywhere it could be.
There is also some duplicated backslash-newline handling elsewhere in
parser.c. Replace most of the calls to pgetc() with calls to
pgetc_eatbnl() and remove the duplicated backslash-newline handling.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Not adding "readtoken1(pgetc_eatbnl(), DQSYNTAX..." changes, since
readtoken1() handles the "starts with backslash + newline" case itself.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit:
Date: Tue Mar 6 17:40:37 2018 +0000
expand: 'nolog' and 'debug' options cause "$-" to wreak havoc
Op 29-03-17 om 20:02 schreef Martijn Dekker:
> Bug: if either the 'nolog' or the 'debug' option is set, trying to
> expand "$-" silently aborts parsing of an entire argument.
>
> $ dash -o nolog -c 'set -fuC; echo "|$- are the options|"; set +o nolog; echo "|$- are the options|"'
> |
> |uCf are the options|
> $ dash -o debug -c 'set -fuC; echo "|$- are the options|"; set +o debug; echo "|$- are the options|"'
> |
> |uCf are the options|
This turned out to be easy to fix. The routine producing the "$-"
expansion failed to skip options for which there is no option letter,
but only a long-form name. In dash, 'nolog' and 'debug' are currently
the only two such options. Patch below.
- Martijn
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In bbox ash, pipefail is the option which exhibited this.
Signed-off-by: Martijn Dekker <martijn@inlv.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Testcase:
set -- a ""; space=" "; printf "<%s>\n" "$@"$space
Before:
<a >
After:
<a>
<>
It usually does not bite since bbox forces -funsigned-char build.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
It usually does not bite since bbox forces -funsigned-char build.
But for some reason void linux people disabled that.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta
setjobctl 371 367 -4
setinputfile 226 220 -6
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-10) Total: -10 bytes
Based on patch by Mark Marshall <mark.marshall@omicronenergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta
cpio_main 588 596 +8
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When using ifplugd on a RNDIS interface with monitor mode, using
SIOCSIFFLAGS seems to fail with EADDRNOTAVAIL. Treat it the same
as if iface disappeared again.
This has been observed on a Tegra TK1 using Linux 4.14. There seem
to be a race when the kernel is creating the device:
ifplugd(usb0): started: BusyBox v1.24.1 (2018-03-27 09:47:48 CEST)
ifplugd(usb0): interface doesn't exist, waiting
ifplugd(usb0): interface appeared
ifplugd(usb0): upping interface
ifplugd(usb0): setting interface flags failed: Cannot assign requested address
<exit>
With this patch ifplugd is successful in upping the device the second
time around:
ifplugd(usb0): upping interface
ifplugd(usb0): using SIOCETHTOOL detection mode
ifplugd(usb0): interface appeared
ifplugd(usb0): upping interface
ifplugd(usb0): setting interface flags failed: Cannot assign requested address
ifplugd(usb0): interface appeared
ifplugd(usb0): upping interface
ifplugd(usb0): using SIOCETHTOOL detection mode
ifplugd(usb0): link is up
ifplugd(usb0): executing '/etc/ifplugd/ifplugd.usb.action usb0 up'
ifplugd up
ifplugd(usb0): exit code: 0
function old new delta
up_iface 120 127 +7
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
For some setups (E.G. for supporting different screen resolutions),
positioning the image somewhere else than the top left corner may be
interesting.
Add support for IMG_LEFT/IMG_TOP settings to specify the image location,
similar to how it is done for the progress bar.
function old new delta
fbsplash_main 994 1038 +44
static.param_names 57 74 +17
packed_usage 32631 32647 +16
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/0 up/down: 77/0) Total: 77 bytes
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Kernel will surely inform us in FITRIM does not make sense on a given file.
function old new delta
fstrim_main 241 221 -20
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Based on a patch by Mark Marshall <mark.marshall@omicronenergy.com>
function old new delta
dup_CLOEXEC - 49 +49
fcntl_F_DUPFD 46 - -46
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Interface may not exist because it got deleted by an ifdown hook script
earlier. This may happen when a virtual interface, such as VLAN, has multiple
iface blocks defined.
function old new delta
static_down6 14 40 +26
static_down 54 70 +16
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 42/0) Total: 42 bytes
Signed-off-by: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If we don't ask for numerical output, and the symbolic look-up failed
we used to get "(null)", but the numeric output would be better.
function old new delta
ip_port_str 109 121 +12
Signed-off-by: Mark Marshall <mark.marshall@omicronenergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The wrong character was used to indicate options taking an integer
parameter.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
EINTR _should_ only happen on two signals we trap, and safe_poll
_should_ work here just fine, but there were kernel bugs where spurious EINTRs
happen (e.g. on ptrace attach). Be safe.
function old new delta
udhcpd_main 1437 1468 +31
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Fixes:
commit 52a515d187
"udhcp: use poll() instead of select()"
Feb 16 2017
udhcp_sp_read() is meant to check whether signal pipe indeed has some data to read.
In the above commit, it was changed as follows:
- if (!FD_ISSET(signal_pipe.rd, rfds))
+ if (!pfds[0].revents)
return 0;
The problem is, the check was working for select() purely by accident.
Caught signal interrupts select()/poll() syscalls, they return with EINTR
(regardless of SA_RESTART flag in sigaction). _Then_ signal handler is invoked.
IOW: they can't see any changes to fd state caused by signal haldler
(in our case, signal handler makes signal pipe ready to be read).
For select(), it means that rfds[] bit array is unmodified, bit of signal
pipe's read fd is still set, and the above check "works": it thinks select()
says there is data to read.
This accident does not work for poll(): .revents stays clear, and we do not
try reading signal pipe as we should. In udhcpd, we fall through and block
in socket read. Further SIGTERM signals simply cause socket read to be
interrupted and then restarted (since SIGTERM handler has SA_RESTART=1).
Fixing this as follows: remove the check altogether. Set signal pipe read fd
to nonblocking mode. Always read it in udhcp_sp_read().
If read fails, assume it's EAGAIN and return 0 ("no signal seen").
udhcpd avoids reading signal pipe on every recvd packet by looping if EINTR
(using safe_poll()) - thus ensuring we have correct .revents for all fds -
and calling udhcp_sp_read() only if pfds[0].revents!=0.
udhcpc performs much fewer reads (typically it sleeps >99.999% of the time),
there is no need to optimize it: can call udhcp_sp_read() after each poll
unconditionally.
To robustify socket reads, unconditionally set pfds[1].revents=0
in udhcp_sp_fd_set() (which is before poll), and check it before reading
network socket in udhcpd.
TODO:
This might still fail: if pfds[1].revents=POLLIN, socket read may still block.
There are rare cases when select/poll indicates that data can be read,
but then actual read still blocks (one such case is UDP packets with
wrong checksum). General advise is, if you use a poll/select loop,
keep all your fds nonblocking.
Maybe we should also do that to our network sockets?
function old new delta
udhcp_sp_setup 55 65 +10
udhcp_sp_fd_set 54 60 +6
udhcp_sp_read 46 36 -10
udhcpd_main 1451 1437 -14
udhcpc_main 2723 2708 -15
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/3 up/down: 16/-39) Total: -23 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
