'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

[Jon]

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

As I'm also creating a "fakeruby.exe" for the FakeInstaller to live in <FAKE_INSTALL_DIR>\bin, any requests for what it should output? For example...

c:\>fakeruby foo bar baz
FakeRuby v1.0
called with 3 args

[Jon]

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

The below fix for install seems to be working...should have a new fake installer for testing either this weekend or early next week.

If you squint a little, the patch looks very close to what Alexey sent...

C:\Users\Jon\Documents\RubyDev\rubyinstaller-trunk>git diff
diff --git a/resources/installer/util.iss b/resources/installer/util.iss
index 354bc51..f3e35fb 100644
--- a/resources/installer/util.iss
+++ b/resources/installer/util.iss
@@ -61,6 +61,13 @@ begin

RegQueryStringValue(RootKey, SubKey, RegValue, OrigData);
Log('Original ' + AnsiUppercase(RegValue) + ': ' + OrigData);

+ // ensure originally empty users PATHEXT also contains system values
+ if (RootKey = HKCU) and (AnsiUppercase(RegValue) = 'PATHEXT') and (OrigData = '') then
+ begin
+ Log('Empty HKCU ' + AnsiUppercase(RegValue) + ', prepending %PATHEXT% to new value');
+ OrigData := '%PATHEXT%';
+ end;
+
PathishList := StrToList(OrigData, Delim);

NeedRegChange := MungePathish(PathishList, NewData, RegValue, IsUninstaller);

[Alexey Borzenkov]

On Sat, Dec 12, 2009 at 12:59 AM, Jon <jon.f...@gmail.com> wrote:
> C:\Users\Jon\Documents\RubyDev\rubyinstaller-trunk>git diff
> diff --git a/resources/installer/util.iss b/resources/installer/util.iss
> index 354bc51..f3e35fb 100644
> --- a/resources/installer/util.iss
> +++ b/resources/installer/util.iss
> @@ -61,6 +61,13 @@ begin
>     RegQueryStringValue(RootKey, SubKey, RegValue, OrigData);
>     Log('Original ' + AnsiUppercase(RegValue) + ': ' + OrigData);
>
> +    // ensure originally empty users PATHEXT also contains system values
> +    if (RootKey = HKCU) and (AnsiUppercase(RegValue) = 'PATHEXT') and (OrigData = '') then

Just my $0.02, but I really think it should be != 'PATH'. :) The
reason is that if you would ever want to add paths to INCLUDE, or LIB,
or CPATH, or LIBRARY_PATH, or RUBYLIB, or PYTHONPATH, or countless
other possible values, you might want to bring HKLM values in... It's
much easier and future proof that way. But.. whatever. :)

[Jon]

Awh 'cmon, no one will ever need more than 640K? ;)

Good points and may make sense to back down the paranoia level after more testing.

Jon

[Jon]

New FakeInstaller for testing at

http://dl.dropbox.com/u/3269968/FakeRubyInstaller_1.9.1-p243_PATHEXT-FIX-1.exe

This version also installs a "fakeruby.exe" stub that spits out some useful info to confirm PATH and PATHEXT are what they should be. To use, simply open up a new command prompt after install and type things like

>fakeruby
>fakeruby -c test the args blah.rb

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

This isn't going to work out as well as we thought and will likely get us a few bug reports.

For example, Octagon's example of a user have %PATHEXT%;.RB;.RBW as their HCKU PATHEXT value. What could happen is

* standard user installs and selects options to modify PATH and file assocs
* installer sees a non-empty HKCU with .RB/.RBW so it doesn't change it
* sometime later user uninstalls
* uninstaller updates PATH, removes .RB/.RBW from PATHEXT
* uninstaller sees that only thing left is %PATHEXT% so it removes it, and the empty value
* user unhappy that their original %PATHEXT%;.RB;.RBW was removed by the installer

After toying with things a bit this weekend, I've reverted back to a very simple solution that I think may be better.

In summary, if a user has selected the file assoc option, upon uninstall the uninstaller will clean up only the Software\Classes part of file assoc but will not touch the Environment\PATHEXT value that makes up the second part of file assocs. PATH will still be cleaned up as it has been in the past.

This option is not perfect by any means, and it needs more testing from you guys to see if it's what we want for Final. I'm not tied to this option by any means, but I currently like it better than our earlier version.

The current diff from the fake branch is:

C:\Users\Jon\Documents\RubyDev\rubyinstaller-trunk>git diff

diff --git a/resources/installer/fake-rubyinstaller.iss b/resources/installer/fake-rubyinstaller.iss
index ef2bf7e..07c7700 100644
--- a/resources/installer/fake-rubyinstaller.iss
+++ b/resources/installer/fake-rubyinstaller.iss
@@ -167,8 +167,10 @@ begin
if GetPreviousData('PathModified', 'no') = 'yes' then
ModifyPath([ExpandConstant('{app}') + '\bin']);

+{* leave PATHEXT reg value as-is instead of guessing wrong
if GetPreviousData('FilesAssociated', 'no') = 'yes' then
ModifyFileExts(['.rb', '.rbw']);
+*}
end;
end;
end;
diff --git a/resources/installer/util.iss b/resources/installer/util.iss
index 354bc51..f720d2d 100644

--- a/resources/installer/util.iss
+++ b/resources/installer/util.iss
@@ -61,6 +61,13 @@ begin
RegQueryStringValue(RootKey, SubKey, RegValue, OrigData);
Log('Original ' + AnsiUppercase(RegValue) + ': ' + OrigData);

+ // ensure originally empty users PATHEXT also contains system values

+ if (RootKey = HKCU) and (AnsiUppercase(RegValue) <> 'PATH') and (OrigData = '') then

+ begin
+ Log('Empty HKCU ' + AnsiUppercase(RegValue) + ', prepending %PATHEXT% to new value');

+ OrigData := '%' + AnsiUppercase(RegValue) + '%';

[Roy Pardee]

Looks good over here!  Dig it:

http://screenr.com/yvU

The only hitch is that the HKCU\Environment\PATHEXT key is not deleted on uninstall--I have to delete that manually & then log off/on in order to bring %PATHEXT% back to its pre-install state.  This does not bother me, but I'm guessing y'all are going to want to tweak some more. ;-)

Thanks so much for all your work!

Cheers,

-Roy

[Luis Lavena]

On Sun, Dec 13, 2009 at 7:27 PM, Jon <jon.f...@gmail.com> wrote:
>
>> > During uninstall, remove additional values (rb, rbw)
>> > if the only thing left if %PATHEXT%, remove it.
>
> This isn't going to work out as well as we thought and will likely get us a few bug reports.
>
> For example, Octagon's example of a user have %PATHEXT%;.RB;.RBW as their HCKU PATHEXT value.  What could happen is
>
> * standard user installs and selects options to modify PATH and file assocs
> * installer sees a non-empty HKCU with .RB/.RBW so it doesn't change it
> * sometime later user uninstalls
> * uninstaller updates PATH, removes .RB/.RBW from PATHEXT
> * uninstaller sees that only thing left is %PATHEXT% so it removes it, and the empty value
> * user unhappy that their original %PATHEXT%;.RB;.RBW was removed by the installer
>

From my point of view I would have to disagree.

I believe we had a conversation about prior-states and what to assume
about user prior user environment. You also gather feedback from
InnoSetup people and saw the behavior of Python installers.

This is exactly the same as saving and restoring the file associations
state. If the user had them previously selected and proceed to
indicate association with the new installer, then we assume these
values will be cleared after uninstall.

That happen with all the programs/tools that associate files with them.

I believe PATHEXT should behave exactly the same.

The corner case will only affect users that manually had tweaked
PATHEXT to be able to start Ruby scripts without extensions, most
likely they had installed previous One-Click Installer.

I personally never used file associations or file extensions
shortcuts, so never tweaked PATHEXT beyond normal Python installation
and One-Click Installer.

As Roy mentioned in the reply, the manual removal of the registry key
to restore it previous behavior will generate more bug reports and
will require some instructions to avoid getting tired of reply the
exact same issue over and over.

Yet again, I had my quota of messups in the past so, once again, could be wrong.

[Jon]

> I believe we had a conversation about prior-states and what to assume
> about user prior user environment. You also gather feedback from
> InnoSetup people and saw the behavior of Python installers.
>
> This is exactly the same as saving and restoring the file associations
> state. If the user had them previously selected and proceed to
> indicate association with the new installer, then we assume these
> values will be cleared after uninstall.

The mods in yesterday's FakeInstaller do the following:

1) No state is saved/restored by the installer. Same behavior as RC1
2) If FakeInstaller finds an empty HKCU PATHEXT and the user chooses file assocs, it will (a) update HKCU\Software\Classes (no change from RC1), and (b) create an HKCU\Environment\PATHEXT value with %PATHEXT%;.RB;.RBW. If HKCU PATHEXT was not empty, .RB/.RBW is added if they are not already present.
3) Upon uninstall, HKCU\Software\Classes is cleaned up (no change from RC1), (b) PATH is cleaned up, and (c) the user's HKCU\Environment\PATHEXT is left as it was after install. No cleanup in any form is attempted on PATHEXT.
4) Part (3c) is a change in behavior from RC1. Where RC1 would try to remove .RB/.RBW and, if PATHEXT is then empty, delete the registry value, this FakeInstaller does nothing at all with a users PATHEXT data.

The result of all of this is that the installer can leave behind a modified version of PATHEXT that what it originally found. It doesn't try to restore any previous state. Specifically, PATHEXT will be one of the following after uninstall:

1) If no user PATHEXT existed, post-install the user will have a PATHEXT of %PATHEXT%;.RB;.RBW but none of the HKCU\Software\Classes machinery from the installer will be present
2) If the user had a non-empty PATHEXT, post-install it will be the same as the original but with .RB and .RBW on the end. None of the HKCU\Software\Classes machinery from the installer will be present

On the negative side, the uninstaller leaves behind a modified PATHEXT. On the positive side, the HKCU\Software\Classes machinery is still removed and the uninstaller doesn't futz with PATHEXT in ways that may impact previous setups.

One of the other uninstall options is the previous suggestion, remove .RB/.RBW and if the only thing remaining on PATHEXT is %PATHEXT% delete the string and delete the resultingly empty PATHEXT value.

The question is which uninstall behavior will cause fewer end-user surprises and bug reports?

The final call is yours Luis as I'm happy to implement whatever behavior you decide you want from among our options.

That includes the option of simply updating HKCU or HKLM's Software\Classes tree for file assocs and leaving the user to manually update PATH and PATHEXT post-install and post-uninstall.

Jon

[Dhage Jayesh]

i am too unable to install ruby 

my laptop 64 bit

i installed ruby 2.3.0

but when i am going to check ruby -v in cmd it says ruby is not an internal bla bla bla bla

what to do 

[Roy Pardee]

Have you tried closing that cmd window and opening a new one & trying ruby -v in that?

--
You received this message because you are subscribed to the Google Groups "RubyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyinstalle...@googlegroups.com.
To post to this group, send email to rubyin...@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyinstaller.
For more options, visit https://groups.google.com/d/optout.

--

Roy Pardee
http://datawranglr.com