Rusty Bird | 26 Jul 11:23 2015

Ignored alias inside for loop


Why does this ...

for i in 1; do
    alias foobarbaz='echo ok'

... result in "foobarbaz: not found", but without the for loop it works?
Maybe I'm missing something in the spec, because bash-as-sh behaves
the same.

Aleksandar Ristovski | 24 Jul 20:50 2015

shell: dash - large file support


For builds that build 32-bit dash, configure misses to setup large
file support resulting in issues with large files.

For example:
...dp/dash-0.5.8/build$ ls -l /tmp/
-rw-rw-r-- 1 aristovski aristovski 3794653588 Jul 24 14:12 /tmp/
...dp/dash-0.5.8/build$ ./src/dash /tmp/
./src/dash: 0: Can't open /tmp/

Where dash was configured (on a 64-bit platform) like so:

...dp/dash-0.5.8/build$ CFLAGS=-m32 ../configure && make -j8

Now, if I make the change in and reconfigure the project,
I get proper operation:

...0.5.8.patched/build$ ./src/dash /tmp/

(the actual working of the '' is removed for brevity)

Thank you,

Aleksandar Ristovski


(Continue reading)

Martijn Dekker | 13 Jul 01:30 2015

[BUG] test: -gt: unexpected operator

I found a bug in dash that affects checking the exit status of '[' or
'test' for failure.

After feeding an illegal number to 'test -t', 'test' will not accept any
operator (or at least not -gt or -lt) for the next invocation.

Confirmed in dash 0.5.7, 0.5.8 and current git version.

$ [ -t 12323454234578326584376438 ]
src/dash: 7: [: Illegal number: 12323454234578326584376438
$ [ "$?" -gt 1 ] && echo error
src/dash: 8: [: -gt: unexpected operator
$ [ "$?" -gt 1 ] && echo error
$ test -t 12323454234578326584376438
src/dash: 10: test: Illegal number: 12323454234578326584376438
$ test "$?" -gt 1 && echo error
src/dash: 11: test: -gt: unexpected operator
$ test "$?" -gt 1 && echo error
$ test -t 12323454234578326584376438
src/dash: 13: test: Illegal number: 12323454234578326584376438
$ test 2 -gt 1
src/dash: 14: test: -gt: unexpected operator
$ test 2 -gt 1
$ test -t 12323454234578326584376438
src/dash: 16: test: Illegal number: 12323454234578326584376438
$ test 2 -lt 1
src/dash: 17: test: -lt: unexpected operator
$ test 2 -lt 1
(Continue reading)

Parke | 6 Jul 04:18 2015

dash unset idiosyncrasies


The man page for dash says:

     unset [-fv] name ...
            The specified variables and functions are
            unset and unexported.  If -f or -v is speci‐
            fied, the corresponding function or variable
            is unset, respectively.  If a given name cor‐
            responds to both a variable and a function,
            and no options are given, only the variable is

The man page does not say what happens if the given name corresponds
only to a function.

Based on experimentation, I have determined that in dash versions
0.5.7, 0.5.8, and git head, "unset name" (without -f) will only unset
variables and will never unset any function.

In addition, during my experiments, I discovered idiosyncrasies that
are demonstrated by the following script.

The script runs a series of tests.  Each test sets a variable and
function, both named "true" (so as to overshadow /bin/true).  The test
then tries to unset either the variable, or the function, or both.
The test then probes the existence of the variable and function, and
compares to the expected result.

(Continue reading)

Martijn Dekker | 3 Jun 13:29 2015

[BUG] ${#var} returns length in bytes, not characters

> ${#parameter}
> String Length. The length in characters of the value of parameter
> shall be substituted. [...]

dash does not expand the length in characters; it expands the length in
bytes instead. That is invalid for locales that include multi-byte
characters, such as the now ubiquitous UTF-8 set.

Test case:

$ locale
$ word='bètatest'	# length: 8
$ echo ${#word}

Expected output: 8
Got output: 9

(bash, ksh93, mksh, and zsh all do this correctly.)

(Continue reading)

Felix Dietrich | 2 Jun 22:55 2015

[MAN] Fix description of getopts when last argument reached

When I read the getopts description in the man-page I got stumped by the
following part:

    getopts optstring var


        If there are no remaining arguments, getopts will set var to
        special option, “--”, otherwise, it will set var to “?”


After I was unable to get getopts to store "--" in var, I asked for help
on [1] where it was pointed out to me that actually the
POSIX description of getopts [2] does not include a special option "--";
dash's behaviour of setting var to "?" after the last argument is
correct and that this is most likely an error in the documention.

In case this is not an error: Under what circumstances will var be set
to "--"?  Could you provide an example?


 src/dash.1 | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/src/dash.1 b/src/dash.1
index 693c970..832eae7 100644
(Continue reading)

Martijn Dekker | 28 May 20:54 2015

getopts doesn't properly update OPTIND when called from function

I'm writing a shell function that extends the functionality of the
'getopts' builtin. For that to work, it is necessary to call the
'getopts' builtin from the shell function.

The POSIX standard specifies that OPTIND and OPTARG are global
variables, even though the positional parameters are local to the
function.[*] This makes it possible to call 'getopts' from a function by
simply passing the global positional parameters along by adding "$ <at> ".

My problem is that dash does not properly update the global OPTIND
variable when getopts is called from a function, which defeats my
function on dash. It updates the global OPTIND for the first option but
not for subsequent options, so OPTIND gets stuck on 3. (It does
accurately update the global OPTARG variable, though.)

I made a little test program that demonstrates this; see below the
footnote. It succeeds on bash, ksh93, pdksh, mksh, and yash, but not
(d)ash or zsh[*2].

The output of my test script seems consistent with the hypothesis that
OPTIND is reinitialized to 1 whenever a function is called. It should
only be initialized when the shell is initialized.

I suspect this is an old bug as other versions of ash, including Busybox
ash and NetBSD's /bin/sh, share it.


- Martijn

(Continue reading)

Fredrik Fornwall | 18 May 01:15 2015

[PATCH] Set LC_ALL instead LC_COLLATE in mkbuiltins

In mkbuiltins LC_COLLATE is set, but since "The value of the LC_ALL
environment variable has precedence over any of the other environment
variables starting with LC_"
(, this
has no effect when LC_ALL is set.

This breaks when having e.g. LC_ALL=en_US.UTF-8 during make, which
causes the test case
    dash -c :
to fail, probably due to broken ordering in builtins.c. The patch
corrects that by setting LC_ALL instead of LC_COLLATE.


diff -u -r ../dash-0.5.8/src/mkbuiltins ./src/mkbuiltins
--- ../dash-0.5.8/src/mkbuiltins 2014-09-28 04:19:32.000000000 -0400
+++ ./src/mkbuiltins 2015-05-17 19:08:00.076452891 -0400
 <at>  <at>  -78,7 +78,7  <at>  <at> 
  if ($i ~ /^-/)
  line = $(++i) "\t" line
  print line
- }}' $temp | LC_COLLATE=C sort -k 1,1 | tee $temp2 | awk '{
+ }}' $temp | LC_ALL=C sort -k 1,1 | tee $temp2 | awk '{
  opt = ""
  if (NF > 2) {
  opt = substr($2, 2)
 <at>  <at>  -97,7 +97,7  <at>  <at> 

(Continue reading)

Alex Waite | 25 Mar 14:51 2015

Pattern matching faster than math


This isn't a problem per-se, but I'm curious if anyone can shed some 
light on why this is so.

I have a script where I'm checking if the contents of a variable is an 
integer. An easy/hacky way to do this is

[ "$var" -ge 0 2> /dev/null ] || echo "is not int"

But this caused posh to segfault, so I went for a pattern matching 
solution instead:

[ -z "${var##*[!0-9]*}" ] && echo "is not int"

This works well, and it makes posh happy. But what's surprising to me is 
that it's faster.

I have more of a write-up in a commit message:

Any thoughts or insight? Am I making some faulty assumption here?

Thanks for your time.


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

jacinta jacinta | 22 Mar 15:00 2015



I, am miss jacinta,interested in you, and wish to have you as my friend,
please could you get back to me for more details of my self and all maybe
necessary in this relationship,including my picture,if this interest you
get back to address(jacinta.jac <at>
yours jacinta

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

Damian Wrobel | 20 Jan 18:01 2015

Re: Inconsistent behaviour between 'jobs' and 'echo "$(jobs)"'

On 01/20/2015 09:44 AM, Seb wrote:
> On Mon, Jan 19, 2015 at 07:01:53PM +0100, Damian Wrobel wrote:
> Hello,
>> I'm observing an inconsistent behaviour between:
>>   jobs
>> and
>>   echo "$(jobs)"
> It's because the command is ran in a sub-shell, where there is indeed no
> running job.
> Bash has a special mechanism to handle this and get the current shell
> context returned, that's why you may feel some inconsistency here (like
> I myself did :)

There is an application usage [1] where this case is specifically mentioned with 
a suggestion that: "For this reason, jobs is generally implemented as a shell 
regular built-in."

I basically planned to use the following construction to kill all running jobs:

$ kill $(jobs -p)

Now it looks that even the following doesn't work in a dash:

$ jobs -p | xargs kill

I would prefer not to code something like the following:
(Continue reading)