823318822c
Upstream patch: Date: Wed, 30 May 2018 02:06:03 +0800 expand: Do not reprocess data when expanding words Currently various paths will reprocess data when performing word expansion. For example, expari will skip backwards looking for the start of the arithmetic expansion, while evalvar will skip unexpanded words manually. This is cumbersome and error-prone. This patch fixes this by making word expansions proceed in a linear fashion. This means changing argstr and the various expansion functions such as expari and subevalvar to return the next character to be expanded. This is inspired by similar code from FreeBSD. However, we take things one step further and completely remove the manual word skipping in evalvar. This is accomplished by introducing a new EXP_DISCARD flag that tells argstr to only parse and not produce any actual expansions. Incidentally, argstr will now always NUL-terminate the expansion unless the EXP_WORD flag is set. This is because all but one caller of argstr wants the result to be NUL-termianted. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Also includes two one-line follow-up fixes: expand: Eat closing brace for length parameter if (subtype == VSLENGTH) { + p++; if (flag & EXP_DISCARD) expand: Fix double-decrement in argstr - newloc = expdest - (char *)stackblock() - end; + newloc = q - (char *)stackblock() - end; and changes in code for bash substring extensions. Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com> |
||
---|---|---|
.. | ||
ash_test | ||
hush_test | ||
ash_doc.txt | ||
ash_ptr_hack.c | ||
ash.c | ||
brace.txt | ||
Config.src | ||
cttyhack.c | ||
hush_doc.txt | ||
hush_leaktool.sh | ||
hush.c | ||
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.