$ PATH=/extra/path:/usr/sbin:/usr/bin:/sbin:/bin \
> busybox sh -xc 'command -V ls; command -V ls; command -Vp ls; command -vp ls'
+ command -V ls
ls is /bin/ls
+ command -V ls
ls is a tracked alias for /bin/ls
+ command -Vp ls
ls is a tracked alias for (null)
+ command -vp ls
Segmentation fault
describe_command should respect `path' argument. Looking up in the hash table
may gives incorrect index in entry.u.index and finally causes incorrect output
or SIGSEGV.
function old new delta
describe_command 386 313 -73
Signed-off-by: Youfu Zhang <zhangyoufu@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When using musl libc glob() a very long string can cause glob() to fail,
which leads to an out of memory error being raised by ash.
This can happen easily if a very long quoted string contains *, even
though no glob expansion should ever be performed on it (since it's
quoted).
Fix this by properly parsing control characters and escaping and only
accept unquoted metacharacters. While we're at it, unify this check for
libc and built-in glob expansion
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
bash has a feature: it restores termios after a successful wait for
a foreground job which had at least one stopped or sigkilled member.
The probable rationale is that SIGSTOP and SIGKILL can preclude task from
properly restoring tty state. Should we do this too?
A reproducer: ^Z an interactive python:
$ python
Python 2.7.12 (...)
>>> ^Z
{ python leaves tty in -icanon -echo state. We do survive that... }
[1]+ Stopped python
{ ...however, next program (python no.2) does not survive it well: }
$ python
Python 2.7.12 (...)
>>> Traceback (most recent call last):
{ above, I typed "qwerty<CR>", but -echo state is still in effect }
File "<stdin>", line 1, in <module>
NameError: name 'qwerty' is not defined
The implementation is modeled on bash code and seems to work.
However, I'm not sure we should do this. For one: what if I'd fg
the stopped python instead? It'll be confused by "restored" tty state.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Splitting these options makes it self-documenting about what
bash-compatible features we have.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Redundant help texts (one which only repeats the description)
are deleted.
Descriptions and help texts are trimmed.
Some config options are moved, even across menus.
No config option _names_ are changed.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
commit e19923f665 deleted clearredir()
call in shellexec():
ash: [REDIR] Remove redundant CLOEXEC calls
Upstream commit:
Now that we're marking file descriptors as CLOEXEC in savefd, we no longer
need to close them on exec or in setinputfd.
but it missed one place where we don't set CLOEXEC. Fixing this.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This would makes all ash options indented inside "ash" in menuconfig.
It appears that menuconfig has a limit at tracking multiple dependency
lines like this (it looks like a "diamond problem" but I'm not sure if
it is):
---ASH <----------
/ \ ASH_OPTIMIZE_FOR_SIZE
!NOMMU <-*----SH_IS_ASH <----[OR] <--ASH_INTERNAL_GLOB
\ / ASH_RANDOM_SUPPORT
---BASH_IS_ASH <-- [...]
The kconfig-language document [1] states that:
> If a menu entry somehow depends on the previous entry, it can be
> made a submenu of it. First, the previous (parent) symbol must be
> part of the dependency list and then one of these two conditions
> must be true:
> - the child entry must become invisible, if the parent is set to 'n'
[BusyBox ash used to satisfy this, but no longer does]
> - the child entry must only be visible, if the parent is visible
[BusyBox ash configs actually satisfy this, but because of
"diamond" above this might not be easily detected]
So I found out a direct workaround: by making ash options explicitly
depend on !NOMMU, we can tell menuconfig that rule 2 above is satisfied
without any more tracking.
---------------------
/ \
!NOMMU <-*-----ASH <-------- \
\ \ \ ASH_OPTIMIZE_FOR_SIZE
*---SH_IS_ASH <---[OR]-[AND] <--ASH_INTERNAL_GLOB
\ / ASH_RANDOM_SUPPORT
--BASH_IS_ASH <- [...]
So all ash options would now be indented under "ash".
[1] "Documentation/kbuild/kconfig-language.txt" in Linux kernel source
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The commit 'ash,hush: set exit code 127 in "sh /does/not/exist" case'
only partly implemented the dash commit '[ERROR] Allow the originator
of EXERROR to set the exit status'. This resulted in incorrect error
codes for a syntax error:
$ )
$ echo $?
0
or a redirection error for a special builtin:
$ rm -f xxx
$ eval cat <xxx
$ echo $?
0
Signed-off-by: Ron Yorston <rmy@pobox.com>
Reported-by: Martijn Dekker <martijn@inlv.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The same can be done for msh, but we are probably better off just deleting it
in a next versio or two.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In this example:
ash -c 'readonly x; echo $(command eval x=2)'
evalstring() is called after forkchild(), which calls popallfiles().
On exception, evalstring() will popfile().
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit:
Date: Sun, 22 Feb 2009 18:10:01 +0800
[JOBS] Fix dowait signal race
This test program by Alexey Gladkov can cause dash to enter an
infinite loop in waitcmd.
#!/bin/dash
trap "echo TRAP" USR1
stub() {
echo ">>> STUB $1" >&2
sleep $1
echo "<<< STUB $1" >&2
kill -USR1 $$
}
stub 3 &
stub 2 &
until { echo "###"; wait; } do
echo "*** $?"
done
The problem is that if we get a signal after the wait3 system
call has returned but before we get to INTON in dowait, then
we can jump back up to the top and lose the exit status. So
if we then wait for the job that has just exited, then it'll
stay there forever.
I made the original change that caused this bug to fix pretty
much the same bug but in the opposite direction. That is, if
we get a signal after we enter wait3 but before we hit the kernel
then it too can cause the wait to go on forever (assuming the
child doesn't exit).
In fact this is pretty much exactly the scenario that you'll
find in glibc's documentation on pause(). The solution is given
there too, in the form of sigsuspend, which is the only way to
do the check and wait atomically.
So this patch fixes Alexey's race without reintroducing the old
bug by converting the blocking wait3 to a sigsuspend.
In order to do this we need to set a signal handler for SIGCHLD,
so the code has been modified to always do that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
I failed to reproduce the bug (it requires precise timing), but it seems real.
function old new delta
dowait 284 463 +179
setsignal 301 326 +25
signal_handler 59 76 +17
ash_main 1481 1487 +6
localcmd 350 348 -2
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 4/1 up/down: 227/-2) Total: 225 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit 1:
Date: Sun, 22 Feb 2009 18:16:13 +0800
[SIGNAL] Remove EXSIG
Now that waitcmd no longer uses EXSIG we can remove it.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Upstream commit 2:
Date: Thu, 2 Oct 2014 21:07:55 +0800
[ERROR] Set exitstatus in onint
Currently the exit status when we receive SIGINT is set in evalcommand
which means that it doesn't always get set. For example, if you press
CTRL-C at the prompt of an interactive dash, the exit status is not
set to 130 as it is in many other Bourne shells.
This patch fixes this by moving the setting of the exit status into
onint which also simplifies evalcommand.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Upstream commit 3:
Date: Fri, 3 Oct 2014 14:07:07 +0800
[EVAL] Do not clobber exitstatus in evalcommand
All originators of EXERROR have been setting the exitstatus for
a while now. So it is no longer appropriate to set it explicitly
in evalcommand.
In fact doing so may cause the original exitstatus to be lost.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Last three coomits:
function old new delta
waitcmd 186 224 +38
dowait 276 284 +8
waitforjob 104 107 +3
localcmd 348 350 +2
showjobs 64 61 -3
forkshell 263 260 -3
raise_interrupt 93 67 -26
blocking_wait_with_raise_on_sig 40 - -40
evalcommand 1264 1208 -56
evaltree 809 498 -311
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This loses an insignificant optimization, but may allow backporting
of some recent-ish dash fixes.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This commit should have deleted these two statements:
commit c0e007663d
Author: Ron Yorston <rmy@pobox.com>
Date: Thu Oct 29 11:30:55 2015 +0000
ash: simplify EOF/newline handling in list parser
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit:
Date: Wed, 8 Sep 2010 20:07:26 +0800
[EXPAND] Fix ifsfirst/ifslastp leak
As it stands expandarg may return with a non-NULL ifslastp which
then confuses any subsequent ifsbreakup user that doesn't clear
it directly.
What's worse, if we get interrupted before we hit ifsfree in
expandarg we will leak memory.
This patch fixes this by always calling ifsfree in expandarg
thus ensuring that ifslastp is always NULL on the normal path.
It also adds an ifsfree call to the RESET path to ensure that
memory isn't leaked.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Fallout 1:
Date: Mon, 18 Oct 2010 10:55:42 +0800
[EXPAND] Fix ifsfirst/ifslastp leak in casematch
The commit f42e443bb511ed3224f09b4fcf0772438ebdbbfa
[EXPAND] Fix ifsfirst/ifslastp leak
revealed yet another ifsfirst/ifslastp leak in casematch.
Previously it was hidden because ifsfirst/ifslastp was cleared
unconditionally on entry (which caused the leakage of those
entries).
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Fallout 2:
Date: Sun, 28 Nov 2010 21:09:51 +0800
[EXPAND] Free IFS state in evalbackcmd
On Sun, Nov 07, 2010 at 04:04:20PM -0600, Jonathan Nieder wrote:
> Herbert Xu wrote:
> > commit f42e443bb511ed3224f09b4fcf0772438ebdbbfa
> > Author: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Wed Sep 8 20:07:26 2010 +0800
> >
> > [EXPAND] Fix ifsfirst/ifslastp leak
>
> Another puzzle bisecting to f42e443bb. This one comes from the
> grub-mkconfig script:
>
> $ sh -c 'datadir=/usr/share; pkgdatadir=${datadir}/`cat`' 2>&1 | cat -A
> cat: M-^\^M^F^HM-4^M^F^HM-(^M^F^H: No such file or directory$
> cat: M-(^M^F^H: No such file or directory$
>
> Still reproducible with 016b529. I'll try to find time to look into
> it, but thought you might like to know nevertheless.
This is the symptom of another leak. In this case evalbackcmd
occurs in the middle of an expansion (as it should) but the forked
child never clears the previous IFS state.
This patch adds the missing ifsfree call.
This wasn't as much of a problem as the previously discovered leaks
since all it means is that the child gets to carry around the parent's
expansion state and the child is usually short-lived.
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Fallout 3:
Date: Tue, 15 Mar 2011 16:01:34 +0800
[EXPAND] Free IFS state after here document expansion
Here's another bug bisecting to f42e443bb ([EXPAND] Fix
ifsfirst/ifslastp leak, 2010-09-08). It was found with the following
test case, based on the configure script for Tracker:
dash -x -c '
<<-_ACEOF
$@
_ACEOF
exec
' - abcdefgh
+
+ exec ?a
exec: 1: : Permission denied
The missing ifsfree call is in expandarg when it returns to openhere
during here document expansion.
Reported-by: Aurelien Jarno <aurel32@debian.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
function old new delta
ifsfree - 66 +66
ash_main 1490 1495 +5
argstr 1154 1159 +5
evalcase 275 270 -5
expandarg 972 888 -84
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 2/2 up/down: 76/-89) Total: -13 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
