Windows 7.
It's for my own machine, so it doesn't matter if it requires admin rights or something.
Preferably in Python or .NET, but I can learn a bit of Win32 (C/C++) programming if it's necessary.
if you want to permanently set environment variable, you can insert the new value into registry. eg with vbscript, add the path "c:\test" into PATH variable
Set WshShell = WScript.CreateObject("WScript.Shell")
strReg = "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path"
strSetting = WshShell.RegRead(strReg)
strNewSetting = strSetting&";c\test"
WshShell.RegWrite strReg, strNewSetting
So, if you use Python or other languages, you can do the same thing using your language's own api/modules to read and write registry
or you could try a Windows PowerShell script; PowerShell is installed on Windows 7 by default.
run powershell.exe
PS C:\> [Environment]::SetEnvironmentVariable("TestVariable", "Test value.", "User")
Then, for example, from cmd.exe
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\>echo %TestVariable%
Test value.
C:\>
Or (in a new) powershell.exe
PS C:\> echo $ENV:TestVariable
Test Value.
PS C:\>
check out http://technet.microsoft.com/en-us/library/ff730964.aspx
In C# the following creates a permanent environment variable:
Environment.SetEnvironmentVariable("foo", "bar", EnvironmentVariableTarget.Machine);
For anyone else looking for a quick commandline answer
SETX is available on windows servers (natively i think - http://technet.microsoft.com/en-us/library/cc755104.aspx )
Its also available in the Windows 7 and 8 toolkit.
Use the Environment class like this:
Environment.SetEnvironmentVariable("foo", "bar");
Programmatically modifying environment variables is only for the duration of the program. Have not heard of actually modifying the environment system-wide and making it effective there and then. I do not think that can be done, that would require poking around at privileged level and possibly messing with the core system to achieve that.
Even under Unix, it cannot be done despite some hacks to achieve it. I do remember seeing code that actually did modify the environment variables under MSDOS, by altering the MSDOS's _psp environment data structure, but that was a single-tasking system and 16bit with no protection whatsoever.
To sum up, I do not think you can and it would be unwise to do so, it could be perceived as if the system is under a threat by a 'trojan' or a 'virus' as a result if attempting to do so, not alone that, as a user, I would not like for a program to modify the system environment variable without my consent! Sure, a program can write to the registry to make it permanent, but I would still like to know what is the purpose of it and why.
Related
Ahead of time I am a newb at programming/scripting. I mainly research what I want and just edit it to fit my needs when possible.
Environment:
Windows 7
CMD
Usergroup = admin
Occurs when launching as user(admin) or launching cmd as administrator
When I use CMD to change an environment setting, it does not save to the system.
Example:
C:\Users\admin>SET TESTVARIABLE = "This is a test"
C:\Users\admin>SET
TESTVARIABLE = "This is a test"
C:\Users\admin>_
close out cmd, reopen, use SET and the testvariable is no longer there.
Going through System > Advanced System Settings > Environment Variables > System Variables is the only way I can positively make changes to the variables.
This is also affected by any .bat files I make. Mine don't actually get applied when they run but other peoples that I copy(entire .bat file, not just text/context).
This is occuring on my (all at work) desk pc(win10) and 2x Remote Desktop (win7). I am admin and I'm using admin users on these RDP's.
Anyone have any idea what is happening, what i'm missing, how I can research it or fix it?
Variables set using the "set" command are only available in the cmd's instance. To save variables persistently see this: Set a persistent environment variable from cmd.exe
I would like to ask you if it's normal that my "Setting environment" changes after each system reboot or even if I just close my cmd console.
for example, I'm using python 3.5, when I wan to use python or to uses pip under the cmd I got an error like :
C:\>python
'python' is not recognized as an internal or external command,
operable program or batch file.
To fix this, I use :
set PATH=%PATH%;C:\Python35
It works after, but as I said before, once I restart my computer, or I close the console, I've the same problem !!!
Thanks in advance for your help and comments. I just would like to inform you that I'm using Windows 7 - 64bits.
You need to add this path in System (Windows+Pause key), Advanced, Environment variables. There you have two sections, System and User, in System, edit the PATH key.
The next time you start a console the path will be present.
Alternaly, if you don't want to modify the setting there (or you have no rights) you could start the app with a batch file which sets the path before launching the app.
In Ruby you can adapt the environment variables from within the script itself by using ENV eg ENV['path'] += 'C:\\Python35'
, I'm sure Python can do this too but wouldn't know how. In your use case this won't help of course.
The SETX command will set the variable permanently. Use SETX /? for information. Set a persistent environment variable from cmd.exe
For Python, many developers use venv which is included with the Python install. https://docs.python.org/3/library/venv.html?highlight=venv#module-venv
I have been puzzling over an issue with environmental variables in Windows 7.
We have a Jenkins server which cannot find the SSH keys in the %HOME% environmental variable as it wants to access the path:
/c/users/jenkins
However if I use
echo %HOME%
in a normal command prompt window as my Jenkins user then the result is
C:\users\jenkins
However, if I use the environment command in Windows PowerShell I also get
/c/user/jenkins
In the normal GUI accessible from the system properties - advanced tag -> environmental I get the following
C:\users\jenkins
I have tried setting them back, but the issue persists. In so far as Jenkins gets the same output as PowerShell.
How do I set them back? (Not that cmd and the Windows system think that they are set wrong.)
How on earth does accessing the same environmental variable give me different outputs?
Is there a way in which this can occur?
Where are they stored so I can manually edit where they are stored?
As mentioned in a comment by #Luis, the env command is not part of PowerShell. It is likely provided by some other set of utilities that you have installed and is intended to emulate the Linux env command.
To refer to an environment variable in PowerShell, use the $env:<variable-name> syntax or the environment provider - Get-Content env:\<variable-name>.
To set an environment variable, you can use $env:<variable-name> = "<variable-value>"
For more information, try running help about_Environment_Variables in PowerShell.
I'm trying to install a driver with a remote framework that lets me run shell commands spawned as children of the remoting/monitoring app on the remote machine, run as cmd /c "command". But the driver refuses to install due to a security feature which thinks the driver may be unsafe.
The driver also has quotes(spaces in path) so its something like
Dim command: command = "\\\\server\\driver\\folder\\Autorun.exe" /passive /norestart";
Set retVal = remote.Shell(command)
which runs
cmd /c " "\\server\driver\folder\Autorun.exe" /passive /norestart"
on the remote machine
I've tried and have had trouble using setx SEE_MASK_NOZONECHECKS 1 /m in a previous statement, I'm guessing that the subprocess don't see new global enviromental variables that weren't around when it's parent started, and won't work without a restart. I'd like to avoid a restart.
I tried running
cmd /c " set SEE_MASK_NOZONECHECKS=1 & "\\server\driver\folder\Autorun.exe" /passive /norestart"
but it doesn't seem to work. Any ideas?
You got a bit lost on the way SEE_MASK_NOZONECHECKS is used. It is not an environment variable and cannot be tinkered with from the command prompt, it is an option for ShellExecuteEx(). A winapi function that you indeed use to start programs. It isn't very clear what programming tools you have access to, using it in a batch file or VBScript isn't going to work. You'd need at least, say, VB.NET and pinvoke the function. You can get the required declarations from the pinvoke.net web site.
Let's talk about what's really going on, you might find a simpler solution. When you download a file from an Internet web site, Windows adds an extra stream to the file that indicates where the file came from. Which basically states "this file did not come from a safe place" and makes the driver installer balky. Which is rather an important feature if you think about it, your user is going to install software that can do a lot, you pretty much have free reign of the machine if you can get a driver installed.
If you right-click the file in Explorer and click Properties then you'll see this at the bottom of the window:
All that's needed is to click that Unblock button. So this is a simple way for your user to solve the problem. You could document the extra step in the install instructions. Also with the advantage that it is now the user that took responsibility of allowing potentially unsafe code to be installed.
Other ways to get the file unblocked is with PowerShell's Unblock-File command and the SysInterals' streams utility, -d option.
And you probably ought to consider the option of writing your own installer. Which will keep the driver packaged in the setup file so it won't be tinkered with by Windows. And the user gets the warning when he starts the installer instead. And it can be signed so the user has some confidence in where the file came from and that it didn't get messed with on its way to his machine. There are many utilities that help you write an installer, like InstallAware, InstallShield, NSIS, etcetera.
I beg to differ to Hans' answer:
Of course, SEE_MASK_NOZONECHECKS is as well a predefined environment variable. Changing it in a process and then starting a child process (e.g. msiexec.exe) which by defaults inherits the environment, has just the same result as using ShellExecuteEx() and providing SEE_MASK_NOZONECHECKS as a parameter to the SHELLEXECUTEINFO structure. The first method is preferred by admins or quick hacks, e.g. if you work with batch or script files which set the environment variable- or when the final call to the .msi file lying on the unsafe network drive is not done by your own code.
For example:
#echo off
set SEE_MASK_NOZONECHECKS=1
call msiexec.exe /i "\\MY_UNC_DRIVE\installs\mysetup.msi /qb /L*v "c:\logs\mysetup.log"
call "\\MY_UNC_DRIVE\installs\Just_another_setup.exe"
If you already use a ShellExecuteEx() in your code, then of course, go with the parameter as Hans mentioned, because this implementation it is more closed. (If you use CreateProcess(), think about using ShellExecuteEx() instead.
Getting back to the environment variable(s). Generally you cannot influence the environment of already started processes. You can set the default environment used by NEW processes by the "setx" command used in the question. But with "setx" you don't change the environment for your current process.This was the problem in question. For this you have to use "set" as shown. So either use both commands after each other or don't use setx at all because for running a setup on foreign machines, it is not clean to make permanent security changes without asking.
For more details on permanent changes/admin point of view, see:
https://superuser.com/questions/595211/removing-the-open-file-security-warning-in-windows-8/934283#934283
Important: As mentioned, there is no general way in Windows to influence processes which already run (only own-defined inter-process-communication maybe), so it is important to set the environment variable before starting the setup to be influenced.
One more thing: Some people think, one must use "SETLOCAL" in a batch file. Normally this is not necessary. Environment changes with "set" are not permanent, and do not incluence "other" processes- they are only inherited to subprocesses and, partly, to superprocesses. But, when the caller on first level ends, the environment is reverted to original state again.
I ended up setting "Launch applications and unsafe files" to enabled for Internet zone in Internet Explorer options under security(custom level) and then exporting the changes from HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 to a registry file and adding it with regedit /s.
After that I can run the installer of the shared drive.
One of these days I'll pare the registry file down to the minimum I guess.
P.S. I believe this causes IE to default to a warning page on startup.
I believe you need to put everything within the same quotation:
cmd /c "set SEE_MASK_NOZONECHECKS=1 & \\server\driver\folder\Autorun.exe /passive /norestart"
You can try these and see the difference in the output:
cmd /c "echo foo & echo bar"
cmd /c "echo foo" & "echo bar"
I'm porting a Linux tool-set that makes frequent use of shell functions to provide certain functionality. These functions are automatically sourced when you start a new shell and include things like changing the working directory, which is nigh impossible with stand-alone programs because child processes can't change their parent's environment.
For example, there is a function cdbm which changes the working directory to one that was previously bookmarked. Now I want to do the same on Windows, but I'm stuck with cmd.exe. As far as I understand the scripts could be ported to jscript, vbscript or plain batch, which shouldn't be a problem. But how do I make sure they automatically get sourced on startup and live in the shell's environment?
According to help cmd:
If /D was NOT specified on the command line, then when CMD.EXE starts, it
looks for the following REG_SZ/REG_EXPAND_SZ registry variables, and if
either or both are present, they are executed first.
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun
and/or
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
As a test, in regedit I created a new key in the HLM branch shown above called "AutoRun" with the string value "echo Hi". When I started a new instance of cmd I got:
Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
Hi
C:\Users\Username>
You could put in the name of a script to run instead (I would put in a fully specified path to the script or one with a environment variable in it like "%HOMEPATH%\scripts\scriptname" (including the quotes in case there are spaces in the name).
Edit:
The registry key has some side effects. One example is help. If I have the echo command above, for example, in the AutoRun when I type help vol I get a "Hi" right above the help text. Doing vol /?, though doesn't do that.
You can set either of the following registry keys to a batch file or other executable to run that program when CMD is started:
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun
HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun
A batch file should be able to change the current directory of the executing CMD process with the CD command, as it doesn't run as a subprocess. You can disable the autorun behaviour by supplying /D as a switch to CMD.
See CMD /? for more details.
Since cmd doesn't allow you to define functions in global scope, I'm a little at a loss to understand what exactly you're trying to achieve by auto-sourcing a script at startup. I tend to include a batch file directory in my path where you can put batch files I regularly need.
Look at cygwin.