On Tue, Jan 13, 2009 at 9:05 PM, John Fouhy <j...@fouhy.net> wrote:
> It's easy to test:
>
> ### test.py ###
> import time
> time.sleep(1)
> print 'foo'
> ###
>
> $ python test.py | python stdintest.py
> Nothing to see here.
> close failed: [Errno 32] Broken pipe
>
> [not shown: the 1 second pause after "Nothing to see here." showed up]
>
> You could "fix" it by adding a delay to your consumer script.. as long
> as none of your input scripts take longer than the delay to generate
> output. Or do things differently, which might be smarter :-)
Yea - I can see where that would become a problem ... hmm ... I think
I am going to look into what Steve is suggesting with the fileinput
module ...
On Tue, Jan 13, 2009 at 9:10 PM, Steve Willoughby <st...@alchemy.com> wrote:
> As the Zen of Python states, "explicit is better than implicit."
>
> Scripts which just magically "do the right thing" can be cool to play
> with, but they have a nasty tendency to guess wrong about what the right
> thing might be. In this case, you're making assumptions about how to
> *guess* whether there's standard input piped at your script, and running
> with those assumptions... but there are easily identified cases where
> those assumptions don't hold true.
That's a good point ... here is more of what I am trying to do ...
minus exceptions and the actual functions that sends the mail ... I
could use the "-" stdin bit to either signify the body message of the
email, or an attachment ... or, I guess, both ... (I left out the
details of actually emailing stuff and all the imports):
def sendMail(recipient, subject, text, *attachmentFilePaths):
#here is the function used to send the mail and attachments...
def main():
parser = OptionParser(usage="%prog [options: -s -t -m ]
[attachemnts, if any...]")
parser.add_option("-q", "--quiet", action="store_true", dest="quiet")
parser.add_option("-s", "--subject", action="store", type="string",
dest="subject", default=default_subject)
parser.add_option("-t", "--to", action="store", type="string",
dest="recipient", default=default_recipient)
parser.add_option("-m", "--message", action="store",
type="string", dest="message")
(options, args) = parser.parse_args()
sendMail(options.recipient, options.subject, options.text, args)
$ sendmail.py -t m...@me.com -s "my subject" -m - attament.jpg
or maybe
$ dmesg | sendmail.py -t m...@me.com -s "my subject" -m "here is output
from dmesg" - someotherattachmenttoo.doc
Thanks for all this help.
On Tue, Jan 13, 2009 at 9:10 PM, Steve Willoughby <st...@alchemy.com> wrote:
> On Tue, January 13, 2009 17:59, Damon Timm wrote:
>> ... 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,
>
> Look at the fileinput module. If you're looking at the command line for a
> list of filenames, which may include "-" to mean (read stdin at this point
> in the list of files), your script's logic is reduced to simply:
>
> while line in fileinput.input():
> # process the line
>
> and your script focuses on its specific task.
>
>>> 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
>
> Yes, it does. And in a trivial case, it will usually work. But don't
> base your solutions on something that looks like it sorta works most of
> the time but isn't really the recommended practice, because it will break
> later and you'll spend a lot of time figuring out why it's not being
> reliable.
>
>> 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.
>
> As the Zen of Python states, "explicit is better than implicit."
>
> Scripts which just magically "do the right thing" can be cool to play
> with, but they have a nasty tendency to guess wrong about what the right
> thing might be. In this case, you're making assumptions about how to
> *guess* whether there's standard input piped at your script, and running
> with those assumptions... but there are easily identified cases where
> those assumptions don't hold true.
>
> Also, think of anyone other than you (or you at a later date) using this
> script. The number of things the script does for no apparent reason can
> lead to frustration and doubt that you really know, as a user, what the
> script is really going to try to do in a given situation, and what you'll
> have to do on your end to "trick" it into doing what you really wanted in
> the first place. It's cute, but ultimately implicit behavior doesn't make
> for good, long-lasting solid applications.
>
>
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
