How to tell Script to use pythonw.exe ?

[goldtech]

Hi,

Using Windows....

I want to run a .py file script using pythonw.exe so the DOS box will not open. Is there a way from inside the script to say "run me with pythonw.exe and not python.exe"?

Thanks

 

[goldtech]

I just changed the file extension of the script file from .py to .pyw and it uses pythonw.exe. I didn't read it anywhere, just intuited it and tried it. Python has some very smart people working the language...

 

[Steven D'Aprano]

Hi,

Using Windows....

I want to run a .py file script using pythonw.exe so the DOS box will
not open. Is there a way from inside the script to say "run me with
pythonw.exe and not python.exe"?

I don't believe so, because by the time the script is even opened, it is
too late. I'm not an expert about Windows, but as I understand it, the
process that occurs when you double-click the file is:

* Windows inspects the file extension and sees it is .py

* Windows checks the registry for the file extension association and
finds python.exe

* Windows calls python.exe with the path to the script as argument

* finally python.exe opens the script.


Instead, you can use .pyw as the file extension, which should do what you
want.

 

[Andrew Berg]

Using Windows....

I want to run a .py file script using pythonw.exe so the DOS box will not open. Is there a way from inside the script to say "run me with pythonw.exe and not python.exe"?

Use the .pyw extension instead of .py.
Also, just FYI, DOS is long dead, and is much, much different under the hood from the console subsystem in modern versions of Windows.

 

[Tim Golden]

DOS is long
dead, and is much, much different under the hood from the console
subsystem in modern versions of Windows.

While this is clearly true, it's by no means unusual for people to refer
to the "DOS Box" or talk about "DOS commands" etc. even when they're
quite well aware of the history of Windows and its Console subsystem.
It's just quicker than saying "Console Window" or something.

I mention this because it seems to get called out every time someone
uses the term "DOS" on this and other Python lists and it can smack
slightly of pedantry.

TJG

 

[Chris Angelico]

While this is clearly true, it's by no means unusual for people to refer
to the "DOS Box" or talk about "DOS commands" etc. even when they're
quite well aware of the history of Windows and its Console subsystem.
It's just quicker than saying "Console Window" or something.

I mention this because it seems to get called out every time someone
uses the term "DOS" on this and other Python lists and it can smack
slightly of pedantry.

I would avoid the term "DOS Box" in reference to cmd.exe though,
because DOSBox is an emulator. (Also because I have an OS/2 heritage,
where a DOS Window is command.com in a virtual x86 windowed session,
while an OS/2 Window is the native OS/2 command interpreter.)

But in general usage, calling them "DOS commands" is sloppy but
unambiguous. I wouldn't be concerned one way or the other.

ChrisA

 

[Andrew Berg]

While this is clearly true, it's by no means unusual for people to refer
to the "DOS Box" or talk about "DOS commands" etc. even when they're
quite well aware of the history of Windows and its Console subsystem.
It's just quicker than saying "Console Window" or something.

I mention this because it seems to get called out every time someone
uses the term "DOS" on this and other Python lists and it can smack
slightly of pedantry.

It's not as ambiguous (or as common) as it used to be, but it has always bothered me when someone refers to the Win32 console as DOS. I try
not to be rude about it, but I really would like to prevent those who are not very familiar with Windows or its history from associating the
limits and internal behavior of MS-DOS with the console subsystem of Windows NT. Especially with the anti-Windows sentiment that seems to be
getting more popular (not that it's entirely without merit, but that's another topic for another day on another list), I'd rather see
operating systems judged on things that are actually true and not miscellaneous FUD spread by ignorance and confusion. I realize it can come
off as pedantic, but what may be obvious to those with of us with a lot of experience with different operating systems over the years can
easily slip past a novice.

BTW, there are several short and unambiguous terms one can use to refer to the Windows CLI environment (or parts thereof): cmd, command
prompt, command line, terminal, console, etc.. Also, I don't think I've ever encountered anyone who prefers to call it DOS even though they
know it's not correct, but if you say it's not unusual, then they're obviously out there, and I'll keep that in mind before jumping in to
correct them.

 

[Tim Golden]

I really would like to prevent those who are not very familiar with
Windows or its history from associating the limits and internal
behavior of MS-DOS with the console subsystem of Windows NT.
Especially with the anti-Windows sentiment that seems to be getting
more popular (not that it's entirely without merit, but that's
another topic for another day on another list), I'd rather see
operating systems judged on things that are actually true and not
miscellaneous FUD spread by ignorance and confusion.

We can certainly agree on this. I can't count the number of emails I've
deleted as too hot-headed in response to dismissive comments about
Windows as a platform. Some of them, at least, appear to be from people
who last actually used Windows back in the 9x days when the command
window was very limited indeed.

I realize it can

come off as pedantic, but what may be obvious to those with of us
with a lot of experience with different operating systems over the
years can easily slip past a novice.

I suppose I view it in the same light as people (very few, thankfully,
in my experience) who go out of their way to correct "MB" to "MiB" when
talking about disk sizes. Or -- and I'm definitely guilty of this -- of
pointing out that London telephone numbers are all 020 plus eight digits
and *not* 0207 or 0208 plus seven digits. Whenever I do that I'm aware
that I'm technically in the right but that, for all practical purposes,
it's a needless precision.

Obviously, if it were clearly a source of confusion in some context I'd
clarify what needed to be clarified.


TJG

 

[Tim Chase]

We can certainly agree on this. I can't count the number of emails
I've deleted as too hot-headed in response to dismissive comments
about Windows as a platform. Some of them, at least, appear to be
from people who last actually used Windows back in the 9x days when
the command window was very limited indeed.

I guess one of my biggest frustrations with the cmd.exe (and
command.com) interpreters is that argument processing is left to the
application, so each application may do it slightly differently:

C:\temp\> find weather *.py
FIND: Parameter format not correct
C:\temp\> find "weather" *.py
---------- WFD.PY
weather = Weather(lat, lon)
C:\temp\> findstr weather *.py
wfd.py: weather = Weather(lat, lon)
C:\temp\> findstr "weather" *.py
wfd.py: weather = Weather(lat, lon)

And more maddeningly:

C:\temp\> start file.txt
... opens the file correctly in Notepad
C:\temp\> start "file with space.txt"
... opens a new dos box with the name "file with space.txt" rather
than opening the file
C:\temp\> start "" "file with space.txt"
... opens the file correctly in Notepad

It's the little inconsistencies like this that wear daily on me. That
and the lack of built-in utilities, so I'm regularly adding GNU tools
on new boxes.

-tkc

 

[Tim Golden]

I guess one of my biggest frustrations with the cmd.exe (and
command.com) interpreters is that argument processing is left to the
application, so each application may do it slightly differently:

Goodness, I doubt if you'll find anyone who can seriously make a case
that the Windows command prompt is all it might be. I'm not a Powershell
user myself but people speak highly of it. Or, as you say, you can use
the GNU tools either natively or via cygwin. Not my cup of tea, but
that's the way of tools: one man's meat...

More to the point, I've got no problem with informed criticism (although
there's little point in grumbling just for the sake of it). The problem
I have is with criticisms which are years out of date, or which appear
to be fuelled by prejudice more than by experience.

TJG

 

[Steven D'Aprano]

Goodness, I doubt if you'll find anyone who can seriously make a case
that the Windows command prompt is all it might be. I'm not a Powershell
user myself but people speak highly of it.

I understand that Powershell is aimed more for batch use rather than
interactive use.

 

[Chris Angelico]

I guess one of my biggest frustrations with the cmd.exe (and
command.com) interpreters is that argument processing is left to the
application, so each application may do it slightly differently:

C:\temp\> find weather *.py
FIND: Parameter format not correct
C:\temp\> find "weather" *.py
---------- WFD.PY
weather = Weather(lat, lon)
C:\temp\> findstr weather *.py
wfd.py: weather = Weather(lat, lon)
C:\temp\> findstr "weather" *.py
wfd.py: weather = Weather(lat, lon)

And more maddeningly:

C:\temp\> start file.txt
... opens the file correctly in Notepad
C:\temp\> start "file with space.txt"
... opens a new dos box with the name "file with space.txt" rather
than opening the file
C:\temp\> start "" "file with space.txt"
... opens the file correctly in Notepad

It's the little inconsistencies like this that wear daily on me. That
and the lack of built-in utilities, so I'm regularly adding GNU tools
on new boxes.

The issue you have there is mainly that the quotes are serving double
purpose. Yes, they delimit and thus can be used to surround a file
name with spaces in it, but they're also significant to a couple of
apps (FIND uses them to indicate the search string, START looks for a
quoted argument to use as the title). I'm not entirely sure how it's
done under the covers; C code looking at argc/argv sees quoted
arguments without their quotes, exactly as I would expect on Unix, and
yet the convention is to notice the quotes.

The issue with START is 100% understandable and 100% annoying.

ChrisA

 

[Îίκος]

Στις 3/7/2013 6:43 πμ, ο/η Tim Roberts έγÏαψε:

While your statement is true, that's not what happened here.

Windows has long had the ability to associate a file extension with a
handler. If you start a command shell, the "assoc" command tells you the
program type associated with an extension, and the "ftype" command tells
you the command line that will be executed for that program type. On my
box:

C:\tmp>assoc .py
.py=Python

C:\tmp>ftype Python
Python="C:\Apps\Python27\Python.exe" "%1" %*

C:\tmp>assoc .pyw
.pyw=Python.NoConFile

C:\tmp>ftype Python.NoConFile
Python.NoConFile="C:\Apps\Python27\Pythonw.exe" "%1" %*

You can create your own, if you want. If you want files with a .script
extension to run PythonW, you can type:

assoc .script=Python.NoConFile

My associations are broken, bt i only care for open web pages with
Chrome instead of IE, so i sued your method:


C:\Windows\system32>assoc .html=Chrome
..html=Chrome

C:\Windows\system32>ftype
Chrome="C:\Users\Ferrous\AppData\Local\Google\Chrome\Application\chrome.exe"
%1

Chrome="C:\Users\Ferrous\AppData\Local\Google\Chrome\Application\chrome.exe"
%1

but still when i click a link IE keeps popping up isntead of Chrome.
Any ideas why?

 

[Benjamin Kaplan]

Στις 3/7/2013 6:43 πμ, ο/η Tim Roberts έγÏαψε:

My associations are broken, bt i only care for open web pages with Chrome

instead of IE, so i sued your method:

C:\Windows\system32>assoc .html=Chrome
.html=Chrome

C:\Windows\system32>ftype Chrome="C:\Users\Ferrous\AppData\Local\Google\Chrome\Application\chrome.exe"
%1
Chrome="C:\Users\Ferrous\AppData\Local\Google\Chrome\Application\chrome.exe"
%1

but still when i click a link IE keeps popping up isntead of Chrome.
Any ideas why?

Because your links don't open files. They send requests to an http server
for data. And IE is the program designated to send http requests. Just use
the browser's "make this the default" button.

 

[Îίκος]

Στις 3/7/2013 7:36 μμ, ο/η Benjamin Kaplan έγÏαψε:

Chrome instead of IE, so i sued your method:

Because your links don't open files. They send requests to an http
server for data. And IE is the program designated to send http requests.
Just use the browser's "make this the default" button.

I dont understand you. I explicitly state via cmd to have the .html
files opened with Chrome instead of IE.


Tried it with the way you said and evben with "open with.." but all that
fails.

some seriosu damaged must have happened and assoc are refusing to change.

 

[Dennis Lee Bieber]

I understand that Powershell is aimed more for batch use rather than
interactive use.

In one respect: no...

Consider that the Powershell default is to /prevent/ execution of
script files unless some security settings have been changed; even local
script files need to be "signed" to be executed.

Powershell is mainly aimed at system administration. I've spent weeks,
at work, where 90% of my day involved variations of a command like:

Get-ChildItem -Recurse -Filter "*.ad*" | Select-String -Pattern
"some-function-name"

{assignment was to trace use of some system calls up through to the user
API level to ensure that the API documented that it might block}

 

[Ian Kelly]

In one respect: no...

Consider that the Powershell default is to /prevent/ execution of
script files unless some security settings have been changed; even local
script files need to be "signed" to be executed.

IOW, it's aimed at *secure* batch use for paranoid sysadmins.

According to microsoft.com:

"""
Windows PowerShell® is a task-based command-line shell and scripting
language designed especially for system administration. Built on the
..NET Framework, Windows PowerShell® helps IT professionals and power
users control and automate the administration of the Windows operating
system and applications that run on Windows.
"""

Which would seem to indicate that it targets both interactive and
scripting uses.

 

[alex23]

I dont understand you. I explicitly state via cmd to have the .html
files opened with Chrome instead of IE.
Tried it with the way you said and evben with "open with.." but all that
fails.
some seriosu damaged must have happened and assoc are refusing to change.

This list is for discussing Python, not your concerns du jour with
various operating systems.

Please take this to comp.os.ms-windows.misc instead.

 

[Wayne Werner]

Consider that the Powershell default is to /prevent/ execution of
script files unless some security settings have been changed; even local
script files need to be "signed" to be executed.

Protip: No they don't - wrap it in a cmd/bat file and have it launch
powershell[1]:

powershell -ExecutionPolicy Bypass -File ...


\o/

Microsoft "security" at it again! (reminds me a bit of just pushing
"Cancel" to log into windows 98, I think it was)

-W

[1]: http://stackoverflow.com/q/728143/344286

 

[Andrew Berg]

powershell -ExecutionPolicy Bypass -File ...


\o/

Microsoft "security" at it again! (reminds me a bit of just pushing
"Cancel" to log into windows 98, I think it was)
From an MSDN page linked in one of the answers:
Now, why is

PowerShell.exe –ExecutionPolicy Bypass –File c:\temp\bad-script.ps1

not a security bug? Ultimately, if bad code has the ability to run this code, it already has control of the machine.

http://blogs.msdn.com/b/powershell/archive/2008/09/30/powershell-s-security-guiding-principles.aspx

If an attacker can run code, he/she already has the capability to well, run code.