David Korn <dgk at research.att.com> wrote:
Let me again quote my old code...
a.c: (compiled against sfio)
int
b_find(int ac, char **av, void *xxx)
{
int i, o, e;
i = fileno(stdin);
o = fileno(stdout);
e = fileno(stderr);
return xfind(ac, av, dup(i), dup(o), dup(e));
}
-----
b.c: (compiled against stdio)
int
xfind(int ac, char **av, int i, int o, int e)
{
int ret;
FILE *std[3];
std[0] = fdopen(i, "r+");
std[1] = fdopen(o, "w");
std[2] = fdopen(e, "w+");
ret = bfind(ac, av, std); /* <----- real find call */
fclose(std[0]);
fclose(std[1]);
fclose(std[2]);
return (ret);
}
> There is another way. On each system we generate an intercept
> library that maps stdio calls into sfio calls. Currently this
> library is not linked into ksh93 because ksh93 doesn't use stdio.
> However, if ksh93 were built with this library, or if a dynamic
> version of this library were mapped in with builtin -f, then it
> should be possible to run built-ins that were compiled against
> stdio.
This will not work.
If you do not use a "FILE *std[3]" parameter for the builtin,
you would need to overwrite stdin/stdout/stderr to allow shell I/O
redirection.
as something like: *stdin = *newstdin will only the visible part
of the "stdin" structure and not the hidden parts.....
> However, the builtins would still have to handle cleanup correctly
> and allow the shell to check for signals periodically.
> There are a couple of methods of doing this which are not
> fully documented although there are examples in libcmd.
This is a real problem as I see no way to intercept with ksh93
in a working way (see below)...
> However, the recommended way to do builtins is to include
> <shell.h> and link with ast. This way stdio calls will
> be mapped to sfio calls at compile time and several
> other calls (for example open) will be intercepted so
> that special /dev/... types not recognized by the OS like /dev/tcp
> will be supported.
Sorry, this is impossible if you like to compile something like libfind
that should be usable with any pther Solaris program or library.
This is a real problem of the current portability method used in ksh93.
It uses private interfaces _instead_ of system supplied interfaces.
My portability method is to use private interfaces _in_addition_to_
system supplied interfaces.
My binaries may be used together with any other program on Solaris that
does not try to redefine system interfaces.
.... Now back to the shell builtin signal handling.
My shell (bsh) uses a variable that is set to 0 before a shell builtin
is called. This variable is incremented by the shell if a signal is received.
For this reason, it is simple to call simething like:
bfind(ac, av, std, &ctlc)
where ctlc is the variable that is incremented on signals.
Some code insice libfind would check for:
if (*ctlcp > 0)
<abort libfind>
If libfind is used outside a shell (which I would expect to be the more
frequent useage), I could pass a dummy variable instead without losing
performance.
It seems that you like a shell to call a ksh93 specific macro in order to
test for whether to abort... this does not look like a method that is
compatible with other use cases for code that may sometimes used as shell
builtin.
Do you have an idea for adaptation software or are you willing to change the
ksh93 interface in to make it more compatible to other software?
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
