Meta: reading file from stdin while still interacting with the terminal

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Meta: reading file from stdin while still interacting with the terminal

Tim Chase
I'm playing around with a curses program and would like it to behave
similarly to how vim lets me do

   $ echo hello | vim -

where vim reads data from stdin but then interacts with the terminal
directrly.  What magic is vim doing here?

For context, it's a dumb Python curses program, but if I try to pipe
data into it, it interprets the EOF on stdin and then complains
there's no input for the curses getch()/getkey() call.

It's not exactly vim-related other than "vim does what I want; what's
it doing under the hood?"

Thanks for any pointers you might send my way.

-tim


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200419220646.069dce75%40bigbox.attlocal.net.
Reply | Threaded
Open this post in threaded view
|

Re: Meta: reading file from stdin while still interacting with the terminal

Eli the Bearded
(Sent directly and to list; list moderator -- if any -- is welcome
to reject this.)

Tim Chase wrote:
> I'm playing around with a curses program and would like it to behave
> similarly to how vim lets me do
>
>    $ echo hello | vim -
>
> where vim reads data from stdin but then interacts with the terminal
> directrly.  What magic is vim doing here?

I don't know what vim is doing, but I suspect it works like password
prompts in pipelines, eg:

    $ someprogram | ssh user@site "sh someotherprogram -"
    user@site password:
    $

Those read from STDERR to get keyboard input in the face of STDIN being
NOTATTY.

Elijah

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/495ZTJ5qJSzfYt%40panix5.panix.com.
Reply | Threaded
Open this post in threaded view
|

Re: Meta: reading file from stdin while still interacting with the terminal

Cameron Simpson-2
In reply to this post by Tim Chase
On 19Apr2020 22:06, Tim Chase <[hidden email]> wrote:
>I'm playing around with a curses program and would like it to behave
>similarly to how vim lets me do
>
>   $ echo hello | vim -
>
>where vim reads data from stdin but then interacts with the terminal
>directrly.  What magic is vim doing here?

Typically stdin, stdout and stderr are all os.dup()s of the terminal.

In the above vim's stdin will of course be the pipe but stdout and
stderr are still attached; it could dup one of them to stdin again and
proceed.

Or it might just open /dev/tty again after reading stdin if that isn't a
tty.

>For context, it's a dumb Python curses program, but if I try to pipe
>data into it, it interprets the EOF on stdin and then complains
>there's no input for the curses getch()/getkey() call.

Aye. The pipe is empty. Reach for the tty.

You _could_ close sys.stdin and reopen, but you might be better off just
using os.close(0) and then duping fd 1 to fd 0. I'd expect getch and
getkey to go direct to the file descriptor.

Cheers,
Cameron Simpson <[hidden email]>

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200420222039.GA46939%40cskk.homeip.net.
Reply | Threaded
Open this post in threaded view
|

Re: Meta: reading file from stdin while still interacting with the terminal

Tim Chase
On 2020-04-21 08:20, Cameron Simpson wrote:

> On 19Apr2020 22:06, Tim Chase <[hidden email]> wrote:
> >I'm playing around with a curses program and would like it to
> >behave similarly to how vim lets me do
> >
> >   $ echo hello | vim -
> >
> >where vim reads data from stdin but then interacts with the
> >terminal directrly.  What magic is vim doing here?  
>
> Typically stdin, stdout and stderr are all os.dup()s of the
> terminal.
>
> In the above vim's stdin will of course be the pipe but stdout and
> stderr are still attached; it could dup one of them to stdin again
> and proceed.
>
> Or it might just open /dev/tty again after reading stdin if that
> isn't a tty.

Thanks, Cameron & Eli.  I tried meandering through the vim source
and, while this is what it looked like it was doing (i.e., using
stderr for input), it made no sense to me.  Now it makes more sense.

So now at least I have two possible courses of action (use stderr or
(re)open /dev/tty).  Time to try and bludgeon curses into pulling its
input from some place other than stdin.  Or possibly re-attaching
stdin to the stderr file descriptor.

Thanks again!

-tim




--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200421141438.395b9b12%40bigbox.attlocal.net.