Re: Dashhh

[Heiko Gerstung <heiko@am-anger-1.de>]

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