background info;
an application is installed on many different PCs, W2000 and XP pro and for multiple users, let's call it foobar, note there is no msi or silent uninstall for this app. therefore, we would like to remove its' entry manualy;
If in the registry environment (path line) we have path=c:\windows;c:\windows\system32;c:\foobar\bin;c:\foobar\bat;c:\c:\oracle\bin
how would we, from the command line, change that line to path=c:\windows;c:\windows\system32;c:\c:\oracle\bin
each path line might be different but c:\foobar\bin;c:\foobar\bat; has to be deleted on all machines.
My thought,
export registry env setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and remove the unwanted items from there and reimport. Easier solution??
To permanently change the PATH use
Control Panel, System, Environment, System Variables
Control Panel, System, Environment, User Variables
Related
I have a problem assessing my advanced settings of my computer, anytime i get to the properties of my computer it freezes and vanishes, I decided to set my path through the command prompt. Though the lines below works. Its just temporal and the path is unset immediately i close the running command prompt,
set path=%path%;C:\python27
I am just wondering why my computer's property panel vanishes.
Any others ways to set the environment variables permanent?
try using setx PATH "%PATH%;C:\python27"
Note that u need to close the current cmd window, after executing this command as the changes will reflect in newer instances only.
The employees of our company use gnome-terminal run from Debian workstations to access a variety of systems running different O/Ss on our local network. Everything works very well except that the host systems and their applications use different character sets, either ISO-8859-1 ("Latin 1") or UTF-8, and the server applications notably do NOT adapt to the locale of the user. This requires the user to manually set gnome-terminal's character set encoding each time one starts a new session!
(In case that's not clear, we always want to log into system X using ISO-8859-1, and always log into system Y using UTF-8. This has to do with the relative antiquity of the O/S of each system, the older ones having little or no accomodation of UTF-8 while the newer ones deal rather grumpily with ISO-8859-1.)
It seems to me that gnome-terminal's character set encoding should be associated with the system one's logging into instead of the system one's calling from. And that therefore, the character set should be one of the parameters that can be pre-set in the profile. This is the way other terminal emulators behave, notably the Windows and Mac emulators that we use outside the office.
But in lieu of configuring it in the profile (which is not possible), does anyone know a way of setting the character set encoding as part of a command line invocation of gnome-terminal?
I've been trying to solve this annoyance off-and-on for years... any solution would receive our eternal gratitude. :)
in the good old times, gnome-terminal support --disable-factory, you can set up for local editing files:
#!/bin/sh
export GDM_LANG="de_DE#euro"
export LANG="de_DE#euro"
export RC_LANG="de_DE#euro"
export LC_ALL="de_DE#euro"
gnome-terminal --disable-factory
or remote access to a linux-box:
#!/bin/sh
export GDM_LANG="de_DE#euro"
export LANG="de_DE#euro"
export RC_LANG="de_DE#euro"
export LC_ALL="de_DE#euro"
gnome-terminal --disable-factory --tab --title="Server1 DE" --command "ssh user#Server1"
Now at gnome 3.10 I get
... Option "--disable-factory" is no longer supported ...
So, I am with you and will keep looking ...
Mario
This worked for me.
LANG=en_US.iso885915 /usr/bin/gnome-terminal
I have just installed an app which overwrote my $PATH variable... so now, a bunch of stuff will not work. While I have a full backup, I am hoping that there is an easier approach than to restore, get the PATH, the "roll it forward" again.
Is there a location in the windows registry (or anywhere else) that stores an older $PATH setting?
Thanks,
GS
If anyone is interested, I found the answer...
using REGEDIT, it is under
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment or
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Session Manager\Environment
In my case, it was under HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002...
GS
type in cmd:
set path=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;
above code will set the path temporarily. To set permanently, add %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\; to System Properties -> Advanced System Settings -> Environment Variables
if i change hkey_current_user/environment/path in registry, get-env "PATH" doesn't reflect the new value unless I close rebol console and re_open it.
Environment variables are not the same things as Registry Keys.
Windows does consult particular registry keys when it is setting up the default environment a program gets when it launches from the shell. However, changing it won't inject those values into the environments of already running processes (in Rebol or any other program). Conversely, if you set things in the environment of a running program you won't see those changes reflected back into the registry.
If you want to read registry values, there is an API for that:
http://www.rebol.com/docs/sdk/registry.html
BUT rightly or wrongly: it is generally accepted (on every platform I've used) that one must exit a program and restart it in order to refresh environment variables from system settings. If you try and work around that, you may cause more complexity and confusion than anything else.
I trying to put my Mac's data in order.
I have many rc-files at my root such as .vimrc, .srceenrc and .bashrc.
I would like to put these files to the specific folders such as .vimrc and .screenrc to ~/bin/coding and .bashrc then again to ~/bin/shells.
How can you determine where these rc-files must be?
Seriously, you should leave them where they are. Applications will be looking for them in specific locations (probably your $HOME directory which is not root, by the way, or shouldn't be). This is a very old UNIX convention that you should attempt to change only if you fully understand the consequences.
Not meaning to sound condescending but your error in naming your home directory as your root directory seems to indicate your knowledge level of how it all works is less than it should be to understand those consequences (apologies if that offends you, I agonized over the best way to say it - what I mean is that you should tread carefully).
If you move them, you will have to ensure you run the applications that use them with their paths fully specified, and some applications may not let you do that.
They all start with "." so that they're hidden to the normal ls commands and, if you're using a graphical file browser, there should be a way to hide them there as well (such as the Gnome File Manager CTRL-H).
Configuration of a program is both defined at system-level and user-level, you can tweak the user-level one, which resides in your home, to help you in what you need.
No need to group them in subfolders as you said: leaving them in your home (not root) is following the convention everybody uses, rc-files usually stay there after the program has been uninstalled, so if some day you make a fresh install you'll find the application configured as you left it.
Also, by leaving them in your home, you can bring your own home folder to another system and have the environment set as you like it.