getting a "simple" program to work

John Haggerty bouncyinc at gmail.com
Thu Aug 13 06:41:47 CEST 2009


Just checking to see if this is more adequate to what you would have wanted
to see I didn't get any feedback so I wasn't quite sure of this at the
present time.

On Tue, Aug 11, 2009 at 11:02 PM, John Haggerty <bouncyinc at gmail.com> wrote:

>
>
> On Tue, Aug 11, 2009 at 10:46 PM, Chris Rebert <clp2 at rebertia.com> wrote:
>
>> On Sun, Aug 9, 2009 at 8:42 PM, John Haggerty<bouncyinc at gmail.com> wrote:
>> > ok so I know this is one of those "weird" requests but here me out.
>> > So far I have an issue with a package for python called "libgmail" which
>> is
>> > basically a gmail interface for python to send messages remoetly.
>> > Works ok except that the 'sendMessage' routine is bad.
>>
>> How is it "bad" precisely? Be specific (e.g. error message(s),
>> description of observed incorrect behavior).
>>
>
> In regards to bad would be failing to transmit claiming that the submittal
> is wrong for the transmit string.
>
> (where username is my gmail username and "password" is my gmail password to
> the test account, 6666666969 is the mobile number in question '00' is my
> "carrier id" from the ogss code example which is just an array location from
> a preformatted part of the string [probably from wikipedia on mobile carrier
> email addresses to cell phones], I actually got desperate and commented out
> the first attempt to transmit which I located in the code as just the
> "instructions" the code fails on re-transmission, I later on looked at the
> file and located that it was a zero byte file of no content. The program
> itself looks for a command from the user's cell phone directly from mms sent
> to the target gmail account prefaced by "Ogss" and anything else is treated
> as a command but since the command failed on the first transmit I don't
> think it's the command per se).
>
> owner at bouncyinc:~/Desktop/OGSS$ python ogss.py username password
> 6666666969 00
> Starting ogss
> Logfile at:/home/owner/ogss.log
> Opening log file for reading
> Parsing user input
> Connecting to Gmail
> Logging into Gmail
> Opening log file for writing
> Listening for commands
> Processing Command
> ls: unrecognized option `---------------------------------------------'
> Try `ls --help' for more information.
> Seding back results
> Traceback (most recent call last):
>   File "ogss.py", line 127, in <module>
>     main(sys.argv)
>   File "ogss.py", line 110, in main
>     account.sendMessage(tosend)
>   File "/usr/lib/python2.5/site-packages/libgmail.py", line 615, in
> sendMessage
>     raise GmailSendError, resultInfo[SM_MSG]
> libgmail.GmailSendError: Please try again.
>
> I traced the result to the sendMessage routine and noted that anytime it
> tries to send anything it fails this also fails with the standard "docs"
> package for libgmail 0.30 docs from the maintainer's site.
>
> Now the part where it *does* fail is where it has an issue with looking at
> the trailing info but then it would have logged the info to the file and
> emailed me back junk (which it didn't)
>
> I assume this could be done on any system just replace 'ls' with 'dir' or
> the equivalent.
>
>
>>
>> > This is included in the above attachment
>> > it's used in a program called "ogss" which is an sms interface to gmail
>> to
>> > basically read gmail and then have a command done on a remote machine
>> and
>> > then spat out on the local machine to a log file that's opened and then
>> > emailed back
>> > problem is that the sending back routine fails.
>>
>> Which routine is that exactly? Please also specify exactly how it is
>> failing (e.g. error message(s), description of observed incorrect
>> behavior).
>>
>> I apologize if these questions are answered in comments in the
>> attachments, but to be honest, the fact that you didn't (or couldn't)
>> put the specific problematic sections of code (and/or error messages)
>> inline in your message makes it less likely that people (such as
>> myself) will try to help you due to the volume of code you're making
>> people wade through (i.e. people tend not to read large code dumps,
>> /especially/ in attachments).
>>
>> Cheers,
>> Chris
>> --
>> http://blog.rebertia.com
>>
> That's ok I understand I hope that helps at least in part.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090812/5689c8da/attachment.html>


More information about the Python-list mailing list