PATH

[Dave Patrick]

Correct. Append is the expected behavior.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Ok. Here's what I just did:
| I edited autoexec.bat to read
|
| @echo off
| set PATH=F:\TEMP3
|
| then rebooted and ran path.
| Here's what came up:
|
|
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\utils;c:\batch;c:\Python22;C:\Program
| files\PC-Doctor for Windows XP\WINDSAPI;F:\TEMP3
|
| Do you see it now?
| Autoexec.bat didn't REPLACE the path variable,
| it appended it.

 

[Nobody Special]

Didn't you just tell me that
set PATH=
would normally result in _replacing_ the path string?
Now you're telling me that append is the expected behavior.
Do you see why I'm confused here?
It seems autoexec.bat is a special case
where the normal rules of set VAR= do not apply.

Correct. Append is the expected behavior.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Ok. Here's what I just did:
| I edited autoexec.bat to read
|
| @echo off
| set PATH=F:\TEMP3
|
| then rebooted and ran path.
| Here's what came up:
|
|
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\utils;c:\batch;c:\Python22;C:\Program
| files\PC-Doctor for Windows XP\WINDSAPI;F:\TEMP3
|
| Do you see it now?
| Autoexec.bat didn't REPLACE the path variable,
| it appended it.

 

[Dave Patrick]

Negative, I did not. Check back up in the thread to confirm.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Didn't you just tell me that
| set PATH=
| would normally result in _replacing_ the path string?
| Now you're telling me that append is the expected behavior.


| Do you see why I'm confused here?
| It seems autoexec.bat is a special case
| where the normal rules of set VAR= do not apply.

 

[Nobody Special]

Ok. Sorry about that. My mistake. All these years I've been operating under an
erroneous idea of how set works. I really appreciate you setting me straight on
that. Now I've got to go and correct all those batch files that I wrote to
temporarily append a particular directory to the path. Append is the expected
behavior. Append is the expected behavior. I think I've got it now. Thank you
very much.

Negative, I did not. Check back up in the thread to confirm.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Didn't you just tell me that
| set PATH=
| would normally result in _replacing_ the path string?
| Now you're telling me that append is the expected behavior.


| Do you see why I'm confused here?
| It seems autoexec.bat is a special case
| where the normal rules of set VAR= do not apply.

 

[Dave Patrick]

No problem. You're welcome.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Ok. Sorry about that. My mistake. All these years I've been operating
under an
| erroneous idea of how set works. I really appreciate you setting me
straight on
| that. Now I've got to go and correct all those batch files that I wrote to
| temporarily append a particular directory to the path. Append is the
expected
| behavior. Append is the expected behavior. I think I've got it now. Thank
you
| very much.

 

[Nobody Special]

Ohmagosh. I thought I understood, but the very first batch file that I modified
with "append is the expected behavior" in mind, the set path= statement
REPLACED the path variable. Arghhh! I'm going to go with what I said before,
that the autoexec.bat is a special case.
set OLDPATH=%PATH%
set PATH=C:\Program Files\WinZip;%OLDPATH%
set OLDPATH=
works.
set PATH=C:\Program Files\WinZip
doesn't. It drops all of the old path string leaving only the new path.
Maybe
set PATH=%PATH%;C:\Program Files\WinZip
would work also. I'll give it a shot.

No problem. You're welcome.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Ok. Sorry about that. My mistake. All these years I've been operating
under an
| erroneous idea of how set works. I really appreciate you setting me
straight on
| that. Now I've got to go and correct all those batch files that I wrote to
| temporarily append a particular directory to the path. Append is the
expected
| behavior. Append is the expected behavior. I think I've got it now. Thank
you
| very much.

 

[Dave Patrick]

Yes, autoexec.bat is a special case in that it is read at boot and *appends*
the system path statement. When you use set PATH= in a batch file it
temporarily *replaces*

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Ohmagosh. I thought I understood, but the very first batch file that I
modified
| with "append is the expected behavior" in mind, the set path= statement
| REPLACED the path variable. Arghhh! I'm going to go with what I said
before,
| that the autoexec.bat is a special case.
| set OLDPATH=%PATH%
| set PATH=C:\Program Files\WinZip;%OLDPATH%
| set OLDPATH=
| works.
| set PATH=C:\Program Files\WinZip
| doesn't. It drops all of the old path string leaving only the new path.
| Maybe
| set PATH=%PATH%;C:\Program Files\WinZip
| would work also. I'll give it a shot.

 

[Nobody Special]

the 'temporarily' part of that statement is wrong. After I had run that
modified batch file I ran 'path' at the command prompt and it came up with only
what that modified batch file had replaced the path string with. Now, if by
'temporarily' you mean that the original path will be restored after returning
to Windows, that's correct, but as long as one is still in command line mode,
that original path is not a part of the active path environment variable. It
remains what the last set statement made it until a new instance of cmd is run.
btw: I tried
set PATH=%PATH%;C:\Program Files\Winzip
and that works fine. The OLDPATH variable steps aren't necessary.
- - -
Yes, autoexec.bat is a special case in that it is read at boot and *appends*
the system path statement. When you use set PATH= in a batch file it
temporarily *replaces*

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Ohmagosh. I thought I understood, but the very first batch file that I
modified
| with "append is the expected behavior" in mind, the set path= statement
| REPLACED the path variable. Arghhh! I'm going to go with what I said
before,
| that the autoexec.bat is a special case.
| set OLDPATH=%PATH%
| set PATH=C:\Program Files\WinZip;%OLDPATH%
| set OLDPATH=
| works.
| set PATH=C:\Program Files\WinZip
| doesn't. It drops all of the old path string leaving only the new path.
| Maybe
| set PATH=%PATH%;C:\Program Files\WinZip
| would work also. I'll give it a shot.

 

[Dave Patrick]

Yes, by temporary I meant for the life of that cmd.exe session.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| the 'temporarily' part of that statement is wrong. After I had run that
| modified batch file I ran 'path' at the command prompt and it came up with
only
| what that modified batch file had replaced the path string with. Now, if
by
| 'temporarily' you mean that the original path will be restored after
returning
| to Windows, that's correct, but as long as one is still in command line
mode,
| that original path is not a part of the active path environment variable.
It
| remains what the last set statement made it until a new instance of cmd is
run.
| btw: I tried
| set PATH=%PATH%;C:\Program Files\Winzip
| and that works fine. The OLDPATH variable steps aren't necessary.

 

[Wesley Vogel]

The only lines in Autoexec.bat that Windows XP will read are the lines that
begin with SET or PATH. If ParseAutoexec is set to 1.

When this value is enabled the variables listed in the Autoexec.bat file
will be parsed and included in the current user environment.

HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon
Value Name: ParseAutoexec
Data Type: REG_SZ
Data: 0 or 1
0 : Ignores Autoexec.bat at logon.
1 : Parses Autoexec.bat at logon.

This has no effect on the parsing of AUTOEXEC.NT or CONFIG.NT by the MS-DOS
or 16-bit Windows environments (VDMs).

Also see this...
How do I check for duplicate path entries?
http://www.jsifaq.com/SUBJ/tip4700/rh4770.htm

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In

PS: I'd sure appreciate it if you would let me know if you ever determine
why the processing of autoexec.bat behaves in that odd manner when
launching cmd. There's got to be something a tad out of the ordinary
there. My email address is rps[at]rpseeley.com

my autoexec.bat?
@echo off
set OLDPATH=%PATH%
set PATH=%OLDPATH%;C:\utils;C:\batch
set OLDPATH=
Would the system assume that the user would _not_ take care of
preserving the initial path?
If the autoexec.bat simply contained only set PATH=C:\utils;C:\batch,
would the system add
that to the existing path, or would it replace the existing path?

 

[Nobody Special]

Yes, this was helpful. Thanks very much.
- - - - - -
The only lines in Autoexec.bat that Windows XP will read are the lines that
begin with SET or PATH. If ParseAutoexec is set to 1.

When this value is enabled the variables listed in the Autoexec.bat file
will be parsed and included in the current user environment.

HKEY_CURRENT_USER\Software\Microsoft\Windows
NT\CurrentVersion\Winlogon
Value Name: ParseAutoexec
Data Type: REG_SZ
Data: 0 or 1
0 : Ignores Autoexec.bat at logon.
1 : Parses Autoexec.bat at logon.

This has no effect on the parsing of AUTOEXEC.NT or CONFIG.NT by the MS-DOS
or 16-bit Windows environments (VDMs).

Also see this...
How do I check for duplicate path entries?
http://www.jsifaq.com/SUBJ/tip4700/rh4770.htm

 

[Star Fleet Admiral Q]

Do you have the same PATHs defined in both the "system variable named PATH"
and "user variable named PATH"? If so, then that's how you are getting
duplicates, as Windows Appends the two together. The system variable named
PATH applies to all users, of course user variable named PATH only applies
to that user when this profile is logged in.

<Right Click> My Computer
<Click> Properties <Menu Item>
<Click> Advanced <Tab>
<Click> Environment Variables <Button>
Verify both User Variables for "<profile name>" and System Variables for the
values stored in the variable named "PATH".


--

Star Fleet Admiral Q @ your Service!

http://www.google.com
Google is your "Friend"