"rm -i FILE" and "yes" can now be interrupted by ^C in hush.
This also now works:
$ usleep 19999999
^C
$ echo $?
130
function old new delta
run_pipe 1668 1711 +43
pseudo_exec_argv 312 321 +9
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 52/0) Total: 52 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream dash commit:
Date: Sun, 13 Jul 2008 19:20:10 +0800
Fixed 3,4-argument cases for test per POSIX
----- Forwarded message from Gerrit Pape <pape@smarden.org> -----
Subject: Bug#455828: dash: 4-argument test "test \( ! -e \)" yields an error
Date: Fri, 28 Dec 2007 08:53:29 +0000
From: Gerrit Pape <pape@smarden.org>
To: Vincent Lefevre <vincent@vinc17.org>, 455828@bugs.debian.org
On Thu, Dec 27, 2007 at 06:23:20PM +0100, Vincent Lefevre wrote:
> On 2007-12-27 16:00:06 +0000, Gerrit Pape wrote:
> > On Wed, Dec 12, 2007 at 02:18:47AM +0100, Vincent Lefevre wrote:
> > > According to POSIX[*], "test \( ! -e \)" is a 4-argument test and is
> > > here equivalent to "test ! -e". But dash (like ksh93 and bash) yields
> > > an error:
> > >
> > > $ test \( ! -e \) || echo $?
> > > test: 1: closing paren expected
> > > 2
> > > $ test ! -e || echo $?
> > > 1
> >
> > Hi Vincent,
> >
> > the -e switch to test takes an argument, a pathname.
>
> According to POSIX, in both above examples, "-e" is *not* a switch,
> just a string.
>
> test \( ! -e \)
>
> means: return true if the string "-e" is empty, otherwhise return false.
> The error in dash is that it incorrectly thinks that "-e" is a switch in
> this context.
I see, you're right. Thanks, Gerrit.
----- End forwarded message -----
This patch hard-codes the 3,4-argument cases in the way required by
POSIX.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
function old new delta
test_main 370 421 +51
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Currently od_bloaty does this:
$ /bin/echo -en '\x00\x00\x00\x00\x00\x00\x00\x00' | busybox od -f
od: invalid character 'F' in type string 'fF'
$ /bin/echo -en '\x00\x00\x00\x00\x00\x00\x00\x00' | busybox od -t fD
od: invalid character 'D' in type string 'fD'
$ /bin/echo -en '\x00\x00\x00\x00\x00\x00\x00\x00' | busybox od -t f
0000000
0000010
The first two occur because the alphabetic length specifier isn't being
properly skipped. The third is due to the empty length specifier being
treated as alphabetic so we fall off the end of the FDL_sizeof array with
undetermined consequences. Coreutils defaults to printing a double in
this case.
With this patch the output is:
$ /bin/echo -en '\x00\x00\x00\x00\x00\x00\x00\x00' | ./busybox od -f
0000000 0.0000000e+00 0.0000000e+00
0000010
$ /bin/echo -en '\x00\x00\x00\x00\x00\x00\x00\x00' | ./busybox od -t fD
0000000 0.000000000000000e+00
0000010
$ /bin/echo -en '\x00\x00\x00\x00\x00\x00\x00\x00' | ./busybox od -t f
0000000 0.000000000000000e+00
0000010
I guess nobody uses BusyBox od to print floating point numbers.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
One of the tests for printf checks for an invalid bare '%' in the
format string:
$ busybox printf '%' a b c
printf: %: invalid format
On x86_64 a slightly different test doesn't work correctly:
$ busybox printf '%' d e f
printf: invalid number 'd'
printf: invalid number 'e'
printf: invalid number 'f'
On other platforms the test fails randomly depending on how the
arguments are laid out in memory.
There are two places in the code where strchr is used to determine if
a character in the format string is valid. However, strchr also returns
a valid pointer if the character being searched for is the null terminator
thus causing the code to incorrectly suppose that a valid character has
been found.
Add explicit checks for the null terminator.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When these options were introduced in d88f94a5df
it provides no config options to compile them out. Now provide one.
Introduce config FEATURE_CATN.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
"""
For example, given input file:
foo
bar
baz
after shuffling the input file, foo will never end up back on the first line.
This came to light when I ran into a use-case where someone was selecting
a random line from a file using shuf | head -n 1, and the results on busybox
were showing a statistical anomaly (as in, the first line would never ever
be picked) vs the same process running on environments that had gnu coreutils
installed.
On line https://git.busybox.net/busybox/tree/coreutils/shuf.c#n56 it uses
r %= i, which will result in 0 <= r < i, while the algorithm specifies
0 <= r <= i.
"""
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Declaration of ls_longopts and initialization of applet_long_options
were incorrectly guarded with ENABLE_FEATURE_LS_COLOR; that yielded a
"ls: NO_OPT: \xff" error message when long options were selected and
color support was not. This patch ensures long options are
initialized separately from color support.
Signed-off-by: Laurent Bercot <ska-dietlibc@skarnet.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
