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?
> > - 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.
> builtin implementations must return / close / free and resources before
> returning
OK, libfind does not yet free the allocated tree from the parser.
But I would first like to get some feedback...
> 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.
> so time is also a managed resource
> builtins that may run a long time announce this via ERROR_NOTIFY in the
> boilerplate initialization:
>
> #include <cmd.h>
>
> int b_foo(int argc, char** argv, void* context)
> {
> cmdinit(argc, argv, context, ERROR_CATALOG, ERROR_NOTIFY);
> ...
> }
>
> 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.
bsh uses the followin builtin interface:
becho(vp, std, flag)
register vector *vp;
register FILE *std[];
int flag;
/*
* Our internal argc/argv structure.
*/
typedef struct {
int v_ac;
char *v_av[1];
} vector;
flag is an execution flag, std[] is an array of 3 stdio entries. This
allows to redirect I/O without copying over stdin/stdout/stderr which
would not work in case that there is unknown extra (hidden) space
associated with stdio.
becho()
uses fprintf(std[1], ...) instead of printf().
Wouldn't something like this make it possible to use non ksh specific libraries
for ksh builtins?
A libfind based buildin could look this way:
b_find(int ac, char ** av, FILE *std[], int *interrupted)
the FILE *[] would allow to be stdio compatible.
int *interrupted would work around the Mac OS X Linker problem.
find.c would be implemented this way:
main(ac, av)
int ac;
char *av[];
{
int intr = 0;
FILE *std[3];
std[0] = stdin;
std[1] = stdout;
std[2] = stderr;
return (b_find(ac, av, std, &intr));
}
What we still miss is locale handling....
b_find() is currently a renamed main() and calls:
#ifdef USE_NLS
setlocale(LC_ALL, "");
bindtextdomain("SCHILY_FIND", "/opt/schily/lib/locale");
textdomain("SCHILY_FIND");
#endif
This must be done different.....
setlocale(LC_ALL, ""); must be done by the caller
gettext() calls need to be replaced by dcgettext()
This is something I did not yet test...
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
