Svyatoslav Mishyn | 18 May 11:07 2016

man fixes


just found some typos and mdocml warnings.

From 745af83b0953eb16ab31ed67f26808665576a46e Mon Sep 17 00:00:00 2001
From: Svyatoslav Mishyn <juef <at>>
Date: Fri, 13 May 2016 09:47:54 +0300
Subject: [PATCH 1/2] man: fix mandoc warnings

They are:
 * prologue macros out of order: Dt after Os
 * skipping paragraph macro: Pp before Bd
 * whitespace at end of input line
 * skipping empty macro: Cm
 * skipping paragraph macro: Pp before It
 * sections out of conventional order: Sh ENVIRONMENT
 * skipping -width argument: Bl -item
 src/dash.1 | 41 ++++++++++++++++++-----------------------
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/src/dash.1 b/src/dash.1
index 832eae7..57e731a 100644
--- a/src/dash.1
+++ b/src/dash.1
 <at>  <at>  -32,9 +32,9  <at>  <at> 
(Continue reading)

Geoff Nixon | 13 May 04:06 2016

The behavior of `jobs -p` is definitely, without a doubt, a bug

Package: dash
Version: build-from-git-HEAD--
Severity: serious
X-Debbugs-CC: herbert <at>

To Whom It May Concern:

I wrote most of this before I read through the Debian bug report process.
I'm actually not sure whether this is supposed to go to Debian or to the address; So I apologize if some of it is redundant or sounds a
bit weird; I assumed I'd be "creating a new thread", so I refer to this
thread as "that thread", etc.

If I've made any other errors, again apologizes in advance; it's the first time
I've worked with the Debian process, and I'm using dash on another platform, so
I don't have access to "reportbug", etc.

Also, if I come off a bit pissy, petulant, pedantic, or arrogant, it's only
because I have so many, many times *been* "that guy" -- someone who takes the
time and goes out of his way to write and file a bug report and send it through
the proper channels -- only have it basically dismissed out of hand. So when
I found myself in the position of not only reporting a bug, but having to
refute the incorrect arguments made that led to the bug report being dismissed,
and thinking about how this could have been fixed 8 years ago, it did irk me.
So yes, I was a bit peeved as I wrote it, it is absolutely nothing personal
(except in that it's some of my own emotional baggage).

So, once again, apologies, I truly mean no disrespect.

(Continue reading)

Mike Hillary | 3 May 11:56 2016


Dear Friend,

I am Mike Hilary, the former Assistant Director of Project,  Niger Delta
Development Commission, (NDDC.) Nigeria

I am interested in investing in your country but i am faced with the problem of finding a trustworthy partner
who will advice me on the viable areas to invest in and at the same time, act as my representative. It is on
this reason that i am contacting you.

Please, indicate your interest by contacting me  for more details.
Email,mike.hilary3 <at>

Yours Sincerely,
Mike Hillary
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at>
More majordomo info at

APPROVED | 9 Apr 23:12 2016

Zero APR. No Credit Required. No Spend Limit!

Date: 03/25/16
Subject: Approval


Credit Card Approval

Attention: Your Credit Card Approval

Low Rates for 2016

Please take a look at the new options:

Postal contact:
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at>
More majordomo info at

Merchant Account Services | 9 Apr 17:04 2016

Merchant Account: No termination fees. No merchant account contract.

New: Credit Card Processing - Merchant Account

New: Credit Card Processing Guide

*Accept all Major Credit Cards

*Find a great Affordable, Credit Card Processing 

*Find a Merchant Account with Low Fees and easy Approval

New: Credit Card Processing Guide

To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at>
More majordomo info at

牛保龙 | 8 Mar 01:23 2016

dash security crash report

i use AFL fuzz dash shell and get 7 null deref vulnerablity and 1
stack corruption vulnerablity. the crash testcase is in the

system: Ubuntu 14.04.4 x86_64
dash: 0.58

jush use /bin/sh or /bin/dash execute the testcase then you can get a crash.
Attachment ( application/zip, 3947 bytes
Martin Lucina | 4 Mar 15:06 2016

Dash commit 46d3c1a (in 0.5.8+) breaks BSD make


Commit 46d3c1a ([VAR] Sanitise environment variable names on entry)
restricts exported environment variables actually set by dash on entry to
those reported as valid by endofname(). While this is technically correct
and matches IEEE Std 1003.1, it breaks BSD make which uses '.' as a
separator in variables exported via the environment to a sub-make.

Upstream bug report:

I'm not sure what the correct fix is here. While we (rumprun) could
possibly patch our version of NetBSD make to not use '.' in exported names,
this problem would continue to hit other users of BSD-derived make.

Would the dash maintainers consider replacing 46d3c1a with a fix that
performs the name validity check at "export -p" time instead? If yes, I can
try my hand at a patch.

Based on my reading of reading of Std 1003.1 section 8.1...

    "Other characters may be permitted by an implementation; applications
    shall tolerate the presence of such names."

... preserving "invalid" but exported environment variables would still be
compliant behaviour.

To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at>
(Continue reading)

Adam Endrodi | 2 Mar 22:09 2016

"case" bug in dash


The following program prints "boo" incorrectly (I'm trying to match


case "111" in
	echo boo;;

File expansion seems to be affected too:

/tmp/dash/src $ touch 111
/tmp/dash/src $ ./dash -c 'echo *[^0-9]*'
111 dash.1
/tmp/dash/src $ bash -c 'echo *[^0-9]*' 
alias.c alias.h alias.o arith_yacc.c arith_yacc.h arith_yacc.o arith_yylex.c arith_yylex.o bltin
builtins.c builtins.def builtins.h builtins.o cd.c cd.h cd.o dash dash.1 error.c
error.h error.o eval.c eval.h eval.o exec.c exec.h exec.o expand.c expand.h expand.o funcs histedit.c
histedit.o init.c init.h init.o input.c input.h input.o jobs.c jobs.h jobs.o machdep.h mail.c mail.h
mail.o main.c main.h main.o Makefile memalloc.c memalloc.h memalloc.o
miscbltin.c miscbltin.h miscbltin.o mkbuiltins mkinit mkinit.c mknodes mknodes.c mksignames
mksignames.c mksyntax mksyntax.c mktokens myhistedit.h mystring.c mystring.h mystring.o nodes.c
nodes.c.pat nodes.h nodes.o nodetypes options.c options.h options.o output.c output.h output.o
parser.c parser.h parser.o
(Continue reading)

Oleg Bulatov | 23 Feb 23:07 2016

heredoc and subshell


trying to minimize a shell code I found an unobvious moment with heredocs and subshells.

Is it specified by POSIX how next code should be parsed? dash output for this code differs from bash and zsh.

--- code
prefix() { sed -e "s/^/$1:/"; }
DASH_CODE() { :; }

prefix A <<XXX && echo "$(prefix B <<XXX
echo line 1
echo line 2)" && prefix DASH_CODE <<DASH_CODE
echo line 3
echo line 4)"
echo line 5

--- bash 4.3.42 output:
A:echo line 3
B:echo line 1
line 2
DASH_CODE:echo line 4)"
DASH_CODE:echo line 5

--- dash 0.5.8 output:
A:echo line 1
B:echo line 2)" && prefix DASH_CODE <<DASH_CODE
(Continue reading)

Jan Verbeek | 23 Feb 19:18 2016

[BUG] Illegal function names are accepted after being used as aliases

Function definitions that use a bad function name (such as "-" and "=") 
are accepted if the function name already exists as an alias. For example:

$ -
dash: 1: -: not found
$ - () { echo hello; }
dash: 2: Syntax error: Bad function name
$ -
dash: 2: -: not found
$ alias -=true
$ -
$ - () { echo hello; }
$ -
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo <at>
More majordomo info at

Martijn Dekker | 13 Feb 16:45 2016

[BUG] 'trap' is not quite POSIX compliant

The 'trap' command in dash is not compliant with POSIX. According to the
spec, both '-' and any unsigned decimal integer should be accepted as an
argument meaning 'unset this trap'; dash only accepts '-'.

I did testing on all other POSIX shells I know of with this little script:

	trap 'echo BYYYE' EXIT
	trap "$1" EXIT

This script will either produce 'BYYYE' or output a "command not found"
error message, depending on whether $1 was accepted as an argument for
unsetting the trap.

None of the shells are technically compliant: they only interpret an
unsigned decimal integer up to a certain value as 'unset this trap'; a
value exceeding that is interpreted as a command.

Interestingly, that maximum value differs slightly between shells. So
far, I've found:
- dash and Busybox ash do not accept any.
- bash, yash, pdksh, mksh/lksh, FreeBSD /bin/sh, and AT&T ksh "AJM 93u+
2012-08-01" accept up to 31.
- AT&T ksh "M 1993-12-28 s+" accepts up to 32.
- zsh 4.3.11, zsh 5.1.1 and zsh 5.2-dev-1 (current git) on my Mac accept
up to 33.
- zsh 5.0.2 on FreeBSD accepts up to 34.

For compatibility purposes it might seem wise to follow the majority of
implementations, accepting up to 31.
(Continue reading)