安排cygwin的at工作

Question

I am running a bunch of simulations on several (non-equivalent) client machines. In order to ensure that each simulation is run only once, the clients connect to and schedule a task on a linux server. The linux server runs the scheduled task, which ssh 's back into the client and schedules a run of the next simulation to be run.

Since some of the clients run windows XP (running cygwin), part of the scheduling script on the client side checks if the client is running linux or cygwin and schedules the run of the simulation with the corresponding at command (cygwin's at command uses the WinXP at command , which has a different syntax).

I am able to successfully schedule on the windows client, the script that calls runs the simulation. However, I find that though the scheduled task is executed, the simulation is never run.
But if I call the simulation from the commandline (copy-paste the scheduled command), then it works just fine.

Can anyone help me figure this out?

More technical details :

The simulation is a python script, which is located in the client filesystem
If I start cmd , it starts out in H:\\> , which is why part of my script starts with c: &&
The scheduled script is a python script The correct python executable is part of the windows path as well as the $PATH variable in cygwin

My scheduled script (the relevant part):

import subprocess
import sys
import smtplib

scenario, p,h,t,c,m,run, IP = sys.argv[1:]

homedir = 'myUserName'
if IP == "137.122.88.124":
    homedir = 'myOtherUserName'

subprocess.check_call("""c: && cd \"c:\\cygwin\\home\\%(home)s\\project\\dir\\scenario%(scenario)s\\p%(popsize)sh%(height)st%(tournsize)sc%(crossprob)sm%(mutprob)s\" && python "c:\\cygwin\\home\\%(home)s\\project\\dir\\scenario%(scenario)s\\p%(popsize)sh%(height)st%(tournsize)sc%(crossprob)sm%(mutprob)s\\GP%(run)s.py" """ %{'home':homedir, 'scenario':scenario, 'popsize':p, 'height':h, 'tournsize':t, 'crossprob':c, 'mutprob':m, 'run':run}, shell=True)

For clarity, following are the commands that I call in the above subprocess.check_call separated by newlines:

c: &&
cd \"c:\\cygwin\\home\\%(home)s\\project\\dir\\scenario%(scenario)s\\p%(popsize)sh%(height)st%(tournsize)sc%(crossprob)sm%(mutprob)s\" &&
python "c:\\cygwin\\home\\%(home)s\\project\\dir\\scenario%(scenario)s\\p%(popsize)sh%(height)st%(tournsize)sc%(crossprob)sm%(mutprob)s\\GP%(run)s.py"

EDIT 1 :

To test whether the scheduled script was even being called, I added the following lines to the top of the script:

f = open("C:\\Documents and Settings\\user\\Desktop\\somesimfile.txt", 'w')
f.write('I actually ran')
f.close()

Thus, if the script was run under python, it would leave a debris file that would confirm that it has run.

After the scheduler showed that the job has executed, the debris file was missing. Thus, the script was never run.

EDIT 2 :

Thinking that the scheduler might run the command within the cygwin environment, I altered the debris filepath to /home/user/somesimfile.txt

Still, no debris file was created.

I can only conclude that even though the task is scheduled, it's not being run.
Thinking that this might be a permission issue, I checked, and all my simulation scripts hav 755 permissions.

EDIT 3 :

This also does not appear to be a limitation of my login's privileges. I am able to schedule tasks directly on cmd and get results for it, using my login. Still, I am unable to schedule this simulation (or any other python script for that matter) directly from cmd

Answer 1

The problem is that even though the path to python is in the system path, when a task is scheduled, this path does not take effect. Therefore, the path to python.exe needs to be explicitly supplied. Therefore, replacing

python "c:\\cygwin\\home\\%(home)s\\project\\dir\\scenario%(scenario)s\\p%(popsize)sh%(height)st%(tournsize)sc%(crossprob)sm%(mutprob)s\\GP%(run)s.py"

with

"c:\\python27\python.exe" "c:\\cygwin\\home\\%(home)s\\project\\dir\\scenario%(scenario)s\\p%(popsize)sh%(height)st%(tournsize)sc%(crossprob)sm%(mutprob)s\\GP%(run)s.py"

fixes the problem