New: FIXPATH for Path problems

[Bill Stewart]

All,

I have updated my CMD prompt FAQ a bit:

http://home.comcast.net/~stewartb/cmdprompt.html

I had some errors in #6 (Why don't my commands work?).

Also, I have added a FIXPATH utility that attempts to automatically correct
a broken Path on Windows 2000 or later machines. FPC source, along with
some documentation, is included.

Maybe this will make fixing the Path a bit quicker and easier for those
nervous about editing the registry.

Regards,

Bill

 

[Torgeir Bakken (MVP)]

I have updated my CMD prompt FAQ a bit:

http://home.comcast.net/~stewartb/cmdprompt.html

I had some errors in #6 (Why don't my commands work?).

Also, I have added a FIXPATH utility that attempts to automatically correct
a broken Path on Windows 2000 or later machines. FPC source, along with
some documentation, is included.

Maybe this will make fixing the Path a bit quicker and easier for those
nervous about editing the registry.

Great addition


--
torgeir
Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of the 1328 page
Scripting Guide:
http://www.microsoft.com/technet/community/scriptcenter/default.mspx

 

[Mark V]

All,

I have updated my CMD prompt FAQ a bit:

http://home.comcast.net/~stewartb/cmdprompt.html

I had some errors in #6 (Why don't my commands work?).

Also, I have added a FIXPATH utility that attempts to
automatically correct a broken Path on Windows 2000 or later
machines. FPC source, along with some documentation, is included.

Maybe this will make fixing the Path a bit quicker and easier for
those nervous about editing the registry.

It's a great idea Bill. And the fixpath utility would be a boon to
those that cannot easily deal with the issue manually.

We assume that only those that are having such an issue would use it,
in which case it could get them back to an operational state.

I question only the "Error" of not-first-on-path and the subsequent
simple insertion of standard strings. Why? Because in some cases the
required elements may in fact be present, but not "first".

Example 1:
existing:
d:\foo;%SYSTEMROOT%\SYSTEM32;%SYSTEMROOT%;%SYSTEMROOT%\SYSTEM32\WBEM;C:\UTIL
post fixpath:
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\Wbem;d:\foo;%SYSTEMROOT%\SYSTEM32;%SYSTEMROOT%;%SYSTEMROOT%\SYSTEM32\WBEM;C:\UTIL

Or the required elements are present and correct, but not contiguous.

Example 2:
existing:
%SYSTEMROOT%\SYSTEM32;d:\foo;%SYSTEMROOT%;d:\bar;%SYSTEMROOT%\SYSTEM32\WBEM;C:\UTIL
post fixpath:
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\Wbem;%SYSTEMROOT%\SYSTEM32;d:\foo;%SYSTEMROOT%;d:\bar;%SYSTEMROOT%\SYSTEM32\WBEM;C:\UTIL

The "fixed" path may inadvertently slow path search or even exceed a
usable length.

I would suggest more detection of the standard elements. By element,
and not as it seems by a string of three elements as a unit. Perhaps
locating some that are present and correct and moving them to the front.

I have seen systems where the Type is correct and the "standard elements"
are present, but not "first" that typically function okay. They would not
need to run fixpath though I guess if they did so we would see as above.

Of course my ideas assume someone might run fixpath when it is not really
needed in the first place. As may well be probable with the intended
audience.

My 2 cents worth and up to you to consider if anything above has merit
enough to justify the extra work in light of the fixpath utility's
intended purpose.


In any case, I like the concept!

 

[Bill Stewart]

I question only the "Error" of not-first-on-path and the subsequent
simple insertion of standard strings. Why? Because in some cases the
required elements may in fact be present, but not "first".

[...]

Of course my ideas assume someone might run fixpath when it is not really
needed in the first place. As may well be probable with the intended
audience.

My 2 cents worth and up to you to consider if anything above has merit
enough to justify the extra work in light of the fixpath utility's
intended purpose.

Hi Mark,

I like your idea of detecting the path elements as separate pieces, rather
than as a single contiguous unit. I might get talked into doing this if you
or others see a lot of cases where it is necessary.

However, I do think that those three standard paths really should be at the
front for the most part. I would think that users who have reasons for
putting something before those 3 standard parts would be comfortable with
editing the path themselves and making the changes.

You're right, though, that the intended audience for the program is someone
with a broken path and just needs it fixed, without the danger of directly
editing the registry.

Thanks for the input!

Bill

 

[Torgeir Bakken (MVP)]

Hi Mark,

I like your idea of detecting the path elements as separate pieces, rather
than as a single contiguous unit. I might get talked into doing this if you
or others see a lot of cases where it is necessary.

Hi

I have created a vbscript program (posted below) I use to check if
the path is basically ok, (type REG_EXPAND_SZ + checking for the
3 standard path elements as separate pieces).

It also sets the process environment correctly if an "error" was
detected, so the rest of the script will run with a correct path
(the script is part of a much bigger script that "wraps" software
installations).


'--------------------8<----------------------
Option Explicit
Dim oShell, oWshProcessEnv

Set oShell = CreateObject("WScript.Shell")
Set oWshProcessEnv = oShell.Environment("Process")

' Check if system path is of type REG_EXPAND_SZ
CheckSystemPathRegType

' Checking if correct path to system folders are in place,
' and if not, add them
CheckSystemPathEntry("%SystemRoot%\System32\Wbem")
CheckSystemPathEntry("%SystemRoot%\System32")
CheckSystemPathEntry("%SystemRoot%")


Sub CheckSystemPathRegType
Dim sProcessPath, sRegPath

sProcessPath = oWshProcessEnv("PATH")

If InStr(sProcessPath, "%") > 0 Then
' system path is most likely of type REG_SZ, needs to be REG_EXPAND_SZ
On Error Resume Next
sRegPath = ""
sRegPath = oShell.RegRead _
("HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path")
If sRegPath <> "" Then
oShell.RegWrite _
"HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path", _
sRegPath, "REG_EXPAND_SZ"
End If
On Error Goto 0
oWshProcessEnv("PATH") = oShell.ExpandEnvironmentStrings _
(oShell.ExpandEnvironmentStrings("%PATH%"))
End If
End Sub


Sub CheckSystemPathEntry(ByVal sSubPath)
Dim sRegPath, sSubPathExpanded, sExpRegPath, sExpEnvPath

sSubPathExpanded = LCase(oShell.ExpandEnvironmentStrings(sSubPath))
On Error Resume Next
sRegPath = ""
sRegPath = oShell.RegRead _
("HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path")
sExpRegPath = LCase(oShell.ExpandEnvironmentStrings(sRegPath))
On Error Goto 0

If Right(sExpRegPath, Len(sSubPathExpanded)) = sSubPathExpanded Then
Exit Sub ' ---->
End if

If InStr(sExpRegPath, sSubPathExpanded & ";") = 0 Then
On Error Resume Next
sRegPath = sSubPath & ";" & sRegPath
oShell.RegWrite _
"HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path", _
sRegPath, "REG_EXPAND_SZ"
On Error Goto 0
End If

sExpEnvPath = LCase(oShell.ExpandEnvironmentStrings("%PATH%"))

If InStr(sExpEnvPath, sSubPathExpanded & ";") = 0 Then
On Error Resume Next
sRegPath = sSubPath & ";" & sRegPath
oWshProcessEnv("PATH") = sSubPathExpanded & ";" & sExpEnvPath
On Error Goto 0
End If
End Sub
'--------------------8<----------------------

 

[Mark V]

I question only the "Error" of not-first-on-path and the
subsequent simple insertion of standard strings. Why? Because
in some cases the required elements may in fact be present, but
not "first".

[...]

Of course my ideas assume someone might run fixpath when it is
not really needed in the first place. As may well be probable
with the intended audience.

My 2 cents worth and up to you to consider if anything above has
merit enough to justify the extra work in light of the fixpath
utility's intended purpose.

Hi Mark,

I like your idea of detecting the path elements as separate
pieces, rather than as a single contiguous unit. I might get
talked into doing this if you or others see a lot of cases where
it is necessary.

However, I do think that those three standard paths really should
be at the front for the most part. I would think that users who
have reasons for putting something before those 3 standard parts
would be comfortable with editing the path themselves and making
the changes.

Agreed. However, sometimes application installers insert their path
element at the "front". These may be the same ones that screw up the
Type. The very ones that should maybe even be using HKCU.


Nice tool in any case and I'm certain it will be useful. Thanks.

 

[Klaatu]

I have updated my CMD prompt FAQ a bit:

http://home.comcast.net/~stewartb/cmdprompt.html

Typo?

"7. Why can't I can't do things when there are spaces in a file or
directory name?"

 

[Bill Stewart]

Typo?

"7. Why can't I can't do things when there are spaces in a file or
directory name?"

Thanks!

Bill