--- Bruno Haible <[EMAIL PROTECTED]> wrote: > Hello, > > > allocating pseudo-terminals in a portable way is a > nightmare. > > I agree. You also find some source code in this > direction in glibc,
I found the relevant source in glibc much more readable than my previous attempt with expect. > in xterm (horrible mess of #ifdefs), in > kdebase/konsole, in rxvt, > in gnome-terminal, ... > > > It would be nice if gnulib included portable > > replacements for GNU C library functions getpt, > > grantpt, unlockpt, ptsname, ptsname_r, openpty, > > forkpty, > > Is this API sufficient? I think so. The really needed op (for me) is to get a master-slave pair (openpty). I will implement something similar to forkpty myself, because forkpty closes 1 and 2 to redirect them to the pseudo-terminal, while I need to redirect them to pipes, and only 0 should refer to the pty (I hope that will work portably). > The example in the glibc > manual indicates that > some STREAMS operations are necessary as well, no? As far as I know (which is not that far), it is something specific of ptsname and ptsname_r (if you want to open the pseudoterminals from their name yourself). My guess is that the higher level APIs, openpty and forkpty, are unaffected. > The usual way for some code to come into gnulib is > that someone who needs > it writes it, and then submits it into gnulib. Someone with a stronger knowledge of the glibc than me could maybe extract those functions from the codebase. If no one steps up in some time, I will give it a try (since I need it to complete libsrcinst). Thanks for pointing at the glibc sources, they helped me understand some things better. Claudio __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
