Variable-based PATH entries are getting overwritten by static PATH entries on 'config' or 'switch' about berrybrew HOT 8 CLOSED

Thanks for your feedback!

I'll take a look at these issues this week and hopefully come up with some
solutions.

Cheers,

Steve

On Fri, Jul 8, 2016 at 4:12 PM, PeterCJ [email protected] wrote:

When berrybrew edits the PATH during a 'config' or 'switch', it expands
any %VARIABLE% in the PATH and writes them back hardcoded.

For example, my original PATH had
...;%VARTHATCHANGES%\bin;...
but after running 'config' or 'switch', it became
...;c:\expanded\version

However, I sometimes need to change %VARTHATCHANGES%: with the hardcoded
PATH, new instances no longer follow the change in %VARTHATCHANGES%.

My guess is that the C# Environment.GetEnvironmentVariable() is
evaluating all the sub-variables inside the PATH when it reads it, and I
can understand why that would often be a nice feature. But I don't know if
there's a way to override that behavior to get at the raw value of the
PATH. (I know that the Windows Scripting Host WScript.Shell's WshEnvironment
object https://msdn.microsoft.com/en-us/library/6s7w15a0(v=vs.84).aspx
does not expand the internal variables when reading a PATH, but I don't
know if there's a way to tell the C# interface to not do the internal
expansion.

Unfortunately, unless this gets fixed, I won't be able to use berrybrew.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#18, or mute the thread
https://github.com/notifications/unsubscribe/AMcCP0XVPek9oD6kPO5EYO3aN2GtUW1pks5qTss1gaJpZM4JIcEi
.

from berrybrew.

Hi Peter, I have fixed this in 0944109, and the new binary/zip/code are all in master.

Can you please test it out to see if it performs as you expect?

from berrybrew.

There's a change in behavior. It looks like the right value is in the path (it includes the %VARIABLE% directories)... but when I open a new command window, that path doesn't get properly used. And, even stranger -- when I use a VBScript which reads the SYSTEM and USER paths, then writes the same values back into the PATHs, and open a new command window, now it does work.

VBScript readWritePath.vbs

dim objShell
dim collectionSystemEnvironment
dim collectionUserEnvironment
dim sysPath
dim usrPath

Set objShell = CreateObject("WScript.Shell")
set collectionUserEnvironment = objShell.Environment("User")
set collectionSystemEnvironment = objShell.Environment("System")
usrPath = collectionUserEnvironment("PATH")
sysPath = collectionSystemEnvironment("PATH")
msgbox(usrPath)
msgbox(sysPath)
collectionUserEnvironment("PATH") = usrPath
collectionSystemEnvironment("PATH") = sysPath

For example, I have a System Path which includes %SystemRoot%\System32\Wbem, which allows me to find WMIC.exe, before I've run the berrybrew:
A. I open up cmd.exe#1, run wmic /c -> wmic shows its help information, so it is found in the PATH
B. Still in cmd.exe#1, berrybrew off -> it runs and claims to have changed the PATH
C. I open cmd.exe#2, and try to run wmic /? -> 'wmic' is not recognized. :-( If I then echo %PATH%, it does include %SystemRoot%\System32\Wbem
D. Run readWritePath.vbs (either in cmd.exe#2 or from Windows Explorer)
E. Open cmd.exe#3, and try to run wmic /? -> wmic shows its help information again, so the PATH has taken effect. If I echo %PATH%, it actually includes the c:\windows\System32\Wbem expanded value... But I can also manually grab the System PATH from the appropriate locations in regedit (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment) or the Environment Variable gui (System Properties > Environment Variables), and they match for C and E...

Very weird.

When I looked in http://stackoverflow.com/a/7739361, which uses the same Registry.LocalMachine.CreateSubKey(keyName).GetValue you're now using, I see that it uses Registry.LocalMachine.CreateSubKey(keyName).SetValue to put the value back. I wonder if maybe that will tell windows to actually use it as the path. This is a strange one.

(unfortunately, I'm not set up for C# development, so I haven't been able to play around and see whether or not .SetValue will do the trick. I guess a C# environment needs to go into my Round Tuit queue)

from berrybrew.

I've figured out what the issue is. SetEnvironmentVariable() updates the
values of the Path key properly, however, it forces it to REG_SZ.
However, we need the value to be of REG_EXPAND_SZ type.

Updating the registry directly and bypassing the above method does not
inform the system that the variable has been updated, so an additional call
to SendMessageTimeout() is required.

I've got most of it working, I'm just making some other small adjustments
and I'll get a new build up soon.

Here's what I'm experiencing:

• hard-coding %SYSTEMROOT% as a path using the GUI shows up in the GUI as
  the variable after closing/re-opening
• the %SYSTEMROOT% variable is expanded when displayed in the cmd window
• it appears in its variable form in the registry
• I altered the PATH berrybrew writes out to %SYSTEMROOT\berrybrew\bin,
  and inserted it with berrybrew config
• in regedit, the value type is properly converted to REG_EXPAND_SZ
• in the env var UI, all variable-based paths appear as the variable name
• on the CLI, the variable-based paths are shown in their expanded form (I
  kind of expect this, as you can't change the variables in PATH and have
  them take effect in the parent/current shell anyhow)

When you see the Changes file updated with today's date, you know that I've
upped the new binary.

I greatly appreciate the help you've provided :) Please let me know if
after I've put up the new binary whether it's closer to what we're hoping
to achieve.

Thanks,

Steve

ps. This is the first ever C# code I've worked on, so all of it is new to
me.

On Mon, Jul 11, 2016 at 6:11 PM, PeterCJ [email protected] wrote:

There's a change in behavior. It looks like the right value is in the
path (it includes the %VARIABLE% directories)... but when I open a new
command window, that path doesn't get properly used. And, even stranger --
when I use a VBScript which reads the SYSTEM and USER paths, then writes
the same values back into the PATHs, and open a new command window, now it
does work.

VBScript readWritePath.vbs

dim objShell
dim collectionSystemEnvironment
dim collectionUserEnvironment
dim sysPath
dim usrPath

Set objShell = CreateObject("WScript.Shell")
set collectionUserEnvironment = objShell.Environment("User")
set collectionSystemEnvironment = objShell.Environment("System")
usrPath = collectionUserEnvironment("PATH")
sysPath = collectionSystemEnvironment("PATH")
msgbox(usrPath)
msgbox(sysPath)
collectionUserEnvironment("PATH") = usrPath
collectionSystemEnvironment("PATH") = sysPath

For example, I have a System Path which includes
%SystemRoot%\System32\Wbem, which allows me to find WMIC.exe, before I've
run the berrybrew:
A. I open up cmd.exe#1, run wmic /c -> wmic shows its help information,
so it is found in the PATH
B. Still in cmd.exe#1, berrybrew off -> it runs and claims to have
changed the PATH
C. I open cmd.exe#2, and try to run wmic /? -> 'wmic' is not recognized.
:-( If I then echo %PATH%, it does include %SystemRoot%\System32\Wbem
D. Run readWritePath.vbs (either in cmd.exe#2 or from Windows Explorer)
E. Open cmd.exe#3, and try to run wmic /? -> wmic shows its help
information again, so the PATH has taken effect. If I echo %PATH%, it
actually includes the c:\windows\System32\Wbem expanded value... But I
can also manually grab the System PATH from the appropriate locations in
regedit (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment)
or the Environment Variable gui (System Properties > Environment Variables),
and they match for C and E...

Very weird.

When I looked in http://stackoverflow.com/a/7739361, which uses the same
Registry.LocalMachine.CreateSubKey(keyName).GetValue you're now using, I
see that it uses Registry.LocalMachine.CreateSubKey(keyName).SetValue to
put the value back. I wonder if maybe that will tell windows to actually
use it as the path. This is a strange one.

(unfortunately, I'm not set up for C# development, so I haven't been able
to play around and see whether or not .SetValue will do the trick. I
guess a C# environment needs to go into my Round Tuit queue)

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AMcCPyxLLN8WHd6czvQmJR8KsoVl_9oXks5qUtvEgaJpZM4JIcEi
.

from berrybrew.

reopened

from berrybrew.

Thanks for your support. It's working for me now.

I am able to switch or off, and it doesn't mess up my variable-based paths -- they all behave as they have historically behaved.

And since you also got #11 released, I am able to install my perls where I want them, and switch between versions. Which makes me a happy user. :-)

Thanks for your effort in improving berrybrew (and willingness to learn C# to do it). I've done my first C# hello-world today, using the compiler that comes with Microsoft.NET Framework (ie, without having to install the Visual Studio or Mono environments)... but I wasn't fast enough to see if I could play with the environment editing...

from berrybrew.

That's great that it works for you now!

I plan on making some improvements over the next little while.

I'd like to make it user-centric, that is, not admin only. However, because
the way Windows does env vars where System comes before User, User env vars
will never take precedence over a Strawberry/ActiveState system install, so
if a system perl is installed, user-based deployments won't work.

I like the idea of having a non-administrator implementation, so that each
user can have their own berrybrew setups. I suppose I could just look at
the system path and check for strawberry or activestate, and then warn that
user-based config won't work.

Tonight, I'm going to start writing quasi unit tests, to ensure future
changes don't break things. Almost all of my Perl modules on CPAN have
~100% coverage. I'm going to write the tests in Perl though, and just
literally shell out the berrybrew command. When I'm more experienced and
have more time, I'll write proper C# tests.

Cheers,

Steve

On Tue, Jul 12, 2016 at 11:54 AM, PeterCJ [email protected] wrote:

Thanks for your support. It's working for me now.

I am able to switch or off, and it doesn't mess up my variable-based
paths -- they all behave as they have historically behaved.

And since you also got #11
#11 released, I am able to
install my perls where I want them, and switch between versions. Which
makes me a happy user. :-)

Thanks for your effort in improving berrybrew (and willingness to learn C#
to do it). I've done my first C# hello-world today, using the compiler that
comes with Microsoft.NET Framework (ie, without having to install the
Visual Studio or Mono environments)... but I wasn't fast enough to see if I
could play with the environment editing...

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AMcCPz-9_wFhx5JHPrKbPdBxLCt7nu2iks5qU9TWgaJpZM4JIcEi
.

from berrybrew.

Confirmed rectified in 440afb6

from berrybrew.