Comments (8)
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\versionHowever, 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 withberrybrew 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 usrPathSet 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") = sysPathFor 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.
Related Issues (20)
- Add a 'howto' doc that describes adding/changing features of berrybrew HOT 1
- Add 'snapshot' to the UI
- Create a UI simulator HOT 1
- Remove all but one select box; make all commands use it HOT 1
- Add new 'check manifest' development tool
- Add automation to check prod config to dev config HOT 2
- Change 'root_dir' to 'instance_dir' in README's "Configure root directory" section
- 'special-dir' hidden command not listed in berrybrew doc
- Typos in documentations HOT 6
- Put all 'info' options into array HOT 1
- Release script needs to update license year in messages.json
- Doc issues
- Add bookend pipes to all markdown table doc references
- Add better links to documentation (developer doc etc) in README
- "Add an exit code" link in dev doc points to "Add an error code" and 404s
- "Configure root directory" must be revisited; at minimum root_dir name must be changed
- Add copyright to README
- Doc issues HOT 1
- API doc: "Available" section sometimes shows the description HOT 1
- Add ability to dump run config from registry back to config file
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from berrybrew.