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]

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.



--
Steven

[Andrew Berg]

On 2013.07.02 20:20, goldtech wrote:
> 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.

--
CPython 3.3.2 | Windows NT 6.2.9200 / FreeBSD 9.1

[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
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Tim Golden]

On 03/07/2013 02:34, Andrew Berg wrote:
> 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]

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]

On 2013.07.03 02:34, Tim Golden wrote:
> 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]

On 03/07/2013 09:28, Andrew Berg wrote:
> On 2013.07.03 02:34, Tim Golden wrote:
>> 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 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]

On 2013-07-03 09:51, Tim Golden wrote:
> 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]

On 03/07/2013 13:50, Tim Chase wrote:
> On 2013-07-03 09:51, Tim Golden wrote:
>> 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:

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]

On Wed, 03 Jul 2013 14:00:49 +0100, Tim Golden wrote:

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


--
Steven

[Jeff Schwab]

Not sure what gave that impression. PS comes with handy Unix-like
aliases by default. I used it interactively every day for years, and
recommend it over either cmd or Cygwin.

[Chris Angelico]

On Wed, Jul 3, 2013 at 10:50 PM, Tim Chase
<pytho...@tim.thechases.com> wrote:
> On 2013-07-03 09:51, Tim Golden wrote:
>> 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.

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

[Νίκος]

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?
--
What is now proved was at first only imagined!

[Benjamin Kaplan]

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.

> --
> What is now proved was at first only imagined

> --
> http://mail.python.org/mailman/listinfo/python-list

[Νίκος]

Στις 3/7/2013 7:36 μμ, ο/η Benjamin Kaplan έγραψε:
>
> On Jul 3, 2013 8:27 AM, "Νίκος" <ni...@superhost.gr

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.


--
What is now proved was at first only imagined!

[Ian Kelly]

On Wed, Jul 3, 2013 at 4:11 PM, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
> On 03 Jul 2013 13:19:26 GMT, Steven D'Aprano
> <steve+comp....@pearwood.info> declaimed the following:

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

On 4/07/2013 2:50 AM, Νίκος wrote:
> 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]

On Wed, 3 Jul 2013, Dennis Lee Bieber wrote:

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

On 2013.07.04 09:08, Wayne Werner wrote:
> 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.

[Chris Angelico]

Well, the whole point of sandboxing is to allow some code and not
other - look at web browser scripts. You can run your JavaScript code
on someone else's machine without the capability to run arbitrary
code.

What this proves is that PowerShell is not a sandboxing environment.
It has just two states: Trusted and untrusted. Untrusted code may not
run. Trusted code has full access as though the administrator typed
the commands by hand.

Unix has measures to prevent a running process from having full
control over the system, but even there, privilege escalation attacks
(usually involving some application that runs as root) have been
known. Restricting a running binary (as opposed to creating an
interpreted and very slow language) is a distinctly hard problem.

ChrisA

[cub...@optonline.net]

On Tuesday, July 2, 2013 9:20:12 PM UTC-4, goldtech wrote:
> Hi,