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("ipcon fig /all", "r")
msg = MIMEText(fp.rea d())
fp.close()

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

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

[Derrick 'dman' Hudson]

On 15 Dec 2003 13:28:01 -0800, hokiegal99 wrote:

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: dm**@dman13.dyn dns.org

[hokiegal99]

> On 15 Dec 2003 13:28:01 -0800, hokiegal99 wrote:

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.

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

[Thomas Heller]

ho********@hotm ail.com (hokiegal99) writes:

On 15 Dec 2003 13:28:01 -0800, hokiegal99 wrote:

> 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.

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

[Daniel Dittmar]

hokiegal99 wrote:

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.Compiled File=C:\Python2 3\python.exe "%1" %*
Python.File=C:\ Python23\python .exe "%1" %*
Python.NoConFil e=C:\Python23\p ythonw.exe "%1" %*

[0] d:\ >assoc | grep Python
..py=Python.Fil e
..pyc=Python.Co mpiledFile
..pyo=Python.Co mpiledFile
..pyw=Python.No ConFile

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

[hokieghal99]

Thomas Heller wrote:

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]

On Tue, 16 Dec 2003 18:06:16 -0500, hokieghal99 wrote:

Thomas Heller wrote:

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.

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: dm**@dman13.dyn dns.org

[Fredrik Lundh]

Derrick 'dman' Hudson wrote:

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

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]

In article <ma************ *************** **********@pyth on.org>, Fredrik Lundh wrote:

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

--
..:[ dave benjamin (ramenboy) -:- www.ramenfest.com -:- www.3dex.com ]:.
: d r i n k i n g l i f e o u t o f t h e c o n t a i n e r :

[Thomas Heller]

Dave Benjamin <ra***@lackingt alent.com> writes:

In article <ma************ *************** **********@pyth on.org>,
Fredrik Lundh wrote:

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?

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.activestat e.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