Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
function old new delta write2pipe - 133 +133 .rodata 105992 106009 +17 readtoken1 3101 3111 +10 cmdtxt 631 641 +10 nodesize 27 28 +1 redirect 961 916 -45 ------------------------------------------------------------------------------ (add/remove: 1/0 grow/shrink: 4/1 up/down: 171/-45) Total: 126 bytes Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit
Date: Wed, 14 Dec 2022 02:06:05 +0100
parser: Invalid redirections are run-time, not syntax errors
This fixes a long-standing bug where
echo 'echo >&a' | sh
errors out with
sh: 2: Syntax error: Bad fd number
despite the error being on line 1
This patch makes the error
sh: 1: Bad fd number: a
as expected
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
text data bss dec hex filename
1067871 559 5184 1073614 1061ce busybox_old
1068067 555 5088 1073710 10622e busybox_unstripped
^^^^^^^^^^^
function old new delta
pgetc 580 623 +43
parse_command 1633 1651 +18
ash_main 1226 1239 +13
popstring 115 126 +11
redirect 951 961 +10
popfile 105 115 +10
expandstr 252 262 +10
evalbltin 306 314 +8
pushstring 155 162 +7
pushfile 31 38 +7
freestrings 90 97 +7
setinputstring 68 74 +6
readtoken1 3095 3101 +6
pungetc 9 15 +6
nlprompt 39 45 +6
nlnoprompt 33 39 +6
unwindfiles 20 25 +5
dotcmd 309 314 +5
setinputfile 190 194 +4
init 429 432 +3
forkchild 617 620 +3
evalcommand 1616 1617 +1
ash_vmsg 141 142 +1
g_parsefile 4 - -4
commandname 4 - -4
basepf 84 - -84
------------------------------------------------------------------------------
(add/remove: 0/3 grow/shrink: 23/0 up/down: 196/-92) Total: 104 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit:
Date: Thu, 28 May 2020 21:31:45 +1000
redir: Retry open64 on EINTR
It is possible for open64 to block on named pipes, and therefore
it can be interrupted by signals and return EINTR. We should only
let it fail with EINTR if real signals are pending (i.e., it should
not fail on SIGCHLD if SIGCHLD has not been trapped).
This patch adds a new helper sh_open to retry the open64 call if
necessary. It also calls sh_error when appropriate.
Fixes: 3800d4934391 ("[JOBS] Fix dowait signal race")
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit:
Date: Sun, 3 Mar 2019 21:57:50 +0800
eval: Reset handler when entering a subshell
As it is a subshell can execute code that is only meant for the
parent shell when it executes a longjmp that is caught by something
like evalcommand. This patch fixes it by resetting the handler
when entering a subshell.
function old new delta
evalsubshell 169 183 +14
evalpipe 342 356 +14
argstr 1406 1416 +10
ash_main 1236 1226 -10
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 4/1 up/down: 65/-10) Total: 28 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit:
Date: Wed, 6 Jan 2021 15:45:12 +1100
jobs: Block signals during tcsetpgrp
Harald van Dijk <harald@gigawatt.nl> wrote:
> On 19/12/2020 22:21, Steffen Nurpmeso wrote:
>> Steffen Nurpmeso wrote in
>> <20201219172838.1B-WB%steffen@sdaoden.eu>:
>> |Long story short, after falsely accusing BSD make of not working
>>
>> After dinner i shortened it a bit more, and attach it again, ok?
>> It is terrible, but now less redundant than before.
>> Sorry for being so terse, that problem crosses my head for about
>> a week, and i was totally mislead and if you bang your head
>> against the wall so many hours bugs or misbehaviours in a handful
>> of other programs is not the expected outcome.
>
> I think a minimal test case is simply
>
> all:
> $(SHELL) -c 'trap "echo TTOU" TTOU; set -m; echo all good'
>
> unless I accidentally oversimplified.
>
> The SIGTTOU is caused by setjobctl's xtcsetpgrp(fd, pgrp) call to make
> its newly started process group the foreground process group when job
> control is enabled, where xtcsetpgrp is a wrapper for tcsetpgrp. (That's
> in dash, the other variants may have some small differences.) tcsetpgrp
> has this little bit in its specification:
>
> Attempts to use tcsetpgrp() from a process which is a member of
> a background process group on a fildes associated with its con‐
> trolling terminal shall cause the process group to be sent a
> SIGTTOU signal. If the calling thread is blocking SIGTTOU sig‐
> nals or the process is ignoring SIGTTOU signals, the process
> shall be allowed to perform the operation, and no signal is
> sent.
>
> Ordinarily, when job control is enabled, SIGTTOU is ignored. However,
> when a trap action is specified for SIGTTOU, the signal is not ignored,
> and there is no blocking in place either, so the tcsetpgrp() call is not
> allowed.
>
> The lowest impact change to make here, the one that otherwise preserves
> the existing shell behaviour, is to block signals before calling
> tcsetpgrp and unblocking them afterwards. This ensures SIGTTOU does not
> get raised here, but also ensures that if SIGTTOU is sent to the shell
> for another reason, there is no window where it gets silently ignored.
>
> Another way to fix this is by not trying to make the shell start a new
> process group, or at least not make it the foreground process group.
> Most other shells appear to not try to do this.
This patch implements the blocking of SIGTTOU (and everything else)
while we call tcsetpgrp.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Upstream commit:
Date: Sat, 19 May 2018 02:39:56 +0800
eval: Add vfork support
This patch adds basic vfork support for the case of a simple command.
Upstream commit:
Date: Tue, 12 Jan 2021 17:11:19 +1100
jobs: Always reset SIGINT/SIGQUIT handlers
On Fri, Jan 08, 2021 at 08:55:41PM +0000, Harald van Dijk wrote:
> On 18/05/2018 19:39, Herbert Xu wrote:
> > This patch adds basic vfork support for the case of a simple command.
> > ... @@ -879,17 +892,30 @@ forkchild(struct job *jp, union node *n, int
> > mode)
> > }
> > }
> > if (!oldlvl && iflag) {
> > - setsignal(SIGINT);
> > - setsignal(SIGQUIT);
> > + if (mode != FORK_BG) {
> > + setsignal(SIGINT);
> > + setsignal(SIGQUIT);
> > + }
> > setsignal(SIGTERM);
> > }
> > +
> > + if (lvforked)
> > + return;
> > +
> > for (jp = curjob; jp; jp = jp->prev_job)
> > freejob(jp);
> > }
>
> This leaves SIGQUIT ignored in background jobs in interactive shells.
>
> ENV= dash -ic 'dash -c "kill -QUIT \$\$; echo huh" & wait'
>
> As of dash 0.5.11, this prints "huh". Before, the subprocess process killed
> itself before it could print anything. Other shells do not leave SIGQUIT
> ignored.
>
> (In a few other shells, this also prints "huh", but in those other shells,
> that is because the inner shell chooses to ignore SIGQUIT, not because the
> outer shell leaves it ignored.)
Thanks for catching this. I have no idea how that got in there
and it makes no sense whatsoever. This patch removes the if
conditional.
Fixes: e94a964e7dd0 ("eval: Add vfork support")
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Comparing code with dash is more difficult with these differences. (We didn't know back then that dash will be revived...) Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>