Reading From stdin After Command Line Redirection

[Tim Daneliuk]

I have a program that runs like this:

foo.py <inputfile

I want to reconnect stdin to the tty as usual after 'inputfile'
has been read so that things like raw_input and getpass
will work as expected.

So, after I do .... = sys.stdin.readlines(), how to I reopen
stdin in its nonredirected mode?

 

[Chris Angelico]

I have a program that runs like this:

foo.py <inputfile

I want to reconnect stdin to the tty as usual after 'inputfile'
has been read so that things like raw_input and getpass
will work as expected.

So, after I do .... = sys.stdin.readlines(), how to I reopen
stdin in its nonredirected mode?

You fundamentally can't reopen "stdin", as that will just be your
input file. What you want to do is open the console (TTY) itself. What
platform are you on?

ChrisA

 

[Chris Angelico]

Can you speak more about how you intend your program to be used? The
above request is incoherent, and I suspect you've made a design mistake.

There are times when this is correct behaviour - like asking for
passwords (SSH and sudo work like this).

ChrisA

 

[random832]

There are times when this is correct behaviour - like asking for
passwords (SSH and sudo work like this).

Less (or pagers generally, or an interactive text editor that allows
creating a file from standard input) would be another example of a
program where it makes sense to do this. It is an unusual thing to want
99% of the time, though.

 

[Chris Angelico]

You're both describing programs that read the console, which is not what
the OP was asking for. The OP was asking about re-opening stdin after
reaching EOF, which is incoherent as far as I understand it.

I'm still waiting for the OP to clarify what they want to do.

The OP did say "tty" and mentioned getpass.

ChrisA

 

[Tim Daneliuk]

You're both describing programs that read the console, which is not what
the OP was asking for. The OP was asking about re-opening stdin after
reaching EOF, which is incoherent as far as I understand it.

I'm still waiting for the OP to clarify what they want to do.

'Easy there Rainman, the question is entirely coherent,
though it may not be achievable this way. The goal of the
exercise was:

- Read a file the user specifies via command line redirection
- When the file is fully read, return to reading keyboard
input with things like raw_input and get_pass which I believe
use stdin as a source ... probably to avoid having to manually
cope with ttys and ptys themselves. One of those two functions -
I don't recall which - was giving me a problem with stdin redirected.

In the end, I broke down and added a command line parameter to
specify which file to read in so that stdin would be unaffected.

Now that I think about it, as I recall from the prehistoric era of writing
lots of assembler and C, if you use shell redirection, stdin shows
up as a handle to the file and there is no way to retrieve/reset it
its default association with the tty/pty. Since python is layered on
top of this, I expect the same would be the case here as well.

 

[Tim Daneliuk]

You're both describing programs that read the console, which is not what
the OP was asking for. The OP was asking about re-opening stdin after
reaching EOF, which is incoherent as far as I understand it.

I'm still waiting for the OP to clarify what they want to do.

'Easy there Rainman, the question is entirely coherent,
though it may not be achievable this way. The goal of the
exercise was:

- Read a file the user specifies via command line redirection
- When the file is fully read, return to reading keyboard
input with things like raw_input and get_pass which I believe
use stdin as a source ... probably to avoid having to manually
cope with ttys and ptys themselves. One of those two functions -
I don't recall which - was giving me a problem with stdin redirected.

In the end, I broke down and added a command line parameter to
specify which file to read in so that stdin would be unaffected.

Now that I think about it, as I recall from the prehistoric era of writing
lots of assembler and C, if you use shell redirection, stdin shows
up as a handle to the file and there is no way to retrieve/reset it
its default association with the tty/pty. Since python is layered on
top of this, I expect the same would be the case here as well.

 

[Tim Daneliuk]

Right. Congratulations for learning more about the design of the OS and
making a program that fits in well

It's only possible because, after some 30 years of doing this, I feel
very abelist ...

 

[Tim Daneliuk]

Congratulations for learning more about the design of the OS and
making a program that fits in well

It's only because of some 30 years of doing this that I now
feel quite abelist ...

 

[Tim Chase]

I think the request is incoherent: If you want to allow the user to
primarily interact with the program, this is incompatible with also
wanting to redirect standard input.

As a counter-example, might I suggest one I use regularly:

gimme_stuff_on_stdout.sh | vim -

I want to use vim interactively, but I want it to read the
file-to-edit from stdin.

-tkc

 

[Oscar Benjamin]

Now that I think about it, as I recall from the prehistoric era of writing
lots of assembler and C, if you use shell redirection, stdin shows
up as a handle to the file

Yes this is true. A demonstration using seek (on Windows but it is the
same in this sense):

$ cat test.py
import sys
sys.stdin.seek(0)
print('Seeked fine without errors')
$ python test.py
Traceback (most recent call last):
File "test.py", line 2, in <module>
sys.stdin.seek(0)
IOError: [Errno 9] Bad file descriptor
$ python test.py < other.dat
Seeked fine without errors

and there is no way to retrieve/reset it
its default association with the tty/pty. Since python is layered on
top of this, I expect the same would be the case here as well.

I think it is true that you cannot restore the association but you can
just open the tty explicitly as described here:
http://superuser.com/questions/569432/why-can-i-see-password-prompts-through-redirecting-output

(I can't test that right now as it obviously doesn't work on Windows).


Oscar

 

[Tim Daneliuk]

we don't welcome ableist (nor sexist) behaviour.

Well now I just feel so very awful ...

 

[Tim Daneliuk]

we don't welcome ableist (nor sexist) behaviour.

Well now I just feel so very awful ...

 

[Oscar Benjamin]

Well now I just feel so very awful ...

Please end this line of discussion. Ben is right: your comment was
entirely unnecessary and could easily offend.


Oscar

 

[Tim Daneliuk]

Please end this line of discussion. Ben is right: your comment was
entirely unnecessary and could easily offend.


Oscar

And his condescension was even more offensive.

But now I feel bad about myself and it's all your fault.

 

[Tim Daneliuk]

Please end this line of discussion. Ben is right: your comment was
entirely unnecessary and could easily offend.


Oscar

And his condescension was even more offensive.

But now I feel bad about myself and it's all your fault.

 

[Ethan Furman]

But now I feel bad about myself and it's all your fault.

Really?

*plonk*

 

[feedthetroll]

Am Donnerstag, 24. Oktober 2013 15:41:52 UTC+2 schrieb Tim Daneliuk:

And his condescension was even more offensive.
But now I feel bad about myself and it's all your fault.

No it is not. You are the only one responsible for your feelings.
Or is it your fault, that I fell bad, because you feel bad?

Btw it's your feelings, that grade an impartial statement as condescension.
As my feelings grade your statements as extremely offending. And (to follow your arguments) that's your fault!

 

[Ethan Furman]

I saw no such insult.

I don't know how wide-spread the movie is, but in the US "Rainman" is well-known. Short synopsis: younger brother
finds out about older brother; older brother has mental challenges (I don't recall which one); they spend about a week
together while younger brother tries to straighten out his life. So unless you're talking about Native American dances
it's an inappropriate moniker to apply to someone, particularly when you're being insulting.

And having said all that, we can have disagreements without name calling.

 

[Tim Daneliuk]

Am Donnerstag, 24. Oktober 2013 15:41:52 UTC+2 schrieb Tim Daneliuk:
No it is not. You are the only one responsible for your feelings.
Or is it your fault, that I fell bad, because you feel bad?

Btw it's your feelings, that grade an impartial statement as condescension.
As my feelings grade your statements as extremely offending. And (to follow your arguments) that's your fault!

Yeah ... definitely feel bad ... definitely...