On Fri, 23 Feb 2007 00:12:25 +0100 [EMAIL PROTECTED] (Joerg Schilling) wrote:
> Glenn Fowler <[EMAIL PROTECTED]> wrote:
> > On Thu, 22 Feb 2007 22:34:05 +0100 [EMAIL PROTECTED] (Joerg Schilling)
> > wrote:
> > > - How is the I/O redirection done for ksh93 builtins?
> > ksh and its builtins use -last sfio for io
> > external builtins that do io must also use sfio
> > sfio provides a <stdio.h> wrapper so external builtins
> > using <stdio.h> are possible as long as they are built against
> > -last and the ast headers
> I am a bit confused now.
> This looks like it is not possible to have a generic library that may also be
> used by ksh93. Didn't you tell me before that it is possible to combine the
> schily and the ast world?
my comments were that the apis were probably compatible
I didn't go into the exact details of building a builtin
if a builtin does io it will either have to compile against
the ast headers or it will have to completely encapsulate
its own io, including final flushing and freeing resources
in addition it must do so without interfering with state
that ksh may be maintaining
e.g., only fd's provided by syscalls are available
> > > - How does ksh93 look for shared libs and how does it
> > > find which builtin commands are inside a shared lib?
> >
> > internally ksh uses the ast -ldll library to locate plugin libraries
> > in a machine independent fashion (builtin library == plugin library in this
> > scheme)
> >
> > -ldll maps generic names valid on all sw platforms to sw specific names
> > the physical library files must reside in ../lib/SUBSYSTEM directories on
> > $PATH
> > e.g., libfind for ksh on solaris would be ../lib/ksh/libfind.so
> >
> > at the shell prompt the "builtin" command handles plugin libs and buitins
> > for libfind, given the above plugin lib name and b_find builtin name:
> > builtin -f find find
> > (see builtin --man and/or builtin --html)
> OK, so for a single command in a single library things should be easy.
no, it works for multiple libs/builtins
builtin -f foo foobar boofar ...
builtin -f bar barfoo barboo ...
> > builtin implementations must return / close / free and resources before
> > returning
> OK, libfind does not yet free the allocated tree from the parser.
yeah, this is sometimes the biggest chore when converting a formerly
standalone command implementation to a builtin
the ast vmalloc() which can allocate piecemeal from a region and then free
the entire region with one call handles this nicely
> > interrupts are blocked by ksh while builtins execute
> In my bsh, interrupts are catched and the external variable "ctlc" is
> incremented > 0 if a command is interrupted.
> > and then must periodically test
> > cmdquit() != 0
> > which means the builtin should free resources and return with and error
> > status
> This looks similar to my ctlc in bsh.
> BTW: are you able to deal with cmdquit() with the "broken" linker on Mac OS X?
> The Mac OS X linker is unable to deal with common variables or with function
> references from the library to the caller.
ksh communicates with the builtin via a separate call to b_foo() with argc==-1
which sets a b_foo() private static that is checked by the cmdquit() macro
argc==-1 is handled by the cmdinit() call just after main
> A libfind based buildin could look this way:
> b_find(int ac, char ** av, FILE *std[], int *interrupted)
the ksh b_*() prototype will not change
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
