Re: [PATCH v2 24/25] Add new command to create extra console/mi UI channels

Eli Zaretskii
2016-03-21T17:12:25Z

> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Mon, 21 Mar 2016 16:51:21 +0000
>
> > Shouldn't this (and other related) code be conditional of PTYs being
> > supported? Otherwise, this is just useless baggage, right?
>
> Actually this should all work on Windows too, for example.

Are you sure? The code does this, for example:

> +static FILE *
> +open_stream (const char *name)
> +{
> + int fd;
> +
> + fd = open (name, O_RDWR | O_NOCTTY);
> + if (fd < 0)
> + perror_with_name (_("opening terminal failed"));
> +
> + return fdopen (fd, "w+");
> +}

How do you expect this to work on Windows? For starters, O_NOCTTY is
not supported. And what would you use for 'name' here? More
importantly, each Windows process can have only one console at a time,
AFAIK.

Am I missing something?

> MI doesn't really need a PTY, so even though currently the command's
> online help and git logs say usage is "new-ui INTERP TTY", that TTY part
> could actually be the name of any bidirectional stream.
>
> E.g., it could be a bidi unix domain socket, on Linux, or on Windows,
> I think it should work to pass a console name, or a bidirectional
> named pipe path, though I haven't tried it.

There are no Unix domain sockets on Windows, AFAIK. As for a console
name, see above.

> If necessary, it would also be easy to extend the command to support
> separate streams for in/out/err, like, e.g.:
>
> (gdb) new-ui INTERP IN OUT ERR
>
> And then it'd be possible to open a new MI channel through
> unidirectional named pipes, regular files, etc. too.

But doesn't readline need a console-compatible device? PTYs pass the
isatty test, but pipes and regular files fail it, so will readline at
all work?

I have a dreadful feeling that I'm missing something very important
here, because I'm sure I don't tell anything you don't already know.