C
Csaba Gabor
Here is some Thanksgiving weirdness. Maybe someone has some comments:
If you schedule a task in a simple way with AT (e.g. AT 16:42 cmd "/K
dir"), after it runs, it will delete itself. Now it might be the case
that I want to schedule a task (with AT) and have it run right away.
I could schedule the task for the next minute (e.g. it is 10:03:23 so
I would schedule the task for 10:04. AT and SchTasks granularity is
to the minute, at least on Win XP). But suppose that I am an
impatient type of individual, begrudging those wasted seconds.
In that case, I would do the following:
AT 16:42 cmd "/C" dir => I get back a task id, say 29. And then,
Schtasks /run /tn 29 => task runs immediately. Nifty.
Now here's the bizzaro behaviour. If the task has been scheduled for
less than about 60 seconds from now, it will be automatically deleted
after the second line! Otherwise, the task sticks around and will be
run (again) at the indicated time. If you right click on the tasks
scheduled with AT in the above fashion, it says, "Delete the task if
it is not scheduled to run again." So I would really like to
understand the exact circumstances under which this mysterious
deletion is occurring. Ie. comments are welcome.
Interesting, but not bizarro behaviour: In keeping with the
"Impatient Script" theme... What I actually wanted was for the task to
be deleted after I had forced a run on it with Schtasks. So, after
that Schtasks line, I did:
AT 29 /delete
Of course I did so programmatically with two invocations of
WScript.Shell's Run command. The task never executed! Further
investigation revealed that the first command executed just fine and
SchTasks reported success for the immediate run. Trouble is, by the
time the responsible agency actually got around to running the task,
that following AT command had deleted it. By a sufficient delay (of
half a second!) I was able to execute and then delete the task. But I
don't like arbitrary delays, so what I wound up doing was scheduling
another task to delete the first one, a fitting if not the most
elegant of ends (not elegant because the subsequent task might have to
wait up to a minute to dispatch its victim).
Gobble gobble,
Csaba Gabor from Vienna
If you schedule a task in a simple way with AT (e.g. AT 16:42 cmd "/K
dir"), after it runs, it will delete itself. Now it might be the case
that I want to schedule a task (with AT) and have it run right away.
I could schedule the task for the next minute (e.g. it is 10:03:23 so
I would schedule the task for 10:04. AT and SchTasks granularity is
to the minute, at least on Win XP). But suppose that I am an
impatient type of individual, begrudging those wasted seconds.
In that case, I would do the following:
AT 16:42 cmd "/C" dir => I get back a task id, say 29. And then,
Schtasks /run /tn 29 => task runs immediately. Nifty.
Now here's the bizzaro behaviour. If the task has been scheduled for
less than about 60 seconds from now, it will be automatically deleted
after the second line! Otherwise, the task sticks around and will be
run (again) at the indicated time. If you right click on the tasks
scheduled with AT in the above fashion, it says, "Delete the task if
it is not scheduled to run again." So I would really like to
understand the exact circumstances under which this mysterious
deletion is occurring. Ie. comments are welcome.
Interesting, but not bizarro behaviour: In keeping with the
"Impatient Script" theme... What I actually wanted was for the task to
be deleted after I had forced a run on it with Schtasks. So, after
that Schtasks line, I did:
AT 29 /delete
Of course I did so programmatically with two invocations of
WScript.Shell's Run command. The task never executed! Further
investigation revealed that the first command executed just fine and
SchTasks reported success for the immediate run. Trouble is, by the
time the responsible agency actually got around to running the task,
that following AT command had deleted it. By a sufficient delay (of
half a second!) I was able to execute and then delete the task. But I
don't like arbitrary delays, so what I wound up doing was scheduling
another task to delete the first one, a fitting if not the most
elegant of ends (not elegant because the subsequent task might have to
wait up to a minute to dispatch its victim).
Gobble gobble,
Csaba Gabor from Vienna