I'm using this new machine, so as usual I go and set the execution policy so that I can use my profile script, after doing that however powershell now opens all batch files in a new cmd.exe window.
I tried undoing this step but it's still the same so I think it has nothing to do with the script execution policy, also I still have the powershell window in which I originally set the execution policy and this one behaves normally, only new windows have this problem.
I may have installed some software, but nothing is related to windows, and I tried setting the PATH variable to its exact value in the working window but it does not work.
Batch files will open in a new window if the PATHEXT environment variable does not contain '.BAT' as one of the executable extensions.
To check the variable, enter the following at the PowerShell prompt: $env:PATHEXT
Related
There are a lot of questions already asking similar things but none helped me:
Start new cmd.exe and NOT inherit environment?
Is there a command to refresh environment variables from the command prompt in Windows?
What i'm f.e. after is:
Create a batch- oder powershell script which
installs python to a system where python isn't installed (this works)
after a successful installation, run python with a python script as argument
(It should also work the same way for installing and using other apps like MSVC, git for windows, ...)
After installing python from a console, the path which has been added to the system environment variables isn't reflected in the current cmd instance environment.
But it's there when i start a new cmd or elevated cmd manually from the windows start menu and not from a script.
I tried the following without luck to update the environment of the existing console or create a new instance with the new user environment from script:
start /i/b&exit
start /i/b "%windir%\explorer.exe" "%windir%\system32\cmd.exe"
powershell -Command Start-Process -UseNewEnvironment -Wait -FilePath python -ArgumentList "test.py"
But for UseNewEnvironment it's documented that
the new process starts only containing the default environment
variables defined for the Machine scope. This has the side effect that
the $env:USERNAME is set to SYSTEM. None of the variables from the
User scope are included
and for start /i that
Ignore any changes to the current environment, typically made with SET. Use the original environment passed to cmd.exe
I think both approaches cannot be used for what i'm after.
Is there a simple possibility to automatically run a script in the new environment which the installer created without extensive code or third party binaries?
I have read somewhere, that the commands entered in the run dialog box are executed as if they are executed using the start command in CMD. Which I believed was the case (as i could executed applications registered at app paths key just by their name using run).
But i noticed a little bit of deviation from this behavior when I tried to run a command on run without extensions. To illustrate this behavior:-
I added .msc and .MSC (i am unaware of extension case sensitivity/insensitivity on windows) to the PATHEXT environment variable, such that it became like this:-
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.msc
After this I executed the following command in CMD, to start the Device Manager:-
start devmgmt
Which lead to execution of Device Manager.
But when i typed in the following command in run dialog box:-
devmgmt
it prompted me with an error stating:-
Well, If my statement in the first paragraph is correct, then why did I ended up with an error in the second case?
P.S.:- Upon googling about this issue before, i read several article which stated run prompt inherits PATHEXT values of CMD, for extension resolution. And if it doesn't, then there exists an policy (in gpedit or something) which makes the run prompt only possess the default PATHEXT values!! (correct me if i was wrong here)
I need to run some .bat files from Cygwin. Until now, these bat files didn't required any param, so I used the following method:
chmod +x $strBatFilename
cygstart "$WINDIR/explorer.exe" "$strBatFilename"
These commands implement 2 features that I need:
The .bat file is opened in a new window
The environment of the new window is the explorer's one, not the one of Cygwin
The problem that I have is that now I need to also pass a parameter to the bat file.
I don't know of a method to call explorer.exe with a file (my bat) as parameter and having some extra option to pass another parameter to the bat (sounds like passing a parameter to a parameter of explorer.exe).
I have searched and found that I can start a cmd.exe. I tried starting it directly or starting it using cygstart:
cygstart $WINDIR/system32/cmd.exe /c start "$strBatFilename $strBatParam"
I have managed to make it start in a new window and launch the .bat with a parameter, but the environment is not the explorer's one.
I don't know the exact differences between the two environments. What makes me say they are different is that when for example the bat contains a repo sync command, if it's open with explorer it runs the repo sync command smoothly, while if the bat is called from cmd.exe, the repo sync command will ask for my user name and email.
So, my question is: are you aware of any command that will start from Cygwin a .bat file
passing a parameter to it
opening it in a new window
having the new window inherit the explorer's environment ?
Thank you
I just installed scala but I can't call it from the command line. So I dutifully checked my path through the environmental variables of the control panel and saw the scala folder present. If I type scala from cmd within that folder, it works fine.
So I tried echo %PATH% from windows cmd to see any problem. If running a normal command window, I get almost the same path except it's missing the scala path item. If I run the command line (Admin), then the echoed path matches the environment variables version. Under this admin setting, scala works fine.
There is no user path variable defined, it's only a system variable.
I've never seen this before. Why is there a difference between admin path and non-admin path? And how do I access the scala path item from the non-admin command line?
Thanks!
I just had the same problem, it was caused by the environment variables not being refreshed. A reboot would have solved it, however there is a way to refresh the environment variables without a reboot.
Open cmd prompt window
Input set PATH=C
close and restart cmd prompt window
input echo %PATH% to check
This worked for me in Windows 10.
I have another bat file that I'm running, and once in the command prompt that bat file creates, I want to run another command in that window.
Here's what I have so far:
call C:\Batch\MyBatFile.bat (this creates the new command prompt that I want to use)
C:\Program\MyProgram.exe
However, the second line is being run in the original window, instead of the new command prompt. I tried using start C:\Program\MyProgram.exe, but that just ran in a 3rd new window instead.
If it's relevant, the first line is just setting a few environment variables that I need access to and MyProgram is a visual studio 2010 project. Technically, I might be able to modify that bat to run the command, but I'd rather avoid that solution as that bat file isn't owned by me (and thus whenever it's updated I'd have to update mine as well).
Thanks in advance.
You could try to inject your program.exe into cmd created by batfile.bat by redirecting it's input stream and then sending it a command, eg. echo C:\Program\MyProgram.exe | C:\Batch\MyBatFile.bat. This assumes that batch really just sets bunch of variables and does not use commands which reset/consume input stream.
Please note that if redirected/piped this way new command window will not stay open It will maybe :-) just execute your command and then close/exit.
Create a CMD script to run both of the commands that you have shown in the question. Maybe call it RunMyProgram.cmd. The contents are just the two lines that you have:
REM Source the environment variables.
REM Any new command prompt window that is opened can be ignored
CALL C:\Batch\MyBatFile.bat
C:\Program\MyProgram.exe
If what you have stated in the comments to your question is accurate regarding MyBatFile.bat setting up the environment variables and then starting a new window, then you should be able to make use of those environment variables after MyBatFile.bat exits.
If running RunMyProgram.cmd from a command prompt still has MyProgram.exe giving the error when the environment variable is not set, or if MyProgram.exe doesn't even start to run until you close the new window that popped up, then we need to see the exact commands that MyBatFile.bat is executing.