Task Scheduler truncates PATH variable?!

Hello,

I have a simple batch file that prints the PATH environment variable:
@echo off
echo %PATH%
pause

I noticed that when I execute this file from the run menu it displays
the PATH as expected. If, however, I execute it via the Task Scheduler
it displays the PATH variable up to some number of characters. It
seems that the variable has been truncated. How can I fix this?

 

I ran your program on my system and saw the entire path, both as a
scheuled task and from the command line. In short, I could not
reproduce your problem. Running WinXP Pro.

- Rich

 

What OS is always a good thing! <G>

If there is a truncation issue in in TS, I do not know of it.

Bear in mind the the %PATH% you see displayed will be that of the
account which is executing your batch. That could be an account
(and a different PATH content) than your own logged-on account. I
suspect this is the issue and that you should either specify the
account (for the task) or simply be aware of the account (and
variables) your are actually using at the time. This could be
*very* important since both Authority and environment may be
different.

 

Hello,

The OS is Win XP Pro SP2 with the latest automatic updates applied.
I run the batch file with the same account in both cases.
I noticed that the PATH env var is truncated in the middle of a
folder. The length of PATH is 1510 cahracters.
Any other ideas?

 

I ran your program on my system and saw the entire path, both as a

I'm running WinXP Pro, too.
I noticed that the PATH env var is truncated in the middle of a
folder. The length of PATH is 1510 cahracters.
Any other ideas?

 

None. Sorry, I use neither XP nor the Task Scheduler (W2K here).
That is certainly odd. Perhaps your very-long-PATH can and should
be shortened considerably? Not that this is an explanation of
course. Did you try echo/redirect %PATH% to a file?

 

Hello,

Same result - only the first 1024 characters are echoed.
Besides, I cannot shorten my PATH as I access my programs via the run
menu, from the command prompt and batch files. Putting the respective
paths in the PATH variable seems to suits these needs very well.

 

Perhaps the task scheduler itself has a limit. Do you know whether it's
actually truncating the path, or is it just truncating the display? You
could use this command in place of the echo in your batch file to make it
clearer:

for %%A in ("%path:;=" "%") do @echo %%~A

 

My PATH is only 776 characters, which might explain why mine isn't
getting truncated. To what length was yours truncated?

- Rich\

 

To 1024 characters. For more info, take a look at one of the other
subthreads in this thread.

 

Well, the last path in PATH that is displayed is truncated as before.

 

It sounds like the task scheduler has a built-in limit then. To work
around this, perhaps you could set the path yourseld in the batch file,
including only those folders needed for the particular task. The change
will be undone when the batch file exits.

 

Thanks for your suggestion! I'll have it in mind.

 

Perhaps the task scheduler itself has a limit. Do you know
Well, how can the TS set a limit on the length of env vars? Does it
copy the env vars when it creates the task or does it rely on the env
inheritance in child processes.
In the latter case there should be no problem with the length of PATH,
right?

 

[ ]
[ ]

Skiping everything else, how wedded are you to Windows Task
Scheduler? I don't use it at all and for several reasons.
Instead, I use nnCron Lite (free and a CKI Win32 clone of cron).
It you are insterested, I can test for any truncation with over-
long PATH values.

 

Could you do this? IF so, my PATH is 1052 charaters in length.

 

1510 characters in a PATH is (pardon me) ridiculous. I can't even
imagine how in practice that can be. There are many methods to
reduce the number of FQ directoy paths needing to be in PATH. Even
if one works from CMD a lot. For one, place all your batch or
other CLI script files in one or two directories "not too deep"
(eg c:\util C:\batch c:\scripts or similar). If an application has
need of very long or multiple paths in PATH, then start it from a
batch file instead and include the setting of those locations into
a more restricted and focus PATH variable also set inside the batch
file. It seems you may be misusing the PATH on your system
especially when you consider that every PATH search needs to
"walk" through all of them until a "hit" occurs.

Example: (not start in col 2, it wrapped)
@echo off
SETLOCAL
SET PATH=%SYSTEMROOT%\SYSTEM32;%SYSTEMROOT%;Q:\someapplication
\deepdir1\deepdir2\bin
START "" "Q:\someapplication\deepdir1\deepdir2\bin\someapp.exe"
EXIT

Line 2 is optional
A
CD /d Q:\someapplication\deepdir1\deepdir2\bin
START "" someapp.exe"
may also be suffient.

Also, Shortcuts that specify the Working Directory ("Start In") can
be used in many cases.

Not bashing you or your system and there is much I do not know, but
you should IMHO consider the points and try to shorten your PATH
even above and beyond the TaskScheduler issue.

 

Hmm, good point and I'll definitely give a good deal of thought.
Thanks a lot!

 

Fails! I mucked with it for a while. No go.

(W2k) a single variable is limited to 1024 bytes.
Since the effective PATH is constructed from several components
such as the Machine and User PATH it apparently can exceed the
limit on-the-fly. I am not sure what the mechanism is for the
truncation or exactly where it occurs, but it seems probable you
won't get around it without,
Shorten the effective path to < 1024
Break it up and store it in several variables

This one just might catch some of the sharper posters around here
and get a better and more complete explanation than I can provide.


What is the real problem that needs solving? There may be other
ways to approach it such as using REG.EXE to read the registry from
inside your scheduled batch file.

 

TS may very well copy the evironment variables when creating a task,
especially if it needs to manipulate them for some reason. If I were you,
I'd seriously work on reducing the size of the path. I though mine was
overblown when it passed 300 bytes.