Dashhh

Dashhh

[Heiko Gerstung]

[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]

Hi!

I am an enthusiastic user of dash since a couple of months and use it on an embedded system (appliance) that is operating
all around the globe in all kinds of networks. I made the switch from bash to dash as soon as I found out that dash covers
99% of what I do with bash while requiring 10% of the ressources.

In the course of porting ~200 shell scripts (small three liners and a few big guys) from bash to dash, I ran into a few
issues (surprise surprise):

1. The usual "[[" and "==" stuff (pretty easy to change, thank you sed)
2. shift returns with a critical error when no arguments are left (no really good solution found)
3. $[] arithmetic stuff not working (OK, worked around that with bc)
4. The bash FUNCNAME variable was very valuable for debugging purposes and is nonexistent in dash

Now, since I solved point 1 and 3 by changing my code, all I did is creating a very small patch to deal with point 2 and,
since it is also not too complicated, I added patches to deal with point 1 and 4 as well.

I call this the dashhh (dash: Heiko's Hack) and although I browsed the mailing list archives and found out that the shift
issue has not been accepted as a worthwhile change for dash and people are still discussing about "==", I decided that I at
least want to show you my patch.

If anyone wants to try this: Please remember that this of course is no longer dash (it is dashhh).

I can understand the reasoning behind the relucatance of the dash crew to apply any of those changes to the main codebase.
For me it is not so important that dash is fully POSIX compliant (I was using bash for years, that tells you how much I care
for POSIX compliance in my shell scripts), the killer feature of dash is its small footprint and the fast execution times.
Since my shell scripts are running inside a closed system where I control which binary is loaded when I enter #!/bin/dash in
the first line of a new shell script, I can easily make patches to dash and make use of the modifications on my system.

What this tiny patch does:
- shift does not return a critical error when no arguments are left, it simply does nothing
- "[[" works exactly as "["
- "==" works like "="
- the variable FUNCNAME contains the name of the currently running shell function or nothing (when not inside a function)

It is far from being perfect and I am not a very good C programmer (as you can probably tell from looking at the patch), so
please feel free to send me your suggestions for changes and any kind of feedback. And, if anyone feels the need for other
tiny tweaks that due to the strict POSIX compliance approach of dash would not make it into the main source tree, I would be
happy to look into that, maybe it is just another tiny patch.

Best Regards,
  Heiko



[-- Attachment #2: dashhh-0.5.7.patch --]
[-- Type: text/x-patch, Size: 3499 bytes --]

diff -Naur dash-0.5.7/src/bltin/test.c dash-0.5.7-shhh/src/bltin/test.c
--- dash-0.5.7/src/bltin/test.c	2011-03-15 07:18:06.000000000 +0000
+++ dash-0.5.7-shhh/src/bltin/test.c	2011-11-17 13:29:08.000000000 +0000
@@ -112,6 +112,7 @@
 	{"-G",	FILGID,	UNOP},
 	{"-L",	FILSYM,	UNOP},
 	{"-S",	FILSOCK,UNOP},
+	{"==",	STREQ,	BINOP},
 	{"=",	STREQ,	BINOP},
 	{"!=",	STRNE,	BINOP},
 	{"<",	STRLT,	BINOP},
diff -Naur dash-0.5.7/src/builtins.def.in dash-0.5.7-shhh/src/builtins.def.in
--- dash-0.5.7/src/builtins.def.in	2010-05-27 03:45:23.000000000 +0000
+++ dash-0.5.7-shhh/src/builtins.def.in	2011-11-17 13:27:20.000000000 +0000
@@ -90,5 +90,5 @@
 #ifdef HAVE_GETRLIMIT
 ulimitcmd	ulimit
 #endif
-testcmd		test [
+testcmd		test [ [[
 killcmd		-u kill
diff -Naur dash-0.5.7/src/eval.c dash-0.5.7-shhh/src/eval.c
--- dash-0.5.7/src/eval.c	2011-07-08 08:29:56.000000000 +0000
+++ dash-0.5.7-shhh/src/eval.c	2011-11-17 14:01:55.000000000 +0000
@@ -36,7 +36,7 @@
 #include <signal.h>
 #include <unistd.h>
 #include <sys/types.h>
-
+#include <stdio.h>
 /*
  * Evaluate a command.
  */
@@ -928,6 +928,7 @@
 	int e;
 	int savefuncline;
 
+	snprintf(fnnamevar, sizeof(fnnamevar), "FUNCNAME=%s", argv[0]);
 	saveparam = shellparam;
 	savefuncline = funcline;
 	savehandler = handler;
@@ -949,6 +950,7 @@
 	poplocalvars(0);
 funcdone:
 	INTOFF;
+	strcpy(fnnamevar, "FUNCNAME=");
 	funcline = savefuncline;
 	freefunc(func);
 	freeparam(&shellparam);
diff -Naur dash-0.5.7/src/options.c dash-0.5.7-shhh/src/options.c
--- dash-0.5.7/src/options.c	2008-07-13 14:24:56.000000000 +0000
+++ dash-0.5.7-shhh/src/options.c	2011-11-17 13:35:36.000000000 +0000
@@ -352,8 +352,10 @@
 	n = 1;
 	if (argc > 1)
 		n = number(argv[1]);
-	if (n > shellparam.nparam)
-		sh_error("can't shift that many");
+	if (n > shellparam.nparam) {
+                shellparam.nparam = 0;
+                return 0;
+        }
 	INTOFF;
 	shellparam.nparam -= n;
 	for (ap1 = shellparam.p ; --n >= 0 ; ap1++) {
diff -Naur dash-0.5.7/src/var.c dash-0.5.7-shhh/src/var.c
--- dash-0.5.7/src/var.c	2011-03-15 07:45:32.000000000 +0000
+++ dash-0.5.7-shhh/src/var.c	2011-11-17 14:01:27.000000000 +0000
@@ -83,6 +83,8 @@
 
 int lineno;
 char linenovar[sizeof("LINENO=")+sizeof(int)*CHAR_BIT/3+1] = "LINENO=";
+char fnnamevar[1024] = "FUNCNAME=";
+
 
 /* Some macros in var.h depend on the order, add new variables to the end. */
 struct var varinit[] = {
@@ -102,6 +104,7 @@
 	{ 0,	VSTRFIXED|VTEXTFIXED,		"PS4=+ ",	0 },
 	{ 0,	VSTRFIXED|VTEXTFIXED,		"OPTIND=1",	getoptsreset },
 	{ 0,	VSTRFIXED|VTEXTFIXED,		linenovar,	0 },
+	{ 0,	VSTRFIXED|VTEXTFIXED,		fnnamevar,	0 },
 #ifndef SMALL
 	{ 0,	VSTRFIXED|VTEXTFIXED|VUNSET,	"TERM\0",	0 },
 	{ 0,	VSTRFIXED|VTEXTFIXED|VUNSET,	"HISTSIZE\0",	sethistsize },
@@ -339,6 +342,7 @@
 			fmtstr(linenovar+7, sizeof(linenovar)-7, "%d", lineno);
 		}
 		return strchrnul(v->text, '=') + 1;
+
 	}
 	return NULL;
 }
diff -Naur dash-0.5.7/src/var.h dash-0.5.7-shhh/src/var.h
--- dash-0.5.7/src/var.h	2011-03-15 07:45:32.000000000 +0000
+++ dash-0.5.7-shhh/src/var.h	2011-11-17 13:53:11.000000000 +0000
@@ -89,8 +89,9 @@
 #define vps4 (&vps2)[1]
 #define voptind (&vps4)[1]
 #define vlineno (&voptind)[1]
+#define vfnname (&vlineno)[1]
 #ifndef SMALL
-#define vterm (&vlineno)[1]
+#define vterm (&vfnname)[1]
 #define vhistsize (&vterm)[1]
 #endif
 
@@ -105,6 +106,7 @@
 
 extern int lineno;
 extern char linenovar[];
+extern char fnnamevar[1024];
 
 /*
  * The following macros access the values of the above variables.

Re: Dashhh

[Stefano Lattarini]

Hello everybody.  Hope it's OK if I chime in for a couple of tangential
issues... (I've no comments on the patch proper, as my knowledge of the
dash internals is zero).

On Thursday 17 November 2011, Heiko Gerstung wrote:
> Hi!
> 
> I am an enthusiastic user of dash since a couple of months and use it
> on an embedded system (appliance) that is operating all around the
> globe in all kinds of networks. I made the switch from bash to dash
> as soon as I found out that dash covers 99% of what I do with bash
> while requiring 10% of the ressources.
> 
> In the course of porting ~200 shell scripts (small three liners and
> a few big guys) from bash to dash, I ran into a few issues (surprise
> surprise):
> 
> 1. The usual "[[" and "==" stuff (pretty easy to change, thank
>    you sed)
> 2. shift returns with a critical error when no arguments are left
>    (no really good solution found)
> 3. $[] arithmetic stuff not working (OK, worked around that with bc)
>
You might instead use the shell built-in construct `$(( ))', which is
mandated by POSIX, and which dash supports as well:

  $ echo $((1 + 2 * 3))
  7

(In fact, I'm pretty sure the the use of `$[]' for arithmetic substitution
has been deprecated in bash for a looong time now).

> 4. The bash FUNCNAME variable was very valuable for debugging purposes
> and is nonexistent in dash
> 
> Now, since I solved point 1 and 3 by changing my code, all I did is creating
> a very small patch to deal with point 2 and, since it is also not too
> complicated, I added patches to deal with point 1 and 4 as well.
>
As for point (1), I'm quite opposed to "solving it", since the change
you are proposing would reduce the usefulness of dash as a testbed to
detect bashisms in shell scripts.

Also (and more importantly), if I'm not mistaken, `[[' as supported by
bash and the Korn shells is not a mere builtin, but rather a "syntactical
contruct", in that the shell parses and interpreters stuff enclosed into
`[[ ... ]]'  differently:

 ## Quoting rules are different ##

 $ a="x y"; [[ -n $a ]] && echo ok
 ok
 $ a="x y"; [ -n $a ] && echo ok
 bash: [: x: binary operator expected
 # Do this in an empty directory.
 $ touch foo
 $ a='*'; [ $a = foo ] && echo ok
 ok
 $ a='*'; [[ $a = "*" ]] && echo ok
 ok

 ## Operators and redirections: ">" is "greater than" in   ##
 ## `[[', but is the usual redirection operator inside `[' ##

 # Do this in an empty directory.
 $ [[ 1 > 2 ]]; echo status = $?; ls -l
 status = 1
 total 0
 $ [ 1 > 2 ]; echo $?; ls -l
 status = 0
 total 0
 -rw-r--r-- 1 stefano stefano 0 Nov 17 18:13 2

> I call this the dashhh (dash: Heiko's Hack) and although I browsed
> the mailing list archives and found out that the shift issue has not
> been accepted as a worthwhile change for dash and people are still
> discussing about "==", I decided that I at least want to show you my
> patch.
> 
> If anyone wants to try this: Please remember that this of course is no
> longer dash (it is dashhh).
> 
> I can understand the reasoning behind the relucatance of the dash crew
> to apply any of those changes to the main codebase.
> For me it is not so important that dash is fully POSIX compliant
>
But for many people, this is VERY important!

(Still, it seems to me that your proposed changes would leave dash
POSIX-compliant, so there's no need to venture into a discussion
of the merits of POSIX-compatibility).

> (I was using bash for years, that tells you how much I care for
> POSIX compliance in my shell scripts), the killer feature of dash
> is its small footprint and the fast execution times.
>
> [SNIP]
>
> Best Regards,
>   Heiko
> 

Regards,
  Stefano 

Re: Dashhh

[Heiko Gerstung]

Hi Stefano,

thank you for your response, please find my comments inline ...

Am 17.11.11 18:21, schrieb Stefano Lattarini:
> Hello everybody.  Hope it's OK if I chime in for a couple of tangential
> issues... (I've no comments on the patch proper, as my knowledge of the
> dash internals is zero).
OK, anyway, all comments are appreciated!

>
> On Thursday 17 November 2011, Heiko Gerstung wrote:
>> Hi!
>> {...} ressources.
>>
>> In the course of porting ~200 shell scripts (small three liners and
>> a few big guys) from bash to dash, I ran into a few issues (surprise
>> surprise):
>>
>> 1. The usual "[[" and "==" stuff (pretty easy to change, thank
>>     you sed)
>> 2. shift returns with a critical error when no arguments are left
>>     (no really good solution found)
>> 3. $[] arithmetic stuff not working (OK, worked around that with bc)
>>
> You might instead use the shell built-in construct `$(( ))', which is
> mandated by POSIX, and which dash supports as well:
>
>    $ echo $((1 + 2 * 3))
>    7
>
> (In fact, I'm pretty sure the the use of `$[]' for arithmetic substitution
> has been deprecated in bash for a looong time now).
Good point, I already forgot about that. I replaced the few occurences 
of $[] with an (ugly) bc workaround, and using $((x)) is definitely the 
best solution. Thanks!
>
>> 4. The bash FUNCNAME variable was very valuable for debugging purposes
>> and is nonexistent in dash
>>
>> Now, since I solved point 1 and 3 by changing my code, all I did is creating
>> a very small patch to deal with point 2 and, since it is also not too
>> complicated, I added patches to deal with point 1 and 4 as well.
>>
> As for point (1), I'm quite opposed to "solving it", since the change
> you are proposing would reduce the usefulness of dash as a testbed to
> detect bashisms in shell scripts.
Well, although I agree that it would reduce the usefulness of dash as a 
testbed for bashisms, I would not see that this is dash's primary task. 
I tried to find a nice workaround for this, but did not get very far 
(and patching dash was much easier and solved my problem instantly).

> Also (and more importantly), if I'm not mistaken, `[[' as supported by
> bash and the Korn shells is not a mere builtin, but rather a "syntactical
> contruct", in that the shell parses and interpreters stuff enclosed into
> `[[ ... ]]'  differently:
>
>   ## Quoting rules are different ##
>
>   $ a="x y"; [[ -n $a ]]&&  echo ok
>   ok
>   $ a="x y"; [ -n $a ]&&  echo ok
>   bash: [: x: binary operator expected
>   # Do this in an empty directory.
>   $ touch foo
>   $ a='*'; [ $a = foo ]&&  echo ok
>   ok
>   $ a='*'; [[ $a = "*" ]]&&  echo ok
>   ok
>
>   ## Operators and redirections: ">" is "greater than" in   ##
>   ## `[[', but is the usual redirection operator inside `[' ##
>
>   # Do this in an empty directory.
>   $ [[ 1>  2 ]]; echo status = $?; ls -l
>   status = 1
>   total 0
>   $ [ 1>  2 ]; echo $?; ls -l
>   status = 0
>   total 0
>   -rw-r--r-- 1 stefano stefano 0 Nov 17 18:13 2
I see, another good point! I personally did not run into the differences 
and used [[ and [ as aliases for each other. But I agree that in the 
light of the different behavior of the two I would prefer to either 
declare [[ a syntax error (like dash does) or to implement the different 
behavior. Will remove that!
>> I call this the dashhh (dash: Heiko's Hack) and although I browsed
>> the mailing list archives and found out that the shift issue has not
>> been accepted as a worthwhile change for dash and people are still
>> discussing about "==", I decided that I at least want to show you my
>> patch.
>>
>> If anyone wants to try this: Please remember that this of course is no
>> longer dash (it is dashhh).
>>
>> I can understand the reasoning behind the relucatance of the dash crew
>> to apply any of those changes to the main codebase.
>> For me it is not so important that dash is fully POSIX compliant
>>
> But for many people, this is VERY important!
I know and I never wanted to question that. That's why I pointed out 
that for me it is not so important. I need a fast, powerful and 
ressource-friendly non-interactive shell for my scripts and dash is 
really kicking ass in this respect.

>
> (Still, it seems to me that your proposed changes would leave dash
> POSIX-compliant, so there's no need to venture into a discussion
> of the merits of POSIX-compatibility).
OK. Although I always thought that the POSIX standard defines a minimum 
feature set that should be shared among all shells out there. 
Nevertheless every shell has additions to POSIX and it has them for a 
reason. Someone needs the additional functions and features and chooses 
that specific shell for her/his task. I agree that a lot of shell 
scripts benefit a lot from relying on the fact that /bin/sh (whereever 
that points to on a system) provides that standardized minimum feature 
set. Great for installation scripts and for stuff that needs to run on a 
number of different platforms and there is no common set of shells for 
all of those platforms. And, of course, you never know if your chosen 
shell is installed on every single system that may be required to run 
your scripts on. Tons of good reasons for a POSIX compliant shell. But: 
Being stricly POSIX compliant does not prevent you from offering 
additions and enhancements for script authors who do not face one of the 
above described situations. I am one of them, so for me and my special 
set of applications, POSIX compliance is not required. I still do not 
see any other shell that offers the speed of dash while sharing its 
small footprint.

Best Regards,
  Heiko
>> [SNIP]
> Regards,
>    Stefano
> --
> To unsubscribe from this list: send the line "unsubscribe dash" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dashhh

[Stefano Lattarini]

Hi Heiko.

On Thursday 17 November 2011, Heiko Gerstung wrote:
> >>
> >> I can understand the reasoning behind the relucatance of the dash crew
> >> to apply any of those changes to the main codebase.
> >> For me it is not so important that dash is fully POSIX compliant
> >>
> > But for many people, this is VERY important!
> I know and I never wanted to question that. That's why I pointed out 
> that for me it is not so important. I need a fast, powerful and 
> ressource-friendly non-interactive shell for my scripts and dash is 
> really kicking ass in this respect.
> 
> >
> > (Still, it seems to me that your proposed changes would leave dash
> > POSIX-compliant, so there's no need to venture into a discussion
> > of the merits of POSIX-compatibility).
>
> OK. Although I always thought that the POSIX standard defines a minimum 
> feature set that should be shared among all shells out there. 
>
> [SNIP]
>
> Being stricly POSIX compliant does not prevent you from offering 
> additions and enhancements
>
> [SNIP]
>
That was exactly what I was trying to say (when I wrote "it seems to
me that your proposed changes would leave dash POSIX-compliant").  So
we agree on this, no worry :-)

Regards,
  Stefano

Re: Dashhh

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

On 11/17/2011 09:17 AM, Heiko Gerstung wrote:
> What this tiny patch does:
> - shift does not return a critical error when no arguments are left, it simply does nothing

This came up in the Austin Group (the folks in charge of POSIX), and the
consensus there was that dash is compliant (POSIX says that the problem
is with the script, not the shell, if you call shift with too few
positional parameters set; and that you should rewrite your script to
avoid tickling unspecified behavior).

http://austingroupbugs.net/view.php?id=459

> - "[[" works exactly as "["

Wrong.  [[ is NOT exactly like [.  And the Austin Group is currently
considering a proposal to add [[ to the shell (if that is done, then
dash will HAVE to implement it as specified by POSIX; but the jury's
still out on whether the proposal will be accepted):

http://austingroupbugs.net/view.php?id=375

> - "==" works like "="

That same Austin Group proposal is also talking about adding [ a == b ];
this particular addition is much less controversial than the [[
addition, so it is likely that the proposal will be split and each
separate addition individually balloted for inclusion.

> - the variable FUNCNAME contains the name of the currently running shell function or nothing (when not inside a function)

That's fluff - POSIX doesn't speak either way, and dash prefers to be as
light as possible when POSIX doesn't require it, so I'm not sure if
you'll get any enthusiastic response on this front.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: Dashhh

[Heiko Gerstung]

Am 17.11.11 18:56, schrieb Eric Blake:
> On 11/17/2011 09:17 AM, Heiko Gerstung wrote:
>> What this tiny patch does:
>> - shift does not return a critical error when no arguments are left, it simply does nothing
> This came up in the Austin Group (the folks in charge of POSIX), and the
> consensus there was that dash is compliant (POSIX says that the problem
> is with the script, not the shell, if you call shift with too few
> positional parameters set; and that you should rewrite your script to
> avoid tickling unspecified behavior).
>
> http://austingroupbugs.net/view.php?id=459
Thanks for providing the link. I disagree with POSIX ;-) in this 
respect. Since shift often deals with user input (parameters provided 
when invoking a script) it is not really foreseeable if a certain number 
of parameters exists when shift comes to the party. I will try to 
rewrite my scripts, but it is a PITA to do so (as all of us most 
probably know) and if it is not really a POSIX violation to allow it, I 
see no benefit from not allowing it. But hey, that's just me.

>
>> - "[[" works exactly as "["
> Wrong.  [[ is NOT exactly like [.  And the Austin Group is currently
> considering a proposal to add [[ to the shell (if that is done, then
> dash will HAVE to implement it as specified by POSIX; but the jury's
> still out on whether the proposal will be accepted):
>
> http://austingroupbugs.net/view.php?id=375
Yep, Stefano already pointed that out. My mistake!

>> - "==" works like "="
> That same Austin Group proposal is also talking about adding [ a == b ];
> this particular addition is much less controversial than the [[
> addition, so it is likely that the proposal will be split and each
> separate addition individually balloted for inclusion.
I hope they accept it. Really a no-ressource-consuming, no existing 
script breaking thing and therefore a worthwhile addition IMHO.
>> - the variable FUNCNAME contains the name of the currently running shell function or nothing (when not inside a function)
> That's fluff - POSIX doesn't speak either way, and dash prefers to be as
> light as possible when POSIX doesn't require it, so I'm not sure if
> you'll get any enthusiastic response on this front.
I do not expect any enthusiastic responses, but I consider this a 
valuable addition for debugging large scripts with lots of functions 
usage. I have no problem if you think it's fluff, nobody is forced to 
use something she/he doesn't like.

One more thing I'd like to add is something like $SECONDS, but maybe 
with a little bit more resolution (maybe $RUNTIME representing the 
amount of milliseconds  since script invocation). Fluff as you probably 
would say ;-), but it would give me a good idea where in my (larger) 
scripts I am doing something that costs a lot of time.

Thank you for your interesting comments, that was exactly what I was 
hoping for! Got me thinking and I already have a few nice ideas how to 
rewrite parts of my scripts.

Regards,
   Heiko

Re: Dashhh

[Stephane CHAZELAS]

2011-11-17, 17:17(+01), Heiko Gerstung:
[...]
> 1. The usual "[[" and "==" stuff (pretty easy to change, thank you sed)
> 2. shift returns with a critical error when no arguments are left (no really good solution found)

[ "$#" -eq 0 ] || shift

> 3. $[] arithmetic stuff not working (OK, worked around that with bc)

$((...))

> 4. The bash FUNCNAME variable was very valuable for debugging purposes and is nonexistent in dash


If your functions are written as

f() {
  ...
}

sed 's/^[[:blank:]]*\([^[:blank:]]*\)[[:blank:]]*()[[:blank:]]*{/& local FUNCNAME=\1;/'

-- 
Stephane

Re: Dashhh

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On 11/17/2011 01:11 PM, Stephane CHAZELAS wrote:
>> 4. The bash FUNCNAME variable was very valuable for debugging purposes and is nonexistent in dash
> 
> 
> If your functions are written as
> 
> f() {
>   ...
> }
> 
> sed 's/^[[:blank:]]*\([^[:blank:]]*\)[[:blank:]]*()[[:blank:]]*{/& local FUNCNAME=\1;/'

Except that 'local' is not part of POSIX, so while this conversion may
work for dash, it's not a portable catch-all for other compliant shells.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: Dashhh

[Stephane CHAZELAS]

2011-11-17, 13:38(-07), Eric Blake:
[...]
>> sed 's/^[[:blank:]]*\([^[:blank:]]*\)[[:blank:]]*()[[:blank:]]*{/& loca=
> l FUNCNAME=3D\1;/'
>
> Except that 'local' is not part of POSIX, so while this conversion may
> work for dash, it's not a portable catch-all for other compliant shells.
[...]

Though "local" is in LSB, so supported by sh implementations on
Linux. Which is probably why even posh supports it. However LSB
only supports:

local var
var=value

Not

local var=value

-- 
Stephane

Re: Dashhh

[Heiko Gerstung]

Am 17.11.11 21:11, schrieb Stephane CHAZELAS:
> 2011-11-17, 17:17(+01), Heiko Gerstung:
> [...]
>> 1. The usual "[[" and "==" stuff (pretty easy to change, thank you sed)
>> 2. shift returns with a critical error when no arguments are left (no really good solution found)
> [ "$#" -eq 0 ] || shift
>
>> 3. $[] arithmetic stuff not working (OK, worked around that with bc)
> $((...))
>
>> 4. The bash FUNCNAME variable was very valuable for debugging purposes and is nonexistent in dash
>
> If your functions are written as
>
> f() {
>    ...
> }
>
> sed 's/^[[:blank:]]*\([^[:blank:]]*\)[[:blank:]]*()[[:blank:]]*{/&  local FUNCNAME=\1;/'
>
Thanks for your helpful comments, in fact I did something like this 
before I added the FUNCNAME patch to my dash sourcetree. I still prefer 
the FUNCNAME implementation as provided by my patch, but it is certainly 
possible to work around that as proposed by you.

Regards,
  Heiko