By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,898 Members | 1,198 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,898 IT Pros & Developers. It's quick & easy.

Code run from IDLE but not via double-clicking on its *.py

P: n/a
When I double-click on "some.py" file console window appears just for a
moment and right after that it's closed. If this script is started from
inside of IDLE (F5 key) then it executes as it should be (e.g.
executing all its print statements).

Any ideas? OS: Windows; Python 2.3.4. Thanks.

Aug 30 '05 #1
Share this Question
Share on Google+
28 Replies


P: n/a
max
"n00m" <n0**@narod.ru> wrote in
news:11*********************@g47g2000cwa.googlegro ups.com:
When I double-click on "some.py" file console window appears just
for a moment and right after that it's closed. If this script is
started from inside of IDLE (F5 key) then it executes as it
should be (e.g. executing all its print statements).

Any ideas? OS: Windows; Python 2.3.4. Thanks.


It's a windows thing. The shell windows opens to run the script in is
closing when the script finishes.

Try opening a shell (Start->Run: cmd.exe on NT/2k/XP or Start->Run:
command.com on 95/98) and then either type the full path to the script
or navigate to it and execute it.

max
Aug 30 '05 #2

P: n/a

n00m wrote:
When I double-click on "some.py" file console window appears just for a
moment and right after that it's closed. If this script is started from
inside of IDLE (F5 key) then it executes as it should be (e.g.
executing all its print statements).

Any ideas? OS: Windows; Python 2.3.4. Thanks.


Your console window closes when the program terminates.
And no, you won't necessarily see any of your print statements
before the window closed. They were buffered and the window
closed before they could be displayed.

Start a console window manually. From the command prompt,
type

some.py

or

python some.py

Aug 30 '05 #3

P: n/a
Thank you, guys, for your replies!

Now it works!

Aug 30 '05 #4

P: n/a
Oops.. not everything so super as I thought.
Incredible but from command line it results as:

D:\>python23\python d:\python23\00\socket6.py
Traceback (most recent call last):
File "d:\python23\00\socket6.py", line 1, in ?
import socket, thread
File "D:\Python23\00\socket.py", line 3, in ?
s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
AttributeError: 'module' object has no attribute 'AF_INET'

D:\>

FROM IDLE 1.0.3 THE SAME SCRIPT WORKS PERFECTLY !!!

WHY ON THE EARTH <'module' object has no attribute 'AF_INET'> ???

Aug 30 '05 #5

P: n/a

[n00m]
WHY ON THE EARTH <'module' object has no attribute 'AF_INET'> ???


Because you have a socket.py in d:\python23\00 which is being picked up
instead of Python's own socket module. You shouldn't give your modules
the same name as Python's own modules.

--
Richie Hindle
ri****@entrian.com
Aug 31 '05 #6

P: n/a

Richie Hindle wrote:
Because you have a socket.py in d:\python23\00 which is being picked up
instead of Python's own socket module. You shouldn't give your modules
the same name as Python's own modules.


Yes, Richie! YOU are dmndly RIGHT! Thanks.

Aug 31 '05 #7

P: n/a
Funnily but I still can't get the code working... WITHOUT IDLE.
I think it's because of "import thread" line. Seems something
wrong with "opening" this module. In IDLE it works OK.

Aug 31 '05 #8

P: n/a

[n00m]
Funnily but I still can't get the code working... WITHOUT IDLE.
I think it's because of "import thread" line. Seems something
wrong with "opening" this module. In IDLE it works OK.


It's difficult to diagnose your problem with so little information. Please
post:

o The command you're typing into the command prompt
o The error message you're getting
o The full traceback
o The code you're trying to run, or if it's too big then the piece that
the last line of the traceback refers to

Thanks,

--
Richie Hindle
ri****@entrian.com
Aug 31 '05 #9

P: n/a
n00m wrote:
Funnily but I still can't get the code working... WITHOUT IDLE.
I think it's because of "import thread" line. Seems something
wrong with "opening" this module. In IDLE it works OK.


Now, let's see ... [presses fingers to temples and exercises psychic
powers] ... ah yes, its because you're DOING SOMETHING WRONG :-)

Unfortunately "can't get the code working" isn't a very helpful
description. Can you explain (preferably with a traceback) how it fails?

Generally speaking, when you take your car into the garage (American:
shop) because "it won't go" it's OK because the technicians can try and
start it themselves. We don;t have your code readily to hand, so we need
a bit more to go on.

Generally speaking you would do well to try the threading module rather
than thread unless you have a specific reason for not doing so. But if
you post your code (or even better a subset of your code that
demonstrates the error so people can pick it apart for themselves) with
a traceback from the interpreter or a full description of what you
expected the code to do and what it actually does we'll be able to help
much more easily.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Aug 31 '05 #10

P: n/a
Richie; Steve; Thanks for your replies!
o The command you're typing into the command prompt
o The error message you're getting
o The full traceback
o The code you're trying to run, or if it's too big then the piece that
the last line of the traceback refers to


1.
D:\>python23\python d:\python23\socket6.py [Enter]

It's OK so far. Python code is launched and starts listening
to port 1434 (see the code below; it's the same code as in my
neibouring topic).
Now I launch a vbs script (which will connect to port 1434).
I.e. I just double-click "my.vbs" file.
And... voila! In a moment & silently console window closes
without any error messages (or I just don't see them).
But VBS reports a network error. Tested on win2k and win98.
In IDLE it works ABSOLUTELY FINE! Prints statements in the
code do exactly what they must do.
import socket, thread
host, port = '127.0.0.1', 1434
s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s2.connect((host, 1433))
s1.bind((host, port))
s1.listen(1)
cn, addr = s1.accept()

def VB_SCRIPT():
while 1:
data = cn.recv(4096)
if not data: return
s2.send(data)
print 'VB_SCRIPT:' + data + '\n\n'

def SQL_SERVER():
while 1:
data = s2.recv(4096)
if not data: return
cn.send(data)
print 'SQL_SERVER:' + data + '\n\n'

thread.start_new_thread(VB_SCRIPT,())
thread.start_new_thread(SQL_SERVER,())

Aug 31 '05 #11

P: n/a
Steve Holden wrote:
Now, let's see ... [presses fingers to temples and exercises psychic
powers] ... ah yes, its because you're DOING SOMETHING WRONG :-)


I just admire this sort of humour!
Made me chuckling and (even) laughing.

Aug 31 '05 #12

P: n/a
On 31 Aug 2005 10:28:42 -0700, "n00m" <n0**@narod.ru> declaimed the
following in comp.lang.python:

1.
D:\>python23\python d:\python23\socket6.py [Enter]

It's OK so far. Python code is launched and starts listening
to port 1434 (see the code below; it's the same code as in my
neibouring topic).
It is not clear if this is being typed at a command prompt in a
console window (start/programs/accessories/command prompt) or the run
prompt (start/run... )

Consoles opened via start/run (or double clicking on a .py) always
close when the program exits. A command shell, opened all by itself,
into which one has typed commands, should not close regardless of what
happens inside it.

import socket, thread
host, port = '127.0.0.1', 1434
s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s2.connect((host, 1433))
So who are you connecting to? I may have missed it, but who is
listening on 1433?
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Sep 1 '05 #13

P: n/a

[n00m]
D:\>python23\python d:\python23\socket6.py [Enter]

It's OK so far. Python code is launched and starts listening
to port 1434 (see the code below; it's the same code as in my
neibouring topic).
Now I launch a vbs script (which will connect to port 1434).
I.e. I just double-click "my.vbs" file.
And... voila! In a moment & silently console window closes
without any error messages (or I just don't see them).
But VBS reports a network error. Tested on win2k and win98.


That sounds impossible, so I must be misunderstanding something. What
happens when you do this (forgive me if this seems patronising, but I'm
missing something about the way you're working)

1. Start a new Command Prompt via Start / Programs / Accessories / Command
Prompt (or the equivalent on your machine)

2. Type the following: d:\python23\python d:\python23\socket6.py [Enter]

3. Double-click your .vbs file in Windows Explorer.

Now what does the python Command Prompt say? By your description above,
it sounds like it disappears, but that ought to be impossible.

--
Richie Hindle
ri****@entrian.com>
Sep 1 '05 #14

P: n/a
It's soooooo pity I'm too buzy at my work today.
I'll reply a bit later. Thank you, guys!

PS Port 1433 SQL Server listens to.
PPS SQL Server is a rdbms from M$.

Sep 1 '05 #15

P: n/a
On 1 Sep 2005 06:01:18 -0700, "n00m" <n0**@narod.ru> declaimed the
following in comp.lang.python:

PS Port 1433 SQL Server listens to.
Okay... Whilst I have a copy of MSDE on this machine, I've not
configured it -- and never had to worry about the IP numbers on any
database, the dp-api adapter defaults took care of that for me.
(Actually, I've go overkill on this machine -- MSDE, MaxDB (SAP via
MySQL), MySQL, Firebird, and the everpresent JET.
PPS SQL Server is a rdbms from M$.
That, at least, I recognized (as I recall, it started life as a
licensed version of Sybase which has diverged over the years)
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Sep 1 '05 #16

P: n/a
Dennis; Richie;
That sounds impossible, so I must be misunderstanding something. YOU - BOTH - UNDERSTAND ME ABSOLUTELY RIGHT!
1.
Start a new Command Prompt via Start / Programs / Accessories / Command
Prompt (or the equivalent on your machine)
2.
Type the following: d:\python23\python d:\python23\socket6.py [Enter]
3. Double-click your .vbs file in Windows Explorer.
Now what does the python Command Prompt say?


It says... NOTHING! It just DISAPPEARS!

JUST FOR TO MAKE SURE I put in the same directory (Python's root)
testme.py file with this simplest content:

print 'ONE'
print 'TWO'
print 'THREE'

Then I run it EXACTLY the same way as I run socket6.py:

D:\>python23\python d:\python23\testme.py [Enter]
ONE
TWO
THREE

D:\>

AND OF COURSE CONSOLE WINDOW DID NOT CLOSE AFTER THAT !
BUT IT REALLY DISAPPEARS IN CASE OF socket6.py !
(but only AFTER I double-click my .vbs file in Windows Explorer)

Sep 1 '05 #17

P: n/a
On 1 Sep 2005 09:36:48 -0700, "n00m" <n0**@narod.ru> declaimed the
following in comp.lang.python:
AND OF COURSE CONSOLE WINDOW DID NOT CLOSE AFTER THAT !
BUT IT REALLY DISAPPEARS IN CASE OF socket6.py !
(but only AFTER I double-click my .vbs file in Windows Explorer)
I'd be tempted to blame the VBS script then... Almost sounds like it
not only does whatever you think it does, but then chases down every
process it was talking to, and killing them too (which means getting the
console window and killing it).

What happens if you run your odd Python program in one window, and
then run /another/ Python program in another window that pretends to be
the VBS process, connecting to the socket, and sending something of the
form needed to be relayed to the SQL Server process.
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Sep 2 '05 #18

P: n/a
On 1 Sep 2005 09:36:48 -0700, "n00m" <n0**@narod.ru> declaimed the
following in comp.lang.python:

<something completely snipped>

I'm going to go back a few messages... Looking for a
simplification...

=====> ORIGINAL CODE
import socket, thread
host, port = '127.0.0.1', 1434
s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s2.connect((host, 1433))
s1.bind((host, port))
s1.listen(1)
cn, addr = s1.accept()

def VB_SCRIPT():
while 1:
data = cn.recv(4096)
if not data: return
s2.send(data)
print 'VB_SCRIPT:' + data + '\n\n'

def SQL_SERVER():
while 1:
data = s2.recv(4096)
if not data: return
cn.send(data)
print 'SQL_SERVER:' + data + '\n\n'

thread.start_new_thread(VB_SCRIPT,())
thread.start_new_thread(SQL_SERVER,())

TWO threads, both just infinite loops of the same nature (you could
actually have done ONE def and passed different arguments in to
differentiate the two thread invocations.

However, threads aren't really needed for this simple connection
relay... The following has /not/ been run (since I don't have your
server nor VBS) but should do about the same thing (see comments for one
lack).

=======> Suggested code
import socket
import select

host = "127.0.0.1"
DBMSPort = 1433
MyPort = 1434

MySocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
DBMSSocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

DBMSSocket.connect((host, DBMSPort))

MySocket.bind((host, MyPort))
MySocket.listen(1)

Client, Addr = MySocket.accept()

while True:
# wait for either connection to have readable data
(inbound, outbound, excption) = select.select([DBMSSocket, Client],
[], [])
# handle each readable socket
# NOTE: there is no way (in this quick and dirty code) to
# detect end of connections.
# probably need to do things with the excption list --
# passing in the sockets, and closing them when they
# show up in excption -- actually, if one side closes
# there is no reason to continue processing the other
# side, so on any excption, could close both and exit
for s in inbound:
data = s.recv(4096)
if s is Client:
print "From VBS: ",
MyDBMS.send(data)
elif s is MyDBMS:
print "From DBMS: ",
Client.send(data)
else:
print "\n\n*** ERROR: select() socket is not known!\n\n"
print repr(data)
print "\n"

--
================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Sep 2 '05 #19

P: n/a

[Richie]
Now what does the python Command Prompt say?
[n00m] It says... NOTHING! It just DISAPPEARS!
That's the strangest thing I've heard all week. 8-)

OK, one more thing to try - redirect the output of Python to some files
and see whether anything useful appears in the files:

C:\> d:
D:\> cd \python23
D:\> python d:\python23\socket6.py > out.txt 2> err.txt

Does anything appear in d:\python23\out.txt or d:\python23\err.txt?

[Dennis] I'd be tempted to blame the VBS script then...


n00m, can you post the vbs?

--
Richie Hindle
ri****@entrian.com
Sep 2 '05 #20

P: n/a
LOL... seems it disappears only in Win98. In Win2k it goes like this:

C:\>d:
D:\>python23\python d:\python23\socket6.py
D:\>

C:\> d:
D:\> cd \python23
D:\> python d:\python23\socket6.py > out.txt 2> err.txt
Does anything appear in d:\python23\out.txt or d:\python23\err.txt? NOTHING APPEARED IN THEM.
n00m, can you post the vbs?


Set cn = CreateObject("ADODB.Connection")
cn.Open _
"Provider=sqloledb;Data Source=192.168.0.3,1434;" & _
"Network Library=DBMSSOCN;Initial Catalog=pubs;" & _
"User ID=qwe;Password=asdasd;"
cn.Execute "select top 1 * from authors;"
cn.Close
Set cn = Nothing

Sep 2 '05 #21

P: n/a
Dennis:
However, threads aren't really needed for this simple connection
relay... The following has /not/ been run (since I don't have your
server nor VBS) but should do about the same thing (see comments for one
lack).


To some degree you are right!
If the vbs issues only some "primitive" sql commands, like

select au_fname from authors where zip=678678678
(the authors is a table in the pubs database in SQL Server)

then it works even without threading it.
But if the vbs issues e.g. this command for sql server:

"waitfor delay '000:00:05'; raiserror ('AAA',10,1) with nowait;"

then things go messed and confused...
and the code refuses to work in only one (main) thread.
In short, see this my topic on an sql server forum:

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=48619

Btw, I have NOT yet seen any WORKING C# code for my subject.

Sep 2 '05 #22

P: n/a
Dennis Lee Bieber wrote:
I'm going to go back a few messages... Looking for a
simplification... [...] TWO threads, both just infinite loops of the same nature (you could
actually have done ONE def and passed different arguments in to
differentiate the two thread invocations.

However, threads aren't really needed for this simple connection
relay...
True, though I prefer the tread solution. You can see my exmaple
in message <Qc***************@newssvr11.news.prodigy.com>.

http://groups.google.com/group/comp....d0159eb52c1b49

The following has /not/ been run (since I don't have your
server nor VBS) but should do about the same thing (see comments for one
lack).
There's an easy trick to pseudo-test such a thing: for the
server host and port, edit in 'www.yahoo.com' and 80. Then
direct a browser to http://localhost:1434.

=======> Suggested code
I have a few further suggestions.

[...] DBMSSocket.connect((host, DBMSPort))

MySocket.bind((host, MyPort))
I'd definitely wait for the client connection to come in, before
making the server connection.

MySocket.listen(1)

Client, Addr = MySocket.accept()

while True:
# wait for either connection to have readable data
(inbound, outbound, excption) = select.select([DBMSSocket, Client], [], [])

One trick I used was to pass a timeout parameter; I used one
second. Python (at least my version on WinXP) won't honor the
keyboard interrupt while waiting at the select. The select is in
an infinite loop anyway, so it just means polling for a keyboard
interrupt every second.

# handle each readable socket
# NOTE: there is no way (in this quick and dirty code) to
# detect end of connections.
# probably need to do things with the excption list --
# passing in the sockets, and closing them when they
# show up in excption -- actually, if one side closes
# there is no reason to continue processing the other
# side, so on any excption, could close both and exit
Not really. If the remote side shuts down writing, the socket
will select as readable, and read will return the empty string.
That's the documented method to detect when the remote side is
done writing. When it happens, you should send the shutdown
across, much like you copy data across: shutdown writing on the
other socket. To terminate clean, copy all data and both
shutdowns (though the latter shutdown should happen
automatically if you just let the socket be destructed).
data = s.recv(4096)
if s is Client:
print "From VBS: ",
MyDBMS.send(data)


Use sendall() in place of send(); same for the other call to
socket.send(). It's an evil trap: under most circumstances,
send() will send all the data, but it's not guaranteed to do so.
With a size of 4096, you're probably O.K., but technically it's
a bug. (The slicker-than-needed thing to do would be to test
whether the outgoing socket is writable within the select, then
send() as much as you can, and keep selecting and sending until
all the data is out.)
--
--Bryan
Sep 2 '05 #23

P: n/a

I wrote:
I prefer the tread solution. You can see my exmaple
in message <Qc***************@newssvr11.news.prodigy.com>.

http://groups.google.com/group/comp....d0159eb52c1b49 [...]
you should send the shutdown
across, much like you copy data across: shutdown writing on the
other socket.


Which, incidentally, I had forgotten to do in my code. See
the follow-up for the fix.
--
--Bryan

Sep 2 '05 #24

P: n/a
On 2 Sep 2005 02:41:51 -0700, "n00m" <n0**@narod.ru> declaimed the
following in comp.lang.python:
But if the vbs issues e.g. this command for sql server:

"waitfor delay '000:00:05'; raiserror ('AAA',10,1) with nowait;"

then things go messed and confused...
Hope you'll forgive my comment -- but for some reason those look
like they were meant more for use within a stored procedure than direct
invocation...
and the code refuses to work in only one (main) thread.
In short, see this my topic on an sql server forum:

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=48619
Don't know if it applies, but the code I see there is not only
single-threaded, but is forcing the two sockets to operate in lock-step:

wait for VBS
send to server
wait for server
send to VBS
repeat

Something that could easily break under a few scenarios... One is if
a socket transaction isn't complete (TCP/IP does not guarantee that what
is sent as one packet is received as one packet, and vice versa). You
could get a situation where you've relayed an incomplete command to the
server, and the server doesn't send anything back until it receives the
rest of the command -- so you deadlock waiting for a server that is
still waiting for you. Another could be that those individual statements
in (each ;) could generate separate server response strings, but you've
read the first response and have gone back to waiting for the VBS,
without processing delayed response packets from the server.

My version, using select(), shouldn't have this problem. Regardless
of what any individual packet contained, if /either/ socket has more
data, it will be read and transferred. [Of course, you then have the
problem of the VBS maybe not handling fragmented responses properly]

-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Sep 2 '05 #25

P: n/a
Dennis Lee Bieber wrote:
Hope you'll forgive my comment -- but for some reason those look... Your comments are absolutely relevant.
My version, using select(), shouldn't have this problem.

Now I see what you meant ("You need no threads"). Your code works just
fine (hope over LAN too). I corrected a couple of typos in it.

Sep 2 '05 #26

P: n/a
On 2 Sep 2005 12:01:51 -0700, "n00m" <n0**@narod.ru> declaimed the
following in comp.lang.python:
Dennis Lee Bieber wrote:
My version, using select(), shouldn't have this problem.

Now I see what you meant ("You need no threads"). Your code works just
fine (hope over LAN too). I corrected a couple of typos in it.


As mentioned, since I didn't have the VBS or server, I only coded
from the help system -- I could not test run my code. And, as mentioned,
I did not include logic to handle a clean shut-down.
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Sep 3 '05 #27

P: n/a
On Fri, 02 Sep 2005 16:09:05 GMT, Bryan Olson <fa*********@nowhere.org>
declaimed the following in comp.lang.python:


I have a few further suggestions.
I have very little actual experience in socket programming... Just
enough to know some of the pitfalls (fragmented packets, for example;
select on windows only works for sockets while UNIX/Linux can mix
sockets and files)...
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Sep 3 '05 #28

P: n/a
> Code run from IDLE but not via double-clicking on its *.py

It still does not work. Weird.

Sep 7 '05 #29

This discussion thread is closed

Replies have been disabled for this discussion.