This little java code produces different output dependend on execution environment:
ProcessBuilder builder = new ProcessBuilder( "cmd", "/c", "set" );
builder.directory( new File("c:/") );
Process p = builder.start();
System.out.println(System.getenv("PATH"));
If executed on command promt it will state the full PATH variable which is also shown by navigating to Systenproperties->Environmentvariables (PATH) or using cmd, typing in set, and looking up for the PATH variable.
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Perforce;C:\Program Files\GnuWin32\bin;
If executed in eclipse it will also state the a PATH variable but it is not consitent with the one in the system itself.
Path=C:/Program Files/Java/jre7/bin/client;C:/Program Files/Java/jre7/bin;C:/Program Files/Java/jre7/lib/i386;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Perforce;C:\eclipse;
The issue is, i need to run an external application (openssl) in my java environment using a processbuilder. The path of that application is also stated in the Path variable. But this path is not available if the code is executed by using eclipse (which is a must in this case).
So i have absolutely no clue why this is the case and how to solve it.
I even tryed to stream the executing class to the hdd and try to execute that class using another processbuilder, but still the Path variable is not equal to the expected one (guess due to inheritance)
Please, if some of you guys have any clue how to get the same content of the Path variable using eclipse as the system itself does, point it out.
btw. Using a WINDOWS machine & using Kepler build
Related
I've recently started using fish, and I needed to use a jar file for google's bundletool.
As such, I needed to set up an alias/function for bundletool, and I chose a function since it seems more "fishy".
My function is simple:
function bundletool
java -jar bundletool-all-1.12.1.jar $argv
end
The bundletool jar itself lives at ~/.local/bin, which is on my fish user path:
lase#laser-razer /m/c/U/matth [1]> echo $fish_user_paths
/home/lase/.local/bin /usr/local/go/bin /home/lase/.nvm /home/lase/.cargo/bin /home/lase/.cargo
In a regular shell, I can execute java -jar bundletool-all-1.12.1.jar, and the command runs as expected. However, in the function, fish doesn't seem to know about my fish_user_paths, and reports it cannot find the jar file.
To remedy this, I had to update my function to specify the full path:
function bundletool
java -jar ~/.local/bin/bundletool-all-1.12.1.jar $argv
end
This works, but I feel like I'm doing something incorrectly. Should I be setting up my paths or functions in a different fashion?
Your function will run in the ordinary environment.
It will run with the current $PATH [0] and, more importantly to you, the current working directory.
What happens is this:
java -jar bundletool-all-1.12.1.jar
Will tell java to run the jar found at bundletool-all-1.12.1.jar.
Notably, fish just hands java the string "bundletool-all-1.12.1.jar", and java will then not look at $PATH. It does not care about $PATH. It simply looks at "bundletool-all-1.12.1.jar", and tries to open a file by that name.
And it will find that file, if it is in the current directory.
And that's the reason this worked for you when you executed it interactively - because you happened to be in that directory
And then you tried it with the function, but you tried it from a different directory, and so it didn't work.
This works, but I feel like I'm doing something incorrectly. Should I be setting up my paths or functions in a different fashion?
No, giving the full path to the file instead of relying on the working directory is the right thing to do.
[0]: $fish_user_paths is just a variable you set, that fish will then take care to add to $PATH. $PATH is the actual variable that fish and other tools (including any command fish starts, if it wants to) will use to find commands.
I'm working on a script that automatically installs software. One of the programs to be installed includes its own command line commands and sub-commands when installed.
The goal is to use the program's provided commands to perform an action after its installation.
But running the command right after the program's installation I'm greeted by:
" is not recognized as an internal or external command , operable program or batch file"
If I open a new Powershell or cmd window the command is available in that instance.
What is the easiest way to to grant the script access to the commands?
Bender the Greatest's helpful answer explains the problem and shows you how to modify the $env:PATH variable in-session by manually appending a new directory path.
While that is a pragmatic solution, it requires that you know the specific directory path of the recently installed program.
If you don't - or you just want a generic solution that doesn't require you to hard-code paths - you can refresh the value of $env:PATH (the PATH environment variable) from the registry, via the [Environment]::GetEnvironmentVariable() .NET API method:
$env:PATH = [Environment]::GetEnvironmentVariable('Path', 'Machine'),
[Environment]::GetEnvironmentVariable('Path', 'User') -join ';'
This updates $env:PATH in-session to the same value that future sessions will see.
Note how the machine-level value (list of directories) takes precedence over the user-level one, due to coming first in the composite value.
Note:
If you happen to have made in-session-only $env:PATH modifications before calling the above, these modifications are lost.
If applicable, this includes modifications made by your $PROFILE file.
Hypothetically, other processes could have made additional modifications to the persistent Path variable definitions as well since your session started, which the call above will pick up too (as will future sessions).
This is because the PATH environment variable gets updated, but existing processes don't see that update unless they specifically query the registry for the live value of the update the PATH environment variable, then update PATH within its own process. If you need to continue in the same process, the workaround is to add the installation location to the PATH variable yourself after the program has been installed:
Note: I don't recommend updating the live value from the registry instead of the below in most cases. Other processes can modify that value, not just your own. It can introduce unnecessary risk, whereas appending only what you know should have changed is a more pragmatic approach. In addition, it adds code complexity for a case that often doesn't need to be generalized to that point.
# This will update the PATH variable for the current process
$env:PATH += ";C:\Path\To\New\Program\Folder;"
For a project I am working on I'm preparing data in MATLAB, then running the data through a separate external application (written in C++) named Model v2.exe, then performing further analysis with the output in MATLAB. I'm trying to create an M-file which does all of this, but I am struggling to get the C++ program to launch from my MATLAB code.
How can I launch an external application from within my MATLAB code?
You can either make use of the ! operator, or the system() command.
First, rename you application to something that has no spaces in the name, like modelv2.exe. Next, either make sure it is in the system path, as defined by your system environment variables, or generate a full path to it (eg: C:\Users\Phil\Desktop\modelv2.exe).
You can call an executable program from the command line using the exclamation point or the system command:
!modelv2
or:
!C:\Users\Phil\Desktop\modelv2.exe
will cause Windows to execute the program hello.exe if there is such a file in the current directory or on the system path. Alternatively:
system('modelv2');
or
system('C:\Users\Phil\Desktop\modelv2.exe');
will do the same thing.
References
"MATLAB Central - call and run an external program in matlab under windows", Accessed 2014-03-19, <http://www.mathworks.com/matlabcentral/answers/11568-call-and-run-an-external-program-in-matlab-under-windows>
I have changed the shell key in windows registry to gain custom shell (Kiosk usage):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon]
I set shell key to a batch file which runs two applications as below:
start "myFirstAppTitle" "myAppPath\myApp1.exe"
start "mySecondAppTitle" "myAppPath\myApp2.exe"
Each application runs but the second application which needs some files to be excuted throws an error which says could not find dependency files. whereas the dependency files are adjoining to the exe file and the mentioned app works fine, when starts from startup.
Meanwhile when i run the batch file manually it rusn fine.
I added the PATH command to the batch file but it did't work too.
Change the batch file to this:
set PATH=%PATH%;C:\MyAppPath
start "myFirstAppTitle" "myApp1.exe"
start "mySecondAppTitle" "myApp2.exe"
If you start executables without an absolute path, the path is relative to the current working directory. Also, when you specify an executable with a relative path, %PATH% is not searched for a matching subfolder with a matching executable.
Since the script worked when you manually started it, your working directory probably was C:\. However, when run at logon as a replacement shell, the working directory is most likely "%SystemRoot%\system32".
The problem solved strangely, i removed the title parameter of start command and it worked. In fact i used start command this fashion:
set PATH=%PATH%;C:\MyAppPath
start myapp.exe
start myapp2.exe
I'm having this weird situation :
My user's and system's PATH variable is different than the PATH in powershell.
When I do :
PS C:\$env:path
C:\Windows\System32\WindowsPowerShell\v1.0\;c:\oldpath
However this is not correct, it looks like it stuck on some old PATH variable of my system, so none of the udpates I've done on it didn't change this variable (I do restart after every change to test).
Why is this happening? Do I have to set a PATH variable just for powershell?
The change might be "delayed", so try one or more of these solutions:
Log off and on again;
Task Manager > Restart "Windows Explorer" (explorer.exe)
Restart your launcher app (launchy, SlickRun, etc)
Reboot
Explanation:
Powershell will inherit the environment of the process that launched it (which depends on how you launch it). This is usually the interactive shell (explorer.exe). When you modify the environment from computer properties, you modify the environment of explorer.exe, so if you launch powershell from explorer.exe, (for example from the start menu) you should see the new environment.
However, if you launch it from something else (say a cmd.exe shell that you already had opened), then you won't since that process was launched under the old environment.
In other words: be careful how you are launching things.
In my case, I installed an app that incorrectly added itself to the PATH by creating a powershell profile that would override $env:PATH and blow out the existing configuration every time I started powershell.
Check if you have profile at USER\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 and if it's doing anything fishy like setting $env:PATH.