qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: [Qemu-devel] curses.c: "We need a terminal output" ?
Date: Thu, 18 Apr 2019 13:02:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 04/18/19 07:02, Joachim Durchholz wrote:
> 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?

You're on a technical mailing list. An explicit problem statement is
instrumental for subscribers to understand the particulars of the
problem. "Somebody might have a problem" is a yes/no question and is
basically devoid of information.

>>> 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.

I've now re-read your original post again. I certainly wouldn't call it
"d'oh".

Protip: it's always best to insult the people that try to help you. The
more abrasive you are the more willingly they will spend their
nonexistent free time to help you. This is how a development mailing
list works. /s

>> 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).

https://pexpect.readthedocs.io/en/stable/FAQ.html

> Q: Can I do screen scraping with this thing?
>
> A: That depends. If your application just does line-oriented output
> then this is easy. If a program emits many terminal sequences, from
> video attributes to screen addressing, such as programs using curses,
> then it may become very difficult to ascertain what text is displayed
> on a screen.
>
> We suggest using the pyte library to screen-scrape. The module
> pexpect.ANSI released with previous versions of pexpect is now marked
> deprecated and may be removed in the future.

Have you tried pyte <https://pyte.readthedocs.io/en/latest/>?

On 04/18/19 07:02, Joachim Durchholz wrote:
> 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.

Because "ui/curses.c" is a display backend written on top of the Curses
API, and that API was *designed* (and so QEMU's display backend was
*designed*) for use on a terminal. That's why the isatty() call is
there, and has been there ever since the introduction of the curses
display backend (commit 4d3b6f6e1265, "Add an ncurses UI.", 2008-02-10).

> Note that I do agree that it's not what qemu should do by default,
> switching that check off should be an option.

Yes, it's also an "option" to ride a bycicle on a busy street at dusk,
without a visibility vest, a helmet, and bike lights. The bike will
still roll, steer and brake.

> I just never got around to making that suggestion because Gerd was so
> insistent on brushing the use cases aside.

Removing the isatty() check, conditionally or unconditionally, is a
suggestion that is counter to the design & purpose of "ui/curses.c", in
my opinion. To me it's a suggestion that is definitely inferior to using
a terminal emulator that works for your purpose.

Adding a different display backend to QEMU, such that it isn't based on
Curses but on a pipe, might make sense. I'm not sure.

Thanks
Laszlo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]