GNU Common Lisp package implementing forkpty()

Question

I seek a GNU Common Lisp package which implements forkpty(); openpty() would also be a big plus, and login_tty() would be a luxury I could live with. (Duckduckgo, Google, etc. were of no help.) Is there such? Where?

Tophet

It would not surprise me if there wasn't one. Is using the FFI not an option for you? – Sonar

It's an option, but I'm new at LISP and wanted to keep the learning curve shallow for the moment. It looks like the FFI will probably be the way to go. Thank you. (And sorry about the delay in the response; I've just figured out how to see quickly that someone's added a comment. Duh.) – Tophet

If you are new at lisp, I would suggest you use just about any implementation other than GCL. It's not particularly performant, nor does it follow the ANSI standard. – Dagda

Try google.fr/search?q=axiom+openpty Just a guess: if Axiom uses openpty, since it's a Lisp program, maybe there is a link from one to the other... – Rianna

Thank you for this, arbautjc. It turns out, though, that I was able to turn the problem around. My code consists of two parts: C code, and LISP code. It's the LISP code that makes the decisions about what the program does, and the C code does things I can't do easily in LISP, as well as some of the things that need to be done more quickly. So the C code is the "main" program. It uses a pty to run the LISP code, to receive commands from it, and return responses to it over the pty. – Tophet

Answer 1

https://github.com/cffi-posix/ seems to be the right place to put the code you are looking for.

The idea is to port standard UNIX header files to CFFI-* packages.

Mannish

Answer 2

LISP is not know for its libraries, which is often though to be a side effect of its power (and lack of portability, and fragmented community, etc.). You are welcome to make your own and put it on github (or a similar platform)!

This is a rather unsatisfying non-answer, so: No, there probably isn't. If there is it is likely to not be portable enough to work on your implementation anyway.

Pretended

One of my objectives was to find something that was indeed portable, that I could take from, say, Linux (cough Wayland cough) to FreeBSD. I ended up "rolling my own". If I have a LISP program which does all the heavy computational lifting and a C program which does all the system stuff, there's no reason that the LISP program has to be on top, and the C program be a subprocess (using forkpty()). I can put the C program on top, and it can listen for commands from the LISP program. The LISP program, then, just communicates via its stdin and stdout. It works, so I really need no answer. :) – Tophet