Re: Ada.Command_Line and wildcards

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Markus E Leypold wrote:

>> I wouldn't want to use Ada as an interactive command language. There
>> are, I think, ways to get (1) type safety, (2) proper quoting
>> without too much overhead. I, personally, would built a new
>> generation shell system on, ahem, OCaml, because of the type
>> interference and because functional composition might take the part
>> pipes have played in the past.
>
> I'm not sure I would use OCaml as the basis.  

Well, I think I will. For me it's more a hacking project (that is, get
something better / different for as cheap as possible: After all I
don't want to spent years with that), so I'll have to built on an
existing language. Some other constraints which are not derived from
"cogito ergo sum" but just express my desires are:

 - functional
 - strong static type system
 - possible to create C bindings
 - dynamic loading of byte code should be possible.
  
> To me it seems too big and complicated for the purpose.

A running Ocaml toplevel requires only slightly more meory than bash
and it is faster and needs to fork less external tools.

> But the shell (interactive command language) should support all the
> different kinds of interprocess communication that the underlying
> kernel supports.

But?

> That doesn't quite seem to be the case with sh(1).

Yes, it isn't. That is the reason ksh was invented and came too late
to become standard shell on all Unices.


>>> Suggesting replacement parts for pieces of Unix really means
>>> suggesting to change its design.
>>
>> No. I do think you use the word design in rather too broad a
>> sense. Else we could never change ynthing without "changing the
>> design".
>>
>> One must perhaps live with the notion that no OS is just amonolithic
>> complex of design choices. It is not simply a "design change" if I
>> (user) change to another shell (that is designed to be user
>> replacable, BTW).


> Since sh(1) is a requirement in the POSIX standard, it is a change in
> the design to substitute sh(1) with something else (although it is a
> change the remaining system is designed to allow).  

You and George are using the word "design" rather to gratiously. More
about that another time.

> Adding yet another user selectable shell to the system is on the
> other hand not something I consider a change in the design.

Regards -- Markus