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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
