Re: Want to replace bash w zsh as system shell on Ubuntu

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Joke de Buhr wrote:
> On Tuesday 02 February 2010 20:04:13 Frank Terbeck wrote:
>> [snip]
>> zsh% foo=( foo bar baz )
>> zsh% set -x; [[ -n $foo ]]; set +x
>> +/bin/zsh:234> [[ -n 'foo bar baz' ]]
>> +/bin/zsh:234> set +x
>> [snap]
>
> I don't know but I would guess the debugging output is only some kind of 
> textual representation of what would be done but isn't done actually done. 
> Much like "$(<file)" isn't the same as "$(cat file)". Only in in an logical 
> sense.

I would want prove of that. Because I think XTRACE is supposed to show
what is actually going on. So, I looked into the code.

For `-n' in cond.c it really only does a strlen(string), for which you
need an actual character array. The most important lines are these, I
think:
        left = ecgetstr(state, EC_DUPTOK, &htok);
        [...]
        case 'n':
            return (!strlen(left));

I don't pretend to fully understand the evalcond() code, but the part
about `-n' is pretty clear. I especially don't understand how the shell
creates the string it stores in `left' on which it later runs strlen().

I suppose it's created by `ecgetstr()'. No idea what's going on in there
with that Estate stuff. But that one seems to do it. Also, with tracing
on, this line:
    quotedzputs(left, xtrerr);

...does the output. So, no - that's not just some kind of textual
representation; unless I'm really mistaken here.

If someone who knows the code feels like filling in the blanks here,
please go ahead. :)

> By the way what is this syntax actually: (( ${#foo} > 0 ))

Yes, which is exactly what I used in both of my mails:
(( ${#matches} > 0 )) && ...
(( ${#array} > 0 ))

> I would use a conditional expressions: [[ ${#foo} -gt 0 ]]
> I only remember the syntax (( a = 4 + 3 )) as an alternative to let and a 
> arithmetic evaluation like "print $((4+3))".

Well, until someone tells me whether (( .. )) or [[ .. ]] would be
preferable performance-wise (which probably doesn't make that much of an
impact) I'll keep using arithmetic expressions when it comes to numbers.
I find that a) logical and b) arithmetic expressions have a lot more
features for handling numbers than [[ .. ]] type tests do. I guess
that's my personal preference.

Someone who knows the code would have to help out with the performance
part of this issue. I won't even try to get my hands into that part of
the code. :)

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925