src/main.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 shell: disable sh -c "command" -> sh -c "exec command" optimization

Bugs #642706 (bin-prot FTBFS) and #642835 (sexplib310 FTBFS) can be
fixed by reverting the patch submitted at [1]. I don't understand why.

[1] http://thread.gmane.org/gmane.comp.shells.dash/556

While investigating #642706, in the failing case, I observed that a
cpp process called with "sh -c" gets SIGPIPE while writing to
stderr. In the succeeding case, the write is successful, and is read
by the ocamlbuild process that started "sh -c cpp ...".

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

src/exec.c | 32 32 + 0 - 0 !
1 file changed, 32 insertions(+)

 don't execute binary files if execve() returned enoexec

Both "dash -c foo" and "./foo" are supposed to be able to run hashbang-less
scripts, but attempts to execute common binary files tend to be nasty:
especially both ELF and PE tend to make dash create a bunch of files with
unprintable names, that in turn confuse some tools up to causing data loss.

Thus, let's read the first line and see if it looks like text.  This is a
variant of the approach used by bash and zsh; mksh instead checks for
signatures of a bunch of common file types.

POSIX says: "If the executable file is not a text file, the shell may bypass
this command execution.".

Signed-off-by: Adam Borowski <kilobyte@angband.pl>

src/bltin/printf.c | 1 1 + 0 - 0 !
src/dash.1 | 4 4 + 0 - 0 !
2 files changed, 5 insertions(+)

 support \e in "echo" and "printf" builtins

Signed-off-by: Adam Borowski <kilobyte@angband.pl>

src/eval.c | 8 7 + 1 - 0 !
src/eval.h | 2 2 + 0 - 0 !
2 files changed, 9 insertions(+), 1 deletion(-)

 dash: fix stack overflow from infinite recursion in script

Bug-Debian: https://bugs.debian.org/579815
Signed-off-by: Chris Lamb <lamby@debian.org>
Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

configure.ac | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 enable large file support when available

src/Makefile.am | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 add $(cppflags), $(cflags) and $(ldflags) to $(compile_for_build) so that helpers are built with hardening

src/histedit.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 histedit: fix infinite loop when using 'fc -s'

When compiling with libedit, he.num may somehow overrun last, causing
an infinite loop when using fc -s.
This mild change to the check plugs it.

Bug-Debian: https://bugs.debian.org/928072

src/dash.1 | 16 10 + 6 - 0 !
src/main.c | 17 17 + 0 - 0 !
src/options.c | 2 2 + 0 - 0 !
src/options.h | 7 4 + 3 - 0 !
src/var.c | 29 23 + 6 - 0 !
src/var.h | 1 1 + 0 - 0 !
6 files changed, 57 insertions(+), 15 deletions(-)

 implement privmode, part 1

src/Makefile.am | 2 1 + 1 - 0 !
src/dash.1 | 2 1 + 1 - 0 !
src/main.c | 14 1 + 13 - 0 !
src/options.c | 4 3 + 1 - 0 !
src/priv.c | 27 27 + 0 - 0 !
src/priv.h | 6 6 + 0 - 0 !
src/var.c | 3 0 + 3 - 0 !
7 files changed, 39 insertions(+), 19 deletions(-)

 implement privmode, part 2

src/jobs.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 [patch] jobs: only block in waitcmd on first run
Message-ID: <20201202053145.GA8074@gondor.apana.org.au>

This patch ensures that waitcmd never blocks unless there are
outstanding jobs.  This could otherwise trigger a hang if children
were created prior to the shell coming into existence, or if
there are backgrounded children of other kinds (e.g., a here-
document).

Fixes: 6c691b3e5099 ("jobs: Only clear gotsigchld when waiting...")
Reported-by: Michael Biebl <biebl@debian.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>