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)]

Bill Stewart wrote:

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]

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]

Mark V <notv...@invalid.nul> wrote:

> 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)]

Bill Stewart wrote:

> 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]

In microsoft.public.win2000.cmdprompt.admin Bill Stewart wrote:

> Mark V <notv...@invalid.nul> wrote:
>
>> 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]

On Wed, 10 Mar 2004 23:31:02 GMT, Bill Stewart posted to
microsoft.public.win2000.cmdprompt.admin:

> 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?"

--
George Bernard Shaw was an idiot.

[Bill Stewart]

Klaatu <kla...@nospam.invalid> wrote:

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

Thanks!

Bill