Re: Scripting support

[Marco Gerards]

Vladimir Serbinenko <address@hidden> writes:

>>That can be translated into some kind of pseudo language:
>>
>>1: list = 1 2 3
>>2: read i, list
>>3: echo $i
>>4: check list
>>5: je 2
>>
>>I know it's stupid and kind of silly like this.  But we have to define
>>a language.  It's important to discuss this on the list, IMO.
>>
>>
>>
> I thought about (a):

Right.  It's also possible.

> The question is how many commands to make: a lot (like in a where
> nearly every internal command corresponds to a scripting command) or
> make so few commands as possible. I wonder which approach is better
> (it's question about bugs and readibility, of course, not about speed)

I think we first have to determine:

1) Which commands should be supported.
2) The smallest subset of commands that should be generated.

Did you have a look at how bash does this?  Perhaps it even has a
completely different approach...

>>Which mail are you talking about (subject and date)?  I must have
>>missed a few the last months. :-(
>>
>>
> Re: [Patch] Scripting engine 25.09.2005
> [Patch] Scripting engine 24.08.2005
> It's just demonstration of some ideas. Now I think with new splitter
> it would be better to keep arglist unparsed. In this patch it was that
> if we have
> echo 1 2 3\;\$ ab$i;
> lexer returns (schematically)
> STRING(echo) STRING(1) STRING(2) STRING (3;$) STRING(abVAR(i)) SEMICOLON
> now I would do that it returns:
> STRING(echo 1 2 3\;\$ ab$i) SEMICOLON

Perhaps the best is to make a list of tokens we need to support.  With
such list we can determine how to detect them.

Thanks,
Marco