Daniel Barlow <dan@...> writes:
> 2) The tty modes. I don't know what they're _supposed_ to be
> (actually, i think it probably varies according to the end-user's
> application) but with the current behaviour on Linux if you write
> to the pty from the parent (Lisp) process, then read back again,
> you get what you just wrote. As opposed to, say, whatever the
> client application wrote. "loopback" is the word I'm looking
> for here.
> The attached patch has the obvious fix to problem (1), and _a_ fix to
> problem (2), with the obvious caveat that we can't really fix the
> problem until we know what the right answer is. However, it does get
> us a bit nearer to grace anyway, by losing the Lisp-side tty mode setting
> stuff altogether and doing it in C instead. With termios instead of
> sgtty, which is probably a whole lot more portable (at least, it's
> code I borrowed from detachtty, which I think runs on Linux, BSD,
> Solaris, a few other places)
I actually had this on my todo list when I was doing the NetBSD port,
but I never got around to fixing it. The sgttyb stuff is indeed quite
archaic and termios is definitely the right answer here.
As to what exactly the tty settings should be, I don't think there's
a single right answer. However assuming that run-program is mostly
used for invoking processes that the user will not directly talk to,
I think that disabling canonical input processing in addition to echoing
would be good. Probably also the CR-NL frobbing (ICRNL and ONLCR off).
I'm not near an sbcl right now, but is there a particular reason why
run-program must even use a pty, instead of just setting up pipes
for the in/out/err of the child? For running simple subprocesses,
ptys are just an added complication and a resource hog besides.
From: Daniel Barlow <dan@te...> - 2003-01-17 20:45:17
Valtteri Vuorikoski <vuori@...> writes:
> I'm not near an sbcl right now, but is there a particular reason why
> run-program must even use a pty, instead of just setting up pipes
> for the in/out/err of the child? For running simple subprocesses,
> ptys are just an added complication and a resource hog besides.
It's an option - in fact, the whole run-program interface is a
plethora of options, and I think that some of them (this one, for
example) have probably bitrotted.
For running simple subprocesses, granted, ptys are just an added
complication, but when talking interactively to something that accepts
interactive input (gdb or wish or some kind of shell) it seems
hellishly complicated to get sane (i.e. line-based or no) buffering
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Get latest updates about Open Source Projects, Conferences and News.