Command-line does work when scheduled

[Jim]

Hi,

I want to schedule a Python program that reads the command line for
input. However, when adding an argument to the command line Python
will not pick it up when using Windows scheduled tasks.

How do I get it to work?

Thanks,
Jim

[Gabriel Genellina]

En Sat, 29 Sep 2007 17:34:34 -0300, Jim <js******@compuserve.comescribi�:

I want to schedule a Python program that reads the command line for
input. However, when adding an argument to the command line Python
will not pick it up when using Windows scheduled tasks.

How do I get it to work?

Do you write the command line when defining the task? Using double quotes
around arguments with spaces?
It works fine for me.

--
Gabriel Genellina

[Jim]

On Sep 29, 3:19 pm, "Gabriel Genellina" <[e-mail]>
wrote:

En Sat, 29 Sep 2007 17:34:34 -0300, Jim <[e-mail]?:

I want to schedule a Python program that reads the command line for
input. However, when adding an argument to the command line Python
will not pick it up when using Windows scheduled tasks.

How do I get it to work?

Do you write the command line when defining the task? Using double quotes
around arguments with spaces?
It works fine for me.

--
Gabriel Genellina

I ran the following on the Scheduled Tasks:
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py " n
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py n"
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py " "n"
None of them work.
However, no problem with running from *.bat file or directly from
shortcut on my Desktop.
Thanks,
Jim

[Gabriel Genellina]

En Sat, 29 Sep 2007 19:17:49 -0300, Jim <js******@compuserve.comescribi�:

On Sep 29, 3:19 pm, "Gabriel Genellina" <[e-mail]>
wrote:

>En Sat, 29 Sep 2007 17:34:34 -0300, Jim <[e-mail]>
escribi?:

I want to schedule a Python program that reads the command line for
input. However, when adding an argument to the command line Python
will not pick it up when using Windows scheduled tasks.

How do I get it to work?

Do you write the command line when defining the task? Using double
quotes
around arguments with spaces?
It works fine for me.

I ran the following on the Scheduled Tasks:
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py " n
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py n"
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py " "n"
None of them work.
However, no problem with running from *.bat file or directly from
shortcut on my Desktop.

Try prepending the Python executable:

C:\Python25\Python.exe "J:\Jim
Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py " n

If it works this way, maybe the .py file extension is not correctly
registered.

--
Gabriel Genellina

[Jim]

On Sep 29, 6:56 pm, "Gabriel Genellina" <[e-mail]>
wrote:

En Sat, 29 Sep 2007 19:17:49 -0300, Jim <[e-mail]?:

On Sep 29, 3:19 pm, "Gabriel Genellina" <[e-mail]>
wrote:

En Sat, 29 Sep 2007 17:34:34 -0300, Jim <[e-mail]>
escribi?:

I want to schedule a Python program that reads the command line for
input. However, when adding an argument to the command line Python
will not pick it up when using Windows scheduled tasks.

How do I get it to work?

Do you write the command line when defining the task? Using double
quotes
around arguments with spaces?
It works fine for me.

I ran the following on the Scheduled Tasks:
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py " n
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py n"
"J:\Jim Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py " "n"
None of them work.
However, no problem with running from *.bat file or directly from
shortcut on my Desktop.

Try prepending the Python executable:

C:\Python25\Python.exe "J:\Jim
Crerar\MyPython\Zero_OE_Counter\Zero_OE_Counter.py " n

If it works this way, maybe the .py file extension is not correctly
registered.

--
Gabriel Genellina- Hide quoted text -

- Show quoted text -

Yes, it works this way.
How do I register the .py extension correctly?

Thanks,
Jim

[Gabriel Genellina]

En Sat, 29 Sep 2007 22:04:06 -0300, Jim <js******@compuserve.comescribi�:

>If it works this way, maybe the .py file extension is not correctly
registered.

Yes, it works this way.
How do I register the .py extension correctly?

From a command line, type:
assoc .py
You should get:
..py=Python.File
If you get an error, or another thing like py_auto_file:
assoc .py=Python.File

Then:
ftype Python.File
You should get:
Python.File=c:\path\to\python.exe "%1" %*
If you don't:
ftype Python.File=c:\path\to\python.exe "%1" %*

The %* at the end is important: if you created the association by using
"Open with...", or selecting Python from the list of installed programs,
very likely the command says only "%1" - that is, the script being open,
but without any additional arguments.

Better if you have administrative rights to do this tasks.

--
Gabriel Genellina

[Jim]

On Sep 29, 8:45 pm, "Gabriel Genellina" <[e-mail]>
wrote:

En Sat, 29 Sep 2007 22:04:06 -0300, Jim <[e-mail]?:

If it works this way, maybe the .py file extension is not correctly
registered.

Yes, it works this way.
How do I register the .py extension correctly?

From a command line, type:
assoc .py
You should get:
.py=Python.File
If you get an error, or another thing like py_auto_file:
assoc .py=Python.File

Then:
ftype Python.File
You should get:
Python.File=c:\path\to\python.exe "%1" %*
If you don't:
ftype Python.File=c:\path\to\python.exe "%1" %*

The %* at the end is important: if you created the association by using
"Open with...", or selecting Python from the list of installed programs,
very likely the command says only "%1" - that is, the script being open,
but without any additional arguments.

Better if you have administrative rights to do this tasks.

--
Gabriel Genellina

I believe I get the correct results as follows:
==============================================
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

J:\Jim Crerar\mypython\misc>assoc .py
..py=Python.File

J:\Jim Crerar\mypython\misc>ftype Python.File
Python.File="E:\Python25\python.exe" "%1" %*

J:\Jim Crerar\mypython\misc>
===============================================
What else could be wrong?
Thanks,
Jim

[Jim]

On Sep 30, 6:16 pm, Dennis Lee Bieber <[e-mail]:

On Sun, 30 Sep 2007 07:42:56 -0700, Jim <[e-mail]>
declaimed the following in comp.lang.python:

What else could be wrong?
Thanks,

Possibly those associations are only defined for your login account,
and not active for the "account" that the task scheduler is running
under?
--
Wulfraed Dennis Lee Bieber KD6MOG
[e-mail] [e-mail]
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: [e-mail])
HTTP://www.bestiaria.com/

As far as know, since I'm the major user of my PC it runs under my
account (computer administrator). It even asked for the password for
my account when I added this scheduled task.
Any further ideas?
Thanks,
Jim

[Gabriel Genellina]

En Sun, 30 Sep 2007 11:42:56 -0300, Jim <js******@compuserve.comescribi�:

On Sep 29, 8:45 pm, "Gabriel Genellina" <[e-mail]>
wrote:

>The %* at the end is important: if you created the association by using
"Open with...", or selecting Python from the list of installed programs,
very likely the command says only "%1" - that is, the script being open,
but without any additional arguments.

I believe I get the correct results as follows:
==============================================
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

J:\Jim Crerar\mypython\misc>assoc .py
.py=Python.File

J:\Jim Crerar\mypython\misc>ftype Python.File
Python.File="E:\Python25\python.exe" "%1" %*

J:\Jim Crerar\mypython\misc>
===============================================
What else could be wrong?

No more ideas... I think the scheduler just executes the command line, and
if it works in a console, should work in the scheduler too... Unless you
execute the job under another user, who has a different association for
..py files, that's the only reason I can think of.

--
Gabriel Genellina

[Jim]

On Sep 30, 6:37 pm, "Gabriel Genellina" <[e-mail]>
wrote:

En Sun, 30 Sep 2007 11:42:56 -0300, Jim <[e-mail]?:

On Sep 29, 8:45 pm, "Gabriel Genellina" <[e-mail]>
wrote:

The %* at the end is important: if you created the association by using
"Open with...", or selecting Python from the list of installed programs,
very likely the command says only "%1" - that is, the script being open,
but without any additional arguments.

I believe I get the correct results as follows:
==============================================
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

J:\Jim Crerar\mypython\misc>assoc .py
.py=Python.File

J:\Jim Crerar\mypython\misc>ftype Python.File
Python.File="E:\Python25\python.exe" "%1" %*

J:\Jim Crerar\mypython\misc>
===============================================
What else could be wrong?

No more ideas... I think the scheduler just executes the command line, and
if it works in a console, should work in the scheduler too... Unless you
execute the job under another user, who has a different association for
.py files, that's the only reason I can think of.

--
Gabriel Genellina- Hide quoted text -

- Show quoted text -

Just logged into the only other account (my Wife's -- uses only for
hotmail access) and it will not run this scheduled Python program.
Thank you for your help.
Jim

[Jay Loden]

I sometimes see issues like this at work because certain processes, including scheduled tasks if I remember right, can run as Local System user instead of as your user account. That tends to be a real pain for Python or Perl scripts because that means that they don't have the associations configured properly. You can play around a bit as Local System to find out, using an old trick:

open a command prompt and type the following:

at nn:nn /interactive cmd

where nn:nn is one minute from the current time (24 hour clock, so 11:30 pm would be 24:30). This will launch a cmd prompt on your desktop, but running as Local System instead of as yourself. From there you can see what your script does when you run it as the System user, and see what assoc .py says etc.

If you still can't figure it out, the only other things I can think of would be to wrap it in a .bat file and try using that for your scheduled task, or using py2exe to compile your script to an exe which should eliminate the whole file association/PATH issue altogether ;)

Hope that helps,

-Jay

Gabriel Genellina wrote:

No more ideas... I think the scheduler just executes the command line, and
if it works in a console, should work in the scheduler too... Unless you
execute the job under another user, who has a different association for
.py files, that's the only reason I can think of.

[Martin P. Hellwig]

Jim wrote:

On Sep 30, 6:16 pm, Dennis Lee Bieber <[e-mail]:

>On Sun, 30 Sep 2007 07:42:56 -0700, Jim <[e-mail]>
declaimed the following in comp.lang.python:

>>What else could be wrong?
Thanks,

Possibly those associations are only defined for your login account,
and not active for the "account" that the task scheduler is running
under?
--
Wulfraed Dennis Lee Bieber KD6MOG
[e-mail] [e-mail]
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: [e-mail])
HTTP://www.bestiaria.com/

As far as know, since I'm the major user of my PC it runs under my
account (computer administrator). It even asked for the password for
my account when I added this scheduled task.
Any further ideas?
Thanks,
Jim

It could be the scheduler might execute the job as the local system
account (which isn't that by default and I doubt that this is the
problem). If your configuration are not globally they won't be picked up
by that account. Meaning you should set the environment variables not on
user level but system level.

However I have observed some weird issues with scheduler too in the
past, especially when the job is executed while the job owner is not
logged on, apparently the full users profile is not available then.
But that behavior seems to differ on the various windows incarnations
and the color of the moon.

I solved my problem by running the scheduling program not in scheduler
but in cron, but I doubt that is applicable for you :-)

This post doesn't really help much but perhaps it gives some insights on
the problem.

--
mph