On Tue, Jan 13, 2009 at 8:28 PM, Alan Gauld <[email protected]> wrote: > The way other Unix style programs deal with this is to write the code > to read from a general file and if you want to use stdin provide an > argument of '-':
That's a good idea, actually -- I hadn't thought of that. Although I use that "-" a lot in command line programs ... It would force someone to be specific about what it was they wanted the script to do ... then, I guess, I can just have it do an if statement that asks: if args[0] == "-" then ... blah. I may do that ... the script, itself, actually handles attachments, too ... so I could use that flag, also, to say: attach the standard out to an email. On Tue, Jan 13, 2009 at 8:45 PM, John Fouhy <[email protected]> wrote: > This might work: > > import select, sys > def isData(): > return select.select([sys.stdin], [], [], 0) == > ([sys.stdin], [], []) > > if isData(): > print 'You typed:', sys.stdin.read() > else: > print 'Nothing to see here.' Oh ho ho! Very neat! I will have to head over to the python docs to see what that is but it seems to work! > I say "might" because it is OS-dependent, but I guess you are using > unix/linux. Yea - you guessed right. > Source: > http://www.darkcoding.net/software/non-blocking-console-io-is-not-possible/ > > I found that by searching for "python stdin non-blocking". This is > because "blocking" is jargon for "waiting until something happens". > In this case, stdin.read() is blocking until it sees some data with an > EOF. Thanks for that tip -- as you probably guessed, google wasn't turning up too many results for me. But this is working now. However ... reading the next comment has me thinking again: On Tue, Jan 13, 2009 at 8:55 PM, Steve Willoughby <[email protected]> wrote: > This is playing a dangerous game, though, of introducing a race condition. > Is there nothing on the standard input RIGHT NOW because the source on > the other end of the pipe hasn't managed to generate anything yet, or > because there's nothing piped? > > A better approach is either to explicitly specify whether to read from > stdin or a file, as Alan demonstrated (and the fileinput module implements > this for you, by the way), or to see if stdin is connected to a terminal > or not. So instead of seeing if anything's showing up (and introducing > timing dependencies and uncertainty), see if it's attached to a real > terminal at all. On Unix, os.isatty(sys.stdin) will tell you this. Does this concern still apply with John's suggestion? I just tested it in my little application and didn't have an issue ... of course, I only ran a couple different command line items before throwing up my hands in celebration. I can go to using the "-" option ... although, to be honest, I like the idea of the script thinking for itself ... that is: if there is stdin, use it -- if not, not ... and, I was thinking of attaching the stdin as a text file, if present. And not attaching anything, if not. Thanks everyone! _______________________________________________ Tutor maillist - [email protected] http://mail.python.org/mailman/listinfo/tutor
