On 29 August 2012 17:02, David Korn <d...@research.att.com> wrote:
> Subject: Re: Re: [ast-developers] Fwd: Per thread open(), stat(), rename()
> and so on, and *at() API
> --------
>
>
>> Well, if you use {a} then please remove the mamfile code which
>> generates libshell.so - libshell.a is sufficient to build ksh. So far
>> a shared library of libshell doesn't make sense until it gets actually
>> usable for embedding. Right now it doesn't work for that purpose and
>> if you pick {a} over {b} then I don't see a chance that it'll get any
>> better anytime soon.
>>
>> Lionel
>>
>
> It does work for embedding. It is embedded in tksh.
Excluding tksh and dtksh - has anyone ever managed to use libshell for
anything else? Anyone? I think the answer is a bold "NO" because the
libshell API is NOT suited for tasks outside making more shell
variants. We've been there and figured that libshell can not be used
in ANY larger project because it fiddles with so many global resources
around that it sooner, more sooner blows your application up. The
libshell code is NOT designed to share control with anything else than
itself.
In fact your option {a} will make that worse instead of better it, to
a point where I say that we have to take the libast code to
Sourceforge.com, Google code or github and fork it to get someone sane
working on that code. Sorry, but that's the truth.
Lionel
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
