Am 17.04.19 um 20:27 schrieb Laszlo Ersek:
So, let's look at your original question again (which was not a problem
statement):
So you need an explicit problem statement to know that somebody might
have a problem?
what's the reasoning behind "We need a terminal output" in curses.c?
The reasoning is that "curses.c" is a QEMU display backend written in
terms of the Curses [XCURSES] interface specification, and that
interface specification is inherently based on terminals, as defined by
the General Terminal Interface of the Single Unix Specification.
Sure.
If you tell us what you want to achieve in the end (i.e. you state the
problem),
I described three use cases. I mentioned which of them was mine.
Problem statement: my use case doesn't work. D'oh.
Let me speculate a bit. You mentioned wanting to connect "ui/curses.c"
to a pipe, possibly to transfer the output elsewhere. This is a common
use case -- it's what terminal emulators such as "xterm" do, also what
"ssh" does (when you log in interactively with it). "screen" and "tmux"
are other programs in this class.
The way they all work is, they set up a pseudo-terminal (pty). The pty
has a master end and a slave end.
I know expect, and yeah it works. It's just that TCL is too old-school
to cleanly handle all edge cases, and I don't have the time budget to
really learn all the ins and outs of TCL.
pexpect doesn't work, because it would insist on line buffering (try
doing a login or responding to a prompt).
expectit doesn't work, because it simply opens a pipe. It's otherwise
the best-maintained, best-structured API. Being Java, it's a bit
difficult to interface to C, besides opening ptys is pretty nonportable
so it would have been a biggish project to give the maintainer a patch
that is useful to him.
So the workaround is to use expect anyway. So happy :-(
> (pexpect)
Then you can read the master-end (pexpect should let you do that as
well) -- the master-end will indeed read similarly to pipe.
Sure, it fails due to line buffering. Can't wait for the login prompt
because it isn't sending an eoln.
> Just be
aware that all the terminal output goo, such as cursor positioning,
color change sequences, beeps, screen resolution changes, etc, will show
up as binary garbage in the stream.
It's just escape sequences, and while they're a bit of a pain, they can
be filtered out.
If TCL were a sane language, I could do that with a bit of code, but it
isn't, so I'm doing that mentally - it's a pain, but it works.
I'm still wondering why there's such a stiff opposition to giving that
with qemu.
Note that I do agree that it's not what qemu should do by default,
switching that check off should be an option.
I just never got around to making that suggestion because Gerd was so
insistent on brushing the use cases aside.
Jo