'ruby' is not recognized as an internal or external command, etc.--but 'ruby.exe' IS

[Roy Pardee]

Hey All,

This is strange.  New 64-bit win7 install.  No other rubys on it.  I d/l & install the rc1 exe (as a non-admin) and checked the two boxes for adding ruby to the path & whatever the other thing was.  Dig this session:

    C:\Users\roy>ruby -v
    'ruby' is not recognized as an internal or external command,
    operable program or batch file.
   
    C:\Users\roy>ruby.exe -v
    ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-mingw32]

So... I've got to add the '.exe' in order for it to be recognized? 

My path is

  PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\e\cmd;C:\Ruby19\bin

Can anybody think of a reason why I can't just invoke the interpreter as 'ruby' w/out the extension?

Many thanks!

-Roy

--
Roy Pardee
http://facebook.com/rpardee

[Luis Lavena]

please also check PATHEXT:

C:\Users\Luis>set PATHEXT
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

That is the functionality that allows calling programs without extensions.

--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[Roy Pardee]

Thanks Luis!  Exactly right.  But there's still some weirdness.

If I say "set pathext" in a command window I get back just:

  PATHEXT=.RB;.RBW

But if I look in the env var dialog ('advanced' tab on computer properties), the only PATHEXT var set is at the system level & the value is:

  .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

If I manually set pathext to all that in my command window, I can call ruby w/out the .exe, but the next command window has of course forgotten the extra goo & sets me back to just .RB;.RBW.

If I use the dialog to create a user-level PATHEXT var & set it to the whole long thing it seems to have no effect--I still only get .rb;.rbw.

Any further thoughts?

Many thanks!

[Jon]

> Any further thoughts?
>

Did you try all of this in a newly created CMD.EXE shell opened post-install or did you try it from a CMD.EXE shell that was already open before installing?

Jon

[Roy Pardee]

It's all post-install.

[Jon]

> It's all post-install.

Odd. I haven't upgraded to 7 yet but I'll look at it on my 32-bit Vista as I don't yet see how it's related to 7 or 64-bit.

I've got a sneaking suspicion I'll have add manual env refresh code again. I'll create an updated FakeInstaller for you to test on your system and look at PATH, PATHEXT, and the env var dialog of system properties.

Jon

[Roy Pardee]

Okey doke--thanks.

[Jon]

> > It's all post-install.
>
> Odd. I haven't upgraded to 7 yet but I'll look at it on my 32-bit Vista as I don't yet see how it's related to 7 or 64-bit.
>
> I've got a sneaking suspicion I'll have add manual env refresh code again. I'll create an updated FakeInstaller for you to test on your system and look at PATH, PATHEXT, and the env var dialog of system properties.

Let's see if we can replicate the issue on your system using the FakeInstaller from here -> http://www.mediafire.com/?ryzzmtmdymn

Note that the FakeInstaller doesn't actually setup a working Ruby environment (so you can't actually run "ruby blah.rb"), but it does install a few files to a dir (C:\FakeRuby19 by default) and updates the registry for PATH and PATHEXT (if selected) like the normal installer. It's a quick way for us to develop and test just the installer.

Try the following:

1) Run installer checking both boxes for modifying your path and associated .rb/.rbw files

2) After installation finishes, open up a new command prompt and type the following 2 commands:

echo %PATH%
echo %PATHEXT%

3) open up the env var dialog of your system properties and see what the values for PATH and PATHEXT are

4) If you're comfortable running "regedit" do so and see what the values are for PATH and PATHEXT depending upon whether you ran the installer from an administrator account or a standard user:

Admin -> HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
Standard -> HKCU\Environment

5) Uninstall the fake installer

6) Open up a completely new command prompt and repeat steps (2) - (4)


If this all correlates with the issue you've reported, I'll roll another FakeInstaller with (hopefully) a fix to your issue for further testing.

Jon

[Roy Pardee]

On Mon, Dec 7, 2009 at 9:31 AM, Jon <jon.f...@gmail.com> wrote:

> > It's all post-install.
>
> Odd. I haven't upgraded to 7 yet but I'll look at it on my 32-bit Vista as I don't yet see how it's related to 7 or 64-bit.
>
> I've got a sneaking suspicion I'll have add manual env refresh code again.  I'll create an updated FakeInstaller for you to test on your system and look at PATH, PATHEXT, and the env var dialog of system properties.

Let's see if we can replicate the issue on your system using the FakeInstaller from here -> http://www.mediafire.com/?ryzzmtmdymn

Drat--download is not working.  Can you put it up someplace else?

BTW, in case it's useful--doing an uninstall of the rc restored my PATHEXT var.

Thanks!

-Roy

[Luis Lavena]

Weird. RC1 generated that? We are talking about RubyInstaller and not
One-Click version, correct?

Please try one of the installers highlighted in pink:

http://rubyforge.org/frs/?group_id=167&release_id=41267

During installation check the PATH modification and file association changes.

Once you installed it, open a new command prompt and try execute "ruby
--version" again.

[Luis Lavena]

On Tue, Dec 8, 2009 at 10:44 AM, Luis Lavena <luisl...@gmail.com> wrote:
>>
>
> Weird. RC1 generated that? We are talking about RubyInstaller and not
> One-Click version, correct?
>
> Please try one of the installers highlighted in pink:
>
> http://rubyforge.org/frs/?group_id=167&release_id=41267
>
> During installation check the PATH modification and file association changes.
>
> Once you installed it, open a new command prompt and try execute "ruby
> --version" again.
>

Also, something weird I just noticed is that e binaries are before Ruby one.

I think "E" was shipping with cygwin or cygwin ruby, but maybe I'm wrong.

[Jon]

> Drat--download is not working. Can you put it up someplace else?
>
> BTW, in case it's useful--doing an uninstall of the rc restored my PATHEXT
> var.
>
> Thanks!
>
> -Roy

Strangeness...

Try this http://bit.ly/592goV

If you get the nasty looking warning page from bit.ly, click the link at the very bottom of the page with the intro words "Or you can continue to..."

And as Luis replied, please do a double check on the RC1 from the link he gave you or one from http://rubyinstaller.org/download.html as they should be the same.

Thanks, Jon

[Roy Pardee]

Thanks guys--that link worked.  I'm off to work now, but will apply your suggestions when I get home tonight & let you know the effects.

Thanks!

[Roy Pardee]

On Tue, Dec 8, 2009 at 5:45 AM, Luis Lavena <luisl...@gmail.com> wrote:

On Tue, Dec 8, 2009 at 10:44 AM, Luis Lavena <luisl...@gmail.com> wrote:
>>
>
> Weird. RC1 generated that? We are talking about RubyInstaller and not
> One-Click version, correct?

Yep, that's right.
 

>
> Please try one of the installers highlighted in pink:
>
> http://rubyforge.org/frs/?group_id=167&release_id=41267
>
> During installation check the PATH modification and file association changes.
>
> Once you installed it, open a new command prompt and try execute "ruby
> --version" again.

I'll give that a shot when I get home.
 

Also, something weird I just noticed is that e binaries are before Ruby one.

I think "E" was shipping with cygwin or cygwin ruby, but maybe I'm wrong.

No, you're right--I'll try removing that from my path & see what happens.

Thanks!

- Roy

[Jon]

> Thanks guys--that link worked.  I'm off to work now, but will apply your
> suggestions when I get home tonight & let you know the effects.
>
> Thanks!

After the install is complete, how exactly are you opening up the
command prompt in which you type "ruby -v"? There's a peculiarity in
Windows regarding how newly opened processes like command prompt
receive updated environment vars.

A screencast (e.g. - http://screenr.com/ or http://screencast.com/ )
showing from where the new command prompt is opened and it's behavior
would be great.

Jon

[Roy Pardee]

I'll try and get that together.  In the meantime, I can tell you I pop the run dialog by typing win-r and then type 'cmd' and hit enter.

[Jon]

> I'll try and get that together. In the meantime, I can tell you I pop the
> run dialog by typing win-r and then type 'cmd' and hit enter.

What is 'win-r'?

This may be part of the issue as the window's oddity I mentioned has to due with the scenario in which if the parent of a newly created process (the new command prompt in this case) doesn't pay attention to a "refresh environment broadcast message" sent by the installer (and therefore doesn't know about the new env vars) its child process (your new command prompt?) inherits the old, outdated environment from its parent process.

Try Start->All Programs->Accessories->Command Prompt as well

FYI, on my 32-bit Vista machine when I try Start -> <type 'cmd' in the 'Start Search' text line at the bottom of Start> it finds and opens up a command prompt on my system that has been setup an environment for Windows SDK Windows Server 2008 DEBUG mode.

Jon

[Luis Lavena]

On Tue, Dec 8, 2009 at 5:10 PM, Jon <jon.f...@gmail.com> wrote:
>> I'll try and get that together.  In the meantime, I can tell you I pop the
>> run dialog by typing win-r and then type 'cmd' and hit enter.
>
> What is 'win-r'?
>

Windows key + R, the shortcut to "Run"

> This may be part of the issue as the window's oddity I mentioned has to due with the scenario in which if the parent of a newly created process (the new command prompt in this case) doesn't pay attention to a "refresh environment broadcast message" sent by the installer (and therefore doesn't know about the new env vars) its child process (your new command prompt?) inherits the old, outdated environment from its parent process.
>

No, seems to me be other thing. Let's way for him to test and then get
our conclusions.

>
> FYI, on my 32-bit Vista machine when I try Start -> <type 'cmd' in the 'Start Search' text line at the bottom of Start> it finds and opens up a command prompt on my system that has been setup an environment for Windows SDK Windows Server 2008 DEBUG mode.
>

That seems to be the magical search / ala spotlight of Windows.
Windows + R is the old Run command.

[Alexey Borzenkov]

On Sun, Dec 6, 2009 at 11:59 PM, Roy Pardee <rpa...@gmail.com> wrote:
> If I say "set pathext" in a command window I get back just:
>
>   PATHEXT=.RB;.RBW
>
> But if I look in the env var dialog ('advanced' tab on computer properties),
> the only PATHEXT var set is at the system level & the value is:
>
>   .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
>
> If I manually set pathext to all that in my command window, I can call ruby
> w/out the .exe, but the next command window has of course forgotten the
> extra goo & sets me back to just .RB;.RBW.
>
> If I use the dialog to create a user-level PATHEXT var & set it to the whole
> long thing it seems to have no effect--I still only get .rb;.rbw.
>
> Any further thoughts?

Just a theory:

- You try installing ruby without elevation
- HKCU is where PATH and PATHEXT are updated
- If HKCU PATH is incomplete (i.e. only C:\Ruby19\bin) then Windows
will append it to HKLM PATH
- But not so for PATHEXT. If HKCU PATHEXT is .rb;.rbw, then resulting
PATHEXT is .rb;.rbw, thus your problem

Jon, is there any way to modify the installer to fall back to reading
PATHEXT from HKLM if value in HKCU is not there? I looked at master
and it seems that it reads PATHEXT from HKCU, chops it into a list
(empty string results in empty list I suppose) and merges the
resulting empty list with .rb/.rbw, thus source of the problem.

[Alexey Borzenkov]

P.S. I think adding %PATHEXT% at the head if Root is HKCU and PATHEXT
is empty should work too. Something like this:

diff --git a/resources/installer/util.iss b/resources/installer/util.iss
index 354bc51..00bab73 100644
--- a/resources/installer/util.iss
+++ b/resources/installer/util.iss
@@ -60,6 +60,10 @@ begin
try
RegQueryStringValue(RootKey, SubKey, RegValue, OrigData);
Log('Original ' + AnsiUppercase(RegValue) + ': ' + OrigData);
+ if RegValue <> 'PATH' and OrigData = '' then
+ begin
+ OrigData = '%' + RegValue + '%'
+ end

PathishList := StrToList(OrigData, Delim);

Though I don't remember Pascal syntax very well and don't know if
that's correct.

[Octagon]

On Dec 8, 11:41 pm, Alexey Borzenkov <sna...@gmail.com> wrote:
> Jon, is there any way to modify the installer to fall back to reading
> PATHEXT from HKLM if value in HKCU is not there? I looked at master
> and it seems that it reads PATHEXT from HKCU, chops it into a list
> (empty string results in empty list I suppose) and merges the
> resulting empty list with .rb/.rbw, thus source of the problem.

This might be the problem, but it was originally reported that PATHEXT
was set on the system level only and the environment variable still
had some different value. If it were the case, it would be reported
that PATHEXT was set to .eb;,rbw at the user level. So, it is
necessary to double check that.

Jon, if ever possible, please do not modify the installer so that it
fells back to HKLM. For example, I have manually set EXTPATH in HKCU
to %PATHEXT%;.rb;.rbw long ago when I compiled Ruby from source. If I
run the installer with empty HKCU, I would like it to do the same.
More so, if I run the installer with the current setting, being
Administrator or not, I would like it to be unchanged.

Why not to take the safe path: if the installer ever wants to modify
HKLM, it should always run with elevated privileges. The only reason
to do so I see is to install Ruby for all users. Possibly the
installer should just ask that. Depending on the answer, only HKLV or
only HKCU should be modified. I do not see any reason for any
fallback.

[Jon]

> Just a theory:
>
> - You try installing ruby without elevation
> - HKCU is where PATH and PATHEXT are updated
> - If HKCU PATH is incomplete (i.e. only C:\Ruby19\bin) then Windows
> will append it to HKLM PATH
> - But not so for PATHEXT. If HKCU PATHEXT is .rb;.rbw, then resulting
> PATHEXT is .rb;.rbw, thus your problem

Alexey is right on PATH/PATHEXT behavior and it appears this is the reason why "ruby.exe" was needed after the install.

Just tested using a FakeInstaller on a non-admin vista account:

Before install and after uninstall PATHEXT = .COM;.EXE;.BAT;.CMD;.VBS...from a cmd prompt

After install PATHEXT = .RB;.RBW from cmd prompt...no HKLM PATHEXT entries.

Jon

[Luis Lavena]

That do not happen on Windows 7 non-admin.

[Roy Pardee]

Ah, excellent.  So you don't need me to do a screencast or whatever?

Thanks!

[Jon]

Good points and I want to think about Alexey's patch a bit more and do a more testing before changing anything. Clearly though, not having .EXE on a command prompts PATHEXT isn't good.

That said, currently the installer makes it's decision to use HKLM or HKCU based upon whether it's running as an admin account or not.

Look at:

http://github.com/oneclick/rubyinstaller/blob/master/resources/installer/util.iss

lines 13-37 and then 57 and 58.

Given the importance of getting this right for Final, I'll create a branch with updated code and ask you to review.

Jon

[Jon]

> Ah, excellent. So you don't need me to do a screencast or whatever?

No need, but I would like you to file a bug on the installer :(

Luis...are you going to re-enable the Issues tab on GitHub or do you want Roy to file at RubyForge?.....I vote for GitHub rather than RubyForge)

Jon

[Jon]

On Tue, 8 Dec 2009 19:26:43 -0300
Luis Lavena <luisl...@gmail.com> wrote:

> On Tue, Dec 8, 2009 at 7:24 PM, Jon <jon.f...@gmail.com> wrote:
> >> Just a theory:
> >>
> >> - You try installing ruby without elevation
> >> - HKCU is where PATH and PATHEXT are updated
> >> - If HKCU PATH is incomplete (i.e. only C:\Ruby19\bin) then Windows
> >> will append it to HKLM PATH
> >> - But not so for PATHEXT. If HKCU PATHEXT is .rb;.rbw, then resulting
> >> PATHEXT is .rb;.rbw, thus your problem
> >
> > Alexey is right on PATH/PATHEXT behavior and it appears this is the reason why "ruby.exe" was needed after the install.
> >
> > Just tested using a FakeInstaller on a non-admin vista account:
> >
> >
> > Before install and after uninstall PATHEXT = .COM;.EXE;.BAT;.CMD;.VBS...from a cmd prompt
> >
> > After install PATHEXT = .RB;.RBW from cmd prompt...no HKLM PATHEXT entries.
> >
>
> That do not happen on Windows 7 non-admin.

Really? What were they before and after install and then after uninstall.

Roy...Please try the FakeInstaller tonight and show us PATH and PATHEXT (a) before install, (b) after install, and (c) after uninstall.

Jon

[Roy Pardee]

http://screenr.com/yXU

I turned it off before the uninstall--but uninstall restored both PATHEXT and PATH.

[Luis Lavena]

On Tue, Dec 8, 2009 at 10:46 PM, Roy Pardee <rpa...@gmail.com> wrote:
> http://screenr.com/yXU
>
> I turned it off before the uninstall--but uninstall restored both PATHEXT
> and PATH.
>

Ok, I have think I see the root of the issue.

At this time we assumed environment variables worked like PATH:

First, System PATH is loaded and then append User's PATH

That is the default behavior to avoid a malicious tool to overwrite
PATH and Windows built-in tools.

But PATHEXT is different, PATHEXT works like any other environment
variable, so it requires invoke %PATHEXT% to keep a reference to the
previous, system value.

So, here is what should happen (from my PoV)

non-admin installs are high likely will not find PATHEXT (or will be
empty). If so, %PATHEXT% should be prepend to the list before adding
.RB and .RBW

For admin installs, this will not be an issue since PATHEXT at system
level contains .EXE;.COM, etc.

I don't know how to say this on Pascal Scripting, but may be similar
to Alexey comments and code.

Roy: can you setup the following in the User section of environment variables?
(Right click in Computer, Properties, Go to Advanced, button at the bottom)

Variable: PATHEXT
Value: %PATHEXT%

Then, try installing again.

Tried same approach here and worked.

[Roy Pardee]

Huh--no fix here.  After trying pathext=%pathext% I also tried pathext=%pathext%;.boo & the .boo did not show up in a new command window.

It looks to me like windows is not heeding the user version of that variable at all.  If I set it to .bibbity;.bobbity;.boo on the dialog it has no effect--I either get the system version value, or the installer-created .rb;.rbw.  And I never see the installer-created value in the dialog.

FWIW--having to type "myscript.rb" instead of simply "myscript" to get a script to run is no hardship at all.  So long as I can double-click an .rb file & have it run, that's all the associations I need...

 

[Alexey Borzenkov]

On Wed, Dec 9, 2009 at 4:47 PM, Roy Pardee <rpa...@gmail.com> wrote:
> Huh--no fix here.  After trying pathext=%pathext% I also tried
> pathext=%pathext%;.boo & the .boo did not show up in a new command window.
>
> It looks to me like windows is not heeding the user version of that variable
> at all.  If I set it to .bibbity;.bobbity;.boo on the dialog it has no
> effect--I either get the system version value, or the installer-created
> .rb;.rbw.  And I never see the installer-created value in the dialog.

Maybe that's because you're using 64-bit Windows? I don't know much
about how 32-bit changes are isolated, but it's possible that values
32-bit installer wrote in registry are hidden somewhere and don't show
up in the dialog for that reason. Why cmd.exe (which is 64-bit I
suppose) prefers them over what you set in the dialog is beyond me
though.

Try searching HKCU for PATHEXT with regedit, maybe you'll find a
hidden Environment key somewhere (installer tries to set it in under
HKCU\Environment key).

> FWIW--having to type "myscript.rb" instead of simply "myscript" to get a
> script to run is no hardship at all.  So long as I can double-click an .rb
> file & have it run, that's all the associations I need...

Since I develop small utilities with Python/Ruby every day I disagree.
Less typing is much better (though I prefer managing environment
(PATH/PATHEXT) myself)... Hell, I even tried to add shebang support to
Windows once (http://git.kitsu.ru/mine/windows-shebang-support.git) to
have my scripts without extension at all, but sadly cmd.exe is stupid
enough to try running DIRECTORIES. :( So I had to abandon the idea...

[Jon]

> First, System PATH is loaded and then append User's PATH
>
> That is the default behavior to avoid a malicious tool to overwrite
> PATH and Windows built-in tools.
>
> But PATHEXT is different, PATHEXT works like any other environment
> variable, so it requires invoke %PATHEXT% to keep a reference to the
> previous, system value.
>
> So, here is what should happen (from my PoV)
>
> non-admin installs are high likely will not find PATHEXT (or will be
> empty). If so, %PATHEXT% should be prepend to the list before adding
> .RB and .RBW
>
> For admin installs, this will not be an issue since PATHEXT at system
> level contains .EXE;.COM, etc.

I see similar things from my testing last nite.

Before I'm going to be comfortable changing any code I'm going to do the following:

* Spelunk MSDN to hopefully find somehting that confirms what we're all seeing
* Test current FakeInstaller on XP under non-admin acct
* Update the FakeInstaller code to handle this OS peculiarity
* Add a "fakeruby.exe" to the FakeInstaller so that we can quickly test this situation. We'll need to be able to run "fakeruby blah" and "fakeruby.exe blah" and both work. "fakeruby.exe" will simply echo stuff to stdout.

While I currently believe appending .RB and .RBW to the existing %PATHEXT% looks decent, I'd like to see a bit more testing on 32-bit and 64-bit XP, Vista, and 7.

Jon

[Jon]

> Maybe that's because you're using 64-bit Windows? I don't know much
> about how 32-bit changes are isolated, but it's possible that values
> 32-bit installer wrote in registry are hidden somewhere and don't show
> up in the dialog for that reason. Why cmd.exe (which is 64-bit I
> suppose) prefers them over what you set in the dialog is beyond me
> though.

Awhile ago I ran across some documentation in Windows SDK/MSDN summarizing some of these 64-bit issues. A lotg of details on pointers and datatypes, but I also remember info on the registry. I also think the Inno guys have some documentation floating around.

Would you all use our friend Google today and tomorrow and help round up the relevant info?

> > FWIW--having to type "myscript.rb" instead of simply "myscript" to get a
> > script to run is no hardship at all.  So long as I can double-click an .rb
> > file & have it run, that's all the associations I need...
>
> Since I develop small utilities with Python/Ruby every day I disagree.
> Less typing is much better (though I prefer managing environment
> (PATH/PATHEXT) myself)

I agree with Alexey on this one and am against having to type things like "ruby.exe myscript.rb". I *am* strongly for finding a fix that allows people to do "ruby myscript" and even better, "myscript"

Jon

[Jon]

> Before I'm going to be comfortable changing any code I'm going to do the following:
>
> * Spelunk MSDN to hopefully find somehting that confirms what we're all seeing

Nothing much of interest so far, however I did find this regarding the same issue with the Groovy NSIS-based installer

http://archive.codehaus.org/lists/org.codehaus.groovy.scm/msg/24915578.12394897206...@codehaus01.managed.contegix.com

...and there current installer code which addresses PATHEXT. Interesting that they read the env var PATHEXT, append new values onto it and then call their custom WriteEnvStr fcn that basically figures out whether the installer is running as admin or non-admin and updates the correct HKLM or HKCU key.

# Set PATHEXT if the user checked the resp. checkbox
825 ReadINIStr $R0 "$PLUGINSDIR\fileassociation.ini" "Field 4" "State"
826 ${If} $R0 == '1'
827 ReadEnvStr $R0 "PATHEXT"
828 StrCpy $R0 "$R0;.groovy;.gy"
829 Push "PATHEXT"
830 Push $R0
831 Call WriteEnvStr
832 ${EndIf}

I'll work up another FakeInstaller that, for non-admin, appends .RB;.RBW to the existing PATHEXT then writes the modified value to HKCU\Environment.

As we're no longer attempt to cache existing PATH or PATHEXT values and try to restore them at uninstall time (bad idea), the HKCU\Environment\PATHEXT value will simply be deleted at uninstall. This behavior will effectively erase any non-admin PATHEXT customizations that existed pre-install.

Feedback?

Jon

[Luis Lavena]

What about my comment of use "%PATHEXT%" instead of reading the env
value of PATHEXT?

If HKCU\Environment\PATHEXT doesn't exist, prepend %PATHEXT% to the
additional values
If it exist, work normally

During uninstall, remove additional values (rb, rbw)
if the only thing left if %PATHEXT%, remove it.

[Jon]

> What about my comment of use "%PATHEXT%" instead of reading the env
> value of PATHEXT?
>
> If HKCU\Environment\PATHEXT doesn't exist, prepend %PATHEXT% to the
> additional values
> If it exist, work normally

To be clear...

(1) By "%PATHEXT%" do you mean read HKLM's PATHEXT value?

(2) By "If it exists, work normally" do you mean that if HKCU's PATHEXT exists *and* has a value, simply append .RB/RBW to the existing PATHEXT value *only* if RB/RBW are not already present?

> During uninstall, remove additional values (rb, rbw)
> if the only thing left if %PATHEXT%, remove it.

That's another option to consider.

Thinking through how I would do the comparison (simple string compare?) of the HKCU\Environment\PATHEXT value (with additional rb, rbw removed) and %PATHEXT%...

Gotta be some corner cases to watch out for...here's one...I'm going to start a gist so we can work through the all the scenarios in one place until we're happy.

* Install prepends %PATHEXT% to additional values for HKCU's PATHEXT
* user updates %PATHEXT% sometime later
* uninstall removes RB/RBW and compares the remaining value of HKCU's PATHEXT
to the updated %PATHEXT% and discovers they're different so it leaves the
"old" %PATHEXT% in HKCU\Environment\PATHEXT
* is this a problem since HKCU's PATHEXT is a subset of the modified %PATHEXT% ?


Jon

[Luis Lavena]

On Wed, Dec 9, 2009 at 4:05 PM, Jon <jon.f...@gmail.com> wrote:
>> What about my comment of use "%PATHEXT%" instead of reading the env
>> value of PATHEXT?
>>
>> If HKCU\Environment\PATHEXT doesn't exist, prepend %PATHEXT% to the
>> additional values
>> If it exist, work normally
>
> To be clear...
>
> (1) By "%PATHEXT%" do you mean read HKLM's PATHEXT value?
>

No, %PATHEXT%

That will get expanded and resolved to the HKLM PATHEXT value automatically

If you do it using the contents of HKLM, then there will be no way
that a system-level value propagates to the user.

> (2) By "If it exists, work normally" do you mean that if HKCU's PATHEXT exists *and* has a value, simply append .RB/RBW to the existing PATHEXT value *only* if RB/RBW are not already present?
>

Exactly.

>
>> During uninstall, remove additional values (rb, rbw)
>> if the only thing left if %PATHEXT%, remove it.
>
> That's another option to consider.
>
> Thinking through how I would do the comparison (simple string compare?) of the HKCU\Environment\PATHEXT value (with additional rb, rbw removed) and %PATHEXT%...
>
> Gotta be some corner cases to watch out for...here's one...I'm going to start a gist so we can work through the all the scenarios in one place until we're happy.
>
> * Install prepends %PATHEXT% to additional values for HKCU's PATHEXT
> * user updates %PATHEXT% sometime later
> * uninstall removes RB/RBW and compares the remaining value of HKCU's PATHEXT
>  to the updated %PATHEXT% and discovers they're different so it leaves the
>  "old" %PATHEXT% in HKCU\Environment\PATHEXT
> * is this a problem since HKCU's PATHEXT is a subset of the modified %PATHEXT% ?
>

Please read my first answer, I'm saying not to expand/evaluate PATHEXT
contents, but instead use "%PATHEXT%" in the HKCU

[Jon]

> Please read my first answer, I'm saying not to expand/evaluate PATHEXT
> contents, but instead use "%PATHEXT%" in the HKCU

Gotcha...prepend the *string* %PATHEXT% and ensure HKCU\Environment\PATHEXT is a REG_EXPAND_SZ. That I agree with.

I'll work up an updated FakeInstaller so we can test the corner cases

Jon