Re: [Qemu-devel] curses.c: "We need a terminal output" ?

[Joachim Durchholz]

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