Reading From stdin After Command Line Redirection

[Ben Finney]

Tim Daneliuk <tundra at tundraware.com> writes:

> 'Easy there Rainman

I'll thank you not to use mental deficiency as some kind of insult.
Calling someone “Rainman” is to use autistic people as the punchline of
a joke. We're a community that doesn't welcome such ableist slurs.

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

Thank you for clarifying. 

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.

Rather, you should add to your program an option to allow specifying a
file to read, and present usage examples that don't redirect standard
input.

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

That's the right solution, I'd say.

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

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

-- 
 \       “A lot of people are afraid of heights. Not me, I'm afraid of |
  `\                                           widths.” —Steven Wright |
_o__)                                                                  |
Ben Finney