Stop popup cmd window

[hokiegal99]

How can I make this script run w/o seeing a cmd popup window on the
screen? The script works well, but each hour (when the task scheduler
runs it) a brief cmd window appears and then goes away. It's only on
the screen for a second or two, but it's noticable.

u = "User Name"
f = "from address"
t = "to address"

fp = os.popen("ipconfig /all", "r")
msg = MIMEText(fp.read())
fp.close()

msg["Subject"] = "%s's IPconfig Report" % u
msg["From"] = f
msg["To"] = t

h = "smtp.vt.edu"
s = smtplib.SMTP(h)
s.sendmail(f, t, msg.as_string())
s.quit()

 

[Derrick 'dman' Hudson]

How can I make this script run w/o seeing a cmd popup window on the
screen? The script works well, but each hour (when the task scheduler
runs it) a brief cmd window appears and then goes away. It's only on
the screen for a second or two, but it's noticable.

Use a better OS? <0.5 wink>

Run it with pythonw.exe instead of python.exe.

--
One OS to rule them all, one OS to find them,
One OS to bring them all and in the darkness bind them,
In the Land of Redmond, where the Shadows lie.

www: http://dman13.dyndns.org/~dman/ jabber: (e-mail address removed)

 

[hokiegal99]

Use a better OS? <0.5 wink>

Run it with pythonw.exe instead of python.exe.

How can I specify pythonw.exe over python.exe? The task scheduler has
no place for this sort of thing.

 

[Daniel Dittmar]

How can I specify pythonw.exe over python.exe? The task scheduler has
no place for this sort of thing.

Give your script a .pyw extension:
[0] d:\ >ftype | grep py
Python.CompiledFile=C:\Python23\python.exe "%1" %*
Python.File=C:\Python23\python.exe "%1" %*
Python.NoConFile=C:\Python23\pythonw.exe "%1" %*

[0] d:\ >assoc | grep Python
..py=Python.File
..pyc=Python.CompiledFile
..pyo=Python.CompiledFile
..pyw=Python.NoConFile

You can also give a full commandline to the scheduler, including the path to
pythonw.exe and the path to your script as the first argument.

Daniel

 

[Thomas Heller]

How can I specify pythonw.exe over python.exe? The task scheduler has
no place for this sort of thing.

Name the script 'myscript.pyw' instead of 'myscript.py'.

Thomas

 

[hokieghal99]

Name the script 'myscript.pyw' instead of 'myscript.py'.

Thomas

Thanks for the tip... that did it. I need to read up on the difference
between python.exe and pythonw.exe.

Thanks again!!!

 

[Derrick 'dman' Hudson]

Thanks for the tip... that did it. I need to read up on the difference
between python.exe and pythonw.exe.

The difference is a Microsoft one. The former has stdin, stdout and
is a normal program. Microsoft dictates that on Windows such programs
must have a black window appear for the life of the program. The
latter is an "MFC" (or whatever the proper term is) program with no
stdin or stdout. On MS Windows this means that you don't get a black
box appearing, and it also means that the 'print' statement and
raw_input() function are useless. The difference is the specific
functions the C runtime calls to notify Windows of which sort of app
it is during startup. On non-Windows platforms (eg UNIX) there is no
such distinction. All (UNIX) apps have stdin and stdout, though they
aren't necessarily connected to the user in any way, but could be if
run in such a context.

HTH,
-D

--
For society, it's probably a good thing that engineers value function
over appearance. For example, you wouldn't want engineers to build
nuclear power plants that only _look_ like they would keep all the
radiation inside.
(Scott Adams - The Dilbert principle)

www: http://dman13.dyndns.org/~dman/ jabber: (e-mail address removed)

 

[Fredrik Lundh]

Same program, linked in different ways. See below.

The difference is a Microsoft one. The former has stdin, stdout and
is a normal program. Microsoft dictates that on Windows such programs
must have a black window appear for the life of the program.

Programs linked for the "console" subsystem (aka "character-mode
applications") have to be connected to a console window. If they're
not, Windows creates one for them.

(I'm pretty sure this is done by the loader and not the C runtime).

The latter is an "MFC" (or whatever the proper term is)

The "windows" subsystem.

The difference is the specific functions the C runtime calls to notify
Windows of which sort of app it is during startup.

A linker option, usually (/subsystem)

A console program may use the Windows API to disconnect from the
console, or create a window, and a window program may use the API
to create a console if it needs one (a version of pythonw that did this
if/when the application prints to sys.stderr would be quite useful, btw)

</F>

 

[Dave Benjamin]

A console program may use the Windows API to disconnect from the
console, or create a window, and a window program may use the API
to create a console if it needs one (a version of pythonw that did this
if/when the application prints to sys.stderr would be quite useful, btw)

Yes! Especially if it paused afterwards, so you could actually read the
error message! Speaking of which, is there any way to keep the console
window on the screen after double-clicking on a .py file so that syntax
errors don't result in a spead-reading test?

Thanks,
Dave

 

[Thomas Heller]

Yes! Especially if it paused afterwards, so you could actually read
the error message! Speaking of which, is there any way to keep the
console window on the screen after double-clicking on a .py file so
that syntax errors don't result in a spead-reading test?

Several I can think of.

- untested, but you get the idea:

try:
main()
except:
import traceback
traceback.print_exc()
raw_input()

- set the PYTHONINSPECT env variable during runtime

- or even fire up the debugger when a problem occurs:

<http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65287>

And, by the way, py2exe 0.5 (still officially unreleased and
undocumented) created console-less programs automatically write
exceptions into a logfile.

Thomas

 

[Dave Benjamin]

Several I can think of.

- untested, but you get the idea:

try:
main()
except:
import traceback
traceback.print_exc()
raw_input()

This is the sort of thing I usually do, but it doesn't catch syntax errors.
I wind up in this state of self-conflict, unsure if I should just run the
program again, and read really fast (which rarely works, because it always
runs faster the second time) or if I should just bite the bullet and open up
a command window. Sometimes, it takes me awhile to recover.

- set the PYTHONINSPECT env variable during runtime

I didn't even know it existed. =)

- or even fire up the debugger when a problem occurs:

<http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65287>
Cool!

And, by the way, py2exe 0.5 (still officially unreleased and
undocumented) created console-less programs automatically write
exceptions into a logfile.

Can py2exe produce a custom Python interpreter? Kind of like how freewrap
did this with Tcl, where your "wrapped" program could be used as an
interpreter to run other scripts in an environment of your choice?

Thanks for the info.

 

[Peter Hansen]

Yes! Especially if it paused afterwards, so you could actually read the
error message! Speaking of which, is there any way to keep the console
window on the screen after double-clicking on a .py file so that syntax
errors don't result in a spead-reading test?

I don't remember exactly what has worked for me, but I've been able
to accomplish that (without resorting to a terminal "raw_input()" in
my script) by modifying the properties associated with the icon for the
python.exe file. Basically, when you click on a .py, it checks what to
do in the registry. Normally it would run c:\python23\python.exe or
whatever equivalent there is. Under the properties for that executable
in Explorer there is a "Run" mode that can be Normal window, Minimized,
or Maximized, and just below that is a checkbox labelled "Close on exit".

I think you have to find the real .exe and not just a Shortcut to it,
though, so don't bother with whatever is in your Start menu.

And if it works for you, please post here so others will know what does
or doesn't work, as I'm unsure.

-Peter