c0663c7cd2
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>
|
||
|---|---|---|
| .. | ||
| 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.