mirror of
https://git.busybox.net/busybox
synced 2026-01-31 16:43:21 +00:00
ba0f94458b
An alias expansion immediately followed by '<' and a newline is
parsed incorrectly:
~ $ alias x='echo yo'
~ $ x<
yo
~ $
sh: syntax error: unexpected newline
The echo is executed and an error is printed on the next command
submission. In dash the echo isn't executed and the error is
reported immediately:
$ alias x='echo yo'
$ x<
dash: 3: Syntax error: newline unexpected
$
The difference between BusyBox and dash is that BusyBox supports
bash-style process substitution and output redirection. These
require checking for '<(', '>(' and '&>' in readtoken1().
In the case above, when the end of the alias is found, the '<' and
the following newline are both read to check for '<('. Since
there's no match both characters are pushed back.
The next input is obtained by reading the expansion of the alias.
Once this string is exhausted the next call to __pgetc() calls
preadbuffer() which pops the string, reverts to the previous input
and recursively calls __pgetc(). This request is satisified from
the pungetc buffer. But the first __pgetc() doesn't know this:
it sees the character has come from preadbuffer() so it (incorrectly)
updates the pungetc buffer.
Resolve the issue by moving the code to pop the string and fetch
the next character up from preadbuffer() into __pgetc().
function old new delta
pgetc 28 589 +561
__pgetc 607 - -607
------------------------------------------------------------------------------
(add/remove: 0/1 grow/shrink: 1/0 up/down: 561/-607) Total: -46 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
||
|---|---|---|
| .. | ||
| ash_test | ||
| hush_test | ||
| ash.c | ||
| ash_doc.txt | ||
| ash_ptr_hack.c | ||
| ash_remove_unnecessary_code_in_backquote_expansion.patch | ||
| brace.txt | ||
| Config.src | ||
| cttyhack.c | ||
| hush.c | ||
| hush_doc.txt | ||
| hush_leaktool.sh | ||
| Kbuild.src | ||
| match.c | ||
| match.h | ||
| math.c | ||
| math.h | ||
| random.c | ||
| random.h | ||
| README | ||
| README.job | ||
| shell_common.c | ||
| shell_common.h | ||
http://www.opengroup.org/onlinepubs/9699919799/ Open Group Base Specifications Issue 7 http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html Shell & Utilities It says that any of the standard utilities may be implemented as a regular shell built-in. It gives a list of utilities which are usually implemented that way (and some of them can only be implemented as built-ins, like "alias"): alias bg cd command false fc fg getopts jobs kill newgrp pwd read true umask unalias wait http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html Shell Command Language It says that shell must implement special built-ins. Special built-ins differ from regular ones by the fact that variable assignments done on special builtin are *PRESERVED*. That is, VAR=VAL special_builtin; echo $VAR should print VAL. (Another distinction is that an error in special built-in should abort the shell, but this is not such a critical difference, and moreover, at least bash's "set" does not follow this rule, which is even codified in autoconf configure logic now...) List of special builtins: . file : [argument...] break [n] continue [n] eval [argument...] exec [command [argument...]] exit [n] export name[=word]... export -p readonly name[=word]... readonly -p return [n] set [-abCefhmnuvx] [-o option] [argument...] set [+abCefhmnuvx] [+o option] [argument...] set -- [argument...] set -o set +o shift [n] times trap n [condition...] trap [action condition...] unset [-fv] name... In practice, no one uses this obscure feature - none of these builtins gives any special reasons to play such dirty tricks. However. This section also says that *function invocation* should act similar to special built-in. That is, variable assignments done on function invocation should be preserved after function invocation. This is significant: it is not unthinkable to want to run a function with some variables set to special values. But because of the above, it does not work: variable will "leak" out of the function.