From Java, I'm extracting an executable into a location specified using File.createTempFile(). When I try to run my executable, my program hangs when it tries to read the first line of output.
I have discovered that if I try to run the same extracted executable from another program, it works if I specify the directory as C:\Documents and Settings\username\Local Settings\Temp\prog.exe. But if I specify the directory as C:\DOCUME~1\USERNA~1\LOCALS~1\Temp\prog.exe I get the hang.
Is there a way to unmangle the tilde filename in my program so I can specify a directory name that will work?
(And since I always like addressing the language and API design issues, is there any reason why Java File.createTempFile() and java.io.tmpdir have to evaluate to mangled filenames?)
You can use getCanonicalPath() to get the expanded path. E.g.:
try
{
File file = File.createTempFile("abc", null);
System.out.println(file.getPath());
System.out.println(file.getCanonicalPath());
}
catch (IOException e) {}
... produces ...
C:\DOCUME~1\USERNA~1\LOCALS~1\Temp\abc49634.tmp
C:\Documents and Settings\username\Local Settings\Temp\abc49634.tmp
I tested this on XP, but assume it would work similarly on other Windows operating systems.
See #raviaw's answer to your second question.
Wow, I never saw that. The fact is that the environment variable %TEMP% returns a mangled name (this is from my computer):
TEMP=C:\DOCUME~1\raviw\LOCALS~1\Temp
TMP=C:\DOCUME~1\raviw\LOCALS~1\Temp
Assuming that a newly create java VM uses the environment variable to get the temporary folder location, it is not VM's fault that the directories are coming mangled.
And even if you try to use System.getenv() to get the temporary folder, you will still have the same problem.
I would make sure that:
The problem is not caused by the fact that you have a directory called "prog.exe" (based on your question, I am assuming this);
If the file is "prog.exe", if it was not in use by any other program (an antivirus, maybe);
Checking if your computer is sane (this would be a very critical bug for any application that is not a web application and that need temporary files).
Related
I've recently searched how I could get the application's directory in Java. I've finally found the answer but I've needed surprisingly long because searching for such a generic term isn't easy. I think it would be a good idea to compile a list of how to achieve this in multiple languages.
Feel free to up/downvote if you (don't) like the idea and please contribute if you like it.
Clarification:
There's a fine distinction between the directory that contains the executable file and the current working directory (given by pwd under Unix). I was originally interested in the former but feel free to post methods for determining the latter as well (clarifying which one you mean).
In Java the calls
System.getProperty("user.dir")
and
new java.io.File(".").getAbsolutePath();
return the current working directory.
The call to
getClass().getProtectionDomain().getCodeSource().getLocation().getPath();
returns the path to the JAR file containing the current class, or the CLASSPATH element (path) that yielded the current class if you're running directly from the filesystem.
Example:
Your application is located at
C:\MyJar.jar
Open the shell (cmd.exe) and cd to C:\test\subdirectory.
Start the application using the command java -jar C:\MyJar.jar.
The first two calls return 'C:\test\subdirectory'; the third call returns 'C:\MyJar.jar'.
When running from a filesystem rather than a JAR file, the result will be the path to the root of the generated class files, for instance
c:\eclipse\workspaces\YourProject\bin\
The path does not include the package directories for the generated class files.
A complete example to get the application directory without .jar file name, or the corresponding path to the class files if running directly from the filesystem (e.g. when debugging):
String applicationDir = getClass().getProtectionDomain().getCodeSource().getLocation().getPath();
if (applicationDir.endsWith(".jar"))
{
applicationDir = new File(applicationDir).getParent();
}
// else we already have the correct answer
In .NET (C#, VB, …), you can query the current Assembly instance for its Location. However, this has the executable's file name appended. The following code sanitizes the path (using System.IO and using System.Reflection):
Directory.GetParent(Assembly.GetExecutingAssembly().Location)
Alternatively, you can use the information provided by AppDomain to search for referenced assemblies:
System.AppDomain.CurrentDomain.BaseDirectory
VB allows another shortcut via the My namespace:
My.Application.Info.DirectoryPath
In Windows, use the WinAPI function GetModuleFileName(). Pass in NULL for the module handle to get the path for the current module.
Python
path = os.path.dirname(__file__)
That gets the path of the current module.
Objective-C Cocoa (Mac OS X, I don't know for iPhone specificities):
NSString * applicationPath = [[NSBundle mainBundle] bundlePath];
In Java, there are two ways to find the application's path. One is to employ System.getProperty:
System.getProperty("user.dir");
Another possibility is the use of java.io.File:
new java.io.File("").getAbsolutePath();
Yet another possibilty uses reflection:
getClass().getProtectionDomain().getCodeSource().getLocation().getPath();
In VB6, you can get the application path using the App.Path property.
Note that this will not have a trailing \ EXCEPT when the application is in the root of the drive.
In the IDE:
?App.Path
C:\Program Files\Microsoft Visual Studio\VB98
In .Net you can use
System.IO.Directory.GetCurrentDirectory
to get the current working directory of the application, and in VB.NET specifically you can use
My.Application.Info.DirectoryPath
to get the directory of the exe.
Delphi
In Windows applications:
Unit Forms;
path := ExtractFilePath(Application.ExeName);
In console applications:
Independent of language, the first command line parameter is the fully qualified executable name:
Unit System;
path := ExtractFilePath(ParamStr(0));
Libc
In *nix type environment (also Cygwin in Windows):
#include <unistd.h>
char *getcwd(char *buf, size_t size);
char *getwd(char *buf); //deprecated
char *get_current_dir_name(void);
See man page
Unix
In unix one can find the path to the executable that was started using the environment variables. It is not necessarily an absolute path, so you would need to combine the current working directory (in the shell: pwd) and/or PATH variable with the value of the 0'th element of the environment.
The value is limited in unix though, as the executable can for example be called through a symbolic link, and only the initial link is used for the environment variable. In general applications on unix are not very robust if they use this for any interesting thing (such as loading resources). On unix, it is common to use hard-coded locations for things, for example a configuration file in /etc where the resource locations are specified.
In bash, the 'pwd' command returns the current working directory.
In PHP :
<?php
echo __DIR__; //same as dirname(__FILE__). will return the directory of the running script
echo $_SERVER["DOCUMENT_ROOT"]; // will return the document root directory under which the current script is executing, as defined in the server's configuration file.
echo getcwd(); //will return the current working directory (it may differ from the current script location).
?>
in Android its
getApplicationInfo().dataDir;
to get SD card, I use
Environment.getExternalStorageDirectory();
Environment.getExternalStoragePublicDirectory(String type);
where the latter is used to store a specific type of file (Audio / Movies etc). You have constants for these strings in Environment class.
Basically, for anything to with app use ApplicationInfo class and for anything to do with data in SD card / External Directory using Environment class.
Docs :
ApplicationInfo ,
Environment
In Tcl
Path of current script:
set path [info script]
Tcl shell path:
set path [info nameofexecutable]
If you need the directory of any of these, do:
set dir [file dirname $path]
Get current (working) directory:
set dir [pwd]
Java:
On all systems (Windows, Linux, Mac OS X) works for me only this:
public static File getApplicationDir()
{
URL url = ClassLoader.getSystemClassLoader().getResource(".");
File applicationDir = null;
try {
applicationDir = new File(url.toURI());
} catch(URISyntaxException e) {
applicationDir = new File(url.getPath());
}
return applicationDir;
}
in Ruby, the following snippet returns the path of the current source file:
path = File.dirname(__FILE__)
In CFML there are two functions for accessing the path of a script:
getBaseTemplatePath()
getCurrentTemplatePath()
Calling getBaseTemplatePath returns the path of the 'base' script - i.e. the one that was requested by the web server.
Calling getCurrentTemplatePath returns the path of the current script - i.e. the one that is currently executing.
Both paths are absolute and contain the full directory+filename of the script.
To determine just the directory, use the function getDirectoryFromPath( ... ) on the results.
So, to determine the directory location of an application, you could do:
<cfset Application.Paths.Root = getDirectoryFromPath( getCurrentTemplatePath() ) />
Inside of the onApplicationStart event for your Application.cfc
To determine the path where the app server running your CFML engine is at, you can access shell commands with cfexecute, so (bearing in mind above discussions on pwd/etc) you can do:
Unix:
<cfexecute name="pwd"/>
for Windows, create a pwd.bat containing text #cd, then:
<cfexecute name="C:\docume~1\myuser\pwd.bat"/>
(Use the variable attribute of cfexecute to store the value instead of outputting to screen.)
In cmd (the Microsoft command line shell)
You can get the name of the script with %* (may be relative to pwd)
This gets directory of script:
set oldpwd=%cd%
cd %0\..
set app_dir=%pwd%
cd %oldpwd%
If you find any bugs, which you will. Then please fix or comment.
I released https://github.com/gpakosz/whereami which solves the problem in C and gives you:
the path to the current executable
the path to the current module (differs from path to executable when calling from a shared library).
It uses GetModuleFileNameW on Windows, parses /proc/self/maps on Linux and Android and uses _NSGetExecutablePath or dladdr on Mac and iOS.
Note to answer "20 above regarding Mac OSX only: If a JAR executable is transformed to an "app" via the OSX JAR BUNDLER, then the getClass().getProtectionDomain().getCodeSource().getLocation(); will NOT return the current directory of the app, but will add the internal directory structure of the app to the response. This internal structure of an app is /theCurrentFolderWhereTheAppReside/Contents/Resources/Java/yourfile
Perhaps this is a little bug in Java. Anyway, one must use method one or two to get the correct answer, and both will deliver the correct answer even if the app is started e.g. via a shortcut located in a different folder or on the desktop.
carl
SoundPimp.com
This is a follow-up question to this one (just as a brief description: I have been able to run a Java program by double-clicking on the .jar file on OS X and Windows, but not on Linux, as with the latter I get a file path problem).
Through trying out a few things using NetBeans under Ubuntu (12.04) I found that the problem seems to be located in what the program considers to be its working directory (which I concluded from the output of File.getAbsolutePath()). If I start my application in NetBeans, everything works (even under Ubuntu), and
System.out.println(new File(".").getAbsolutePath());
gives me /home/my_home/projects/VocabTrainer/., which is my project folder and thus correct. However, if I double-click on the .jar file, located in /home/my_home/projects/VocabTrainer/dist, the output I get under Ubuntu suddenly is merely /home/my_home/. This is problematic as I want to access a data file which is located in a sub-directory of my dist dir.
Does anyone know the cause of this behaviour, and how I can solve the problem?
PS: I don't know if this is required, but here's the output of java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.5) (6b24-1.11.5-0ubuntu1~12.04.1)
OpenJDK Server VM (build 20.0-b12, mixed mode)
I think you're confusing the location of the JAR with the current working directory.
To determine the former, see How to get the path of a running JAR file?
The cause, not really, at the moment. But you may not want to handle it that way, due to the evident unpredictability. Something like this should get the file, assuming you use the qualified class name of something in the jar in the below getResource call.:
URL url = this.getClass().getClassLoader().getResource("thepackage/ofyourclass/JunkTest.class"); //get url of class file. expected: ("jar:file:/somepath/dist/yourjar.jar!qualified/class/name.class")
File distDir = null;
if(url.getProtocol() == "jar") {
String classPath = null;
String jarPath = url.getPath();
if(jarPath.matches(".*:.*")) jarPath = new URL(jarPath).getPath();
classPath = jarPath.split("!")[0];
distDir = new File(classPath).getParentFile(); //may need to replace / with \ on windows?
} else { //"file" or none
distDir = new File(url.toURI()).getParentFile();
}
//... do what you need to do with distDir to tack on your subdirectory and file name
EDIT: I should point out this is clearly hacky. You may be able to add the file's location to the classpath directly at startup (or include the file you're looking for in the jar). From this you could use this.getClass().getClassLoader().getResource() with the filename of what you're looking for directly, which would get you to something like:
URL url = this.getClass().getResource("yourfile");
File file = new File(url.toURI());
//... use file directly from here
FURTHER EDIT: ok, adapted to your missing protocol, and spread it out, so error messages will be more readable for you.
I am developing a program that calls R functions from Java using JRI/rJava. I was coding the program in NetBeans on another machine, which was working fine (i.e. able to run the code). I have since then moved to another machine and have been running into problems.
The exact error message I am seeing is this:
Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
java.lang.UnsatisfiedLinkError: E:\R\R-2.13.1\library\rJava\jri\jri.dll: The specified path is invalid
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1807)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1732)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at org.rosuda.JRI.Rengine.<clinit>(Rengine.java:19)
at com.rjava.test.rtest.main(rtest.java:64)
Java Result: 1
I have read the FAQs for JRI/rJava, and have been scouring the internet for fixes, but have made no progress. Here is what I have done so far:
Created an environment variable called R_HOME: "E:\R\R-2.13.1"
Added "%R_HOME%\bin\x64" to the PATH environment variable
Added "%R_HOME%\library\rJava\JRI" to the PATH environment variable (this is where jri.dll is located)
Set the required jar files as compile time libraries (JRI.jar, JRIEngine.jar, REngine.jar) in NetBeans
set the following VM options in NetBeans: : -Djava.library.path=E:\R\R-2.13.1\library\rJava\jri (This is where jri.dll is located)
I have restarted my computer to make sure that the changes stick.
To make sure I configured things correctly, I ran the following in the command line:
java -cp E:\R\R-2.13.1\library\rJava\jri\JRI.jar;E:\R\R-2.13.1\library\rJava\jri\examples rtest
And the example java files ran fine. I'm beginning to think my new machine just hates me.
The message indicates that it the path E:\R\R-2.13.1\library\rJava\jri\jri.dll is invalid. Are you sure that path exists? Also, is E a mapped drive that is mapped to a path that has spaces in it? I'm not sure if the spaces are the issue, but it eliminates one issue. I would try just putting the dll in C:\ or somewhere very simple and seeing if it can find it there as a simple test.
Also verify that the -Djava.library.path is being passed as you think it is (you can check that with visualvm or jconsole).
You could try this:
-Djava.library.path=E:\R\R-2.13.1\library\rJava\jri -cp E:\R\R-2.13.1\library
\rJava\jri;E:\R\R-2.13.1\library\rJava\jri\JRI.jar;E:\R\R-2.13.1
\library\rJava\jri\examples
The reason I say this is that, perhaps the .dll also needs to be in the classpath as well as the library path in order for the classloader to load it? Its probably not true, but worth trying. Also is "rJava" correct? Other than that, it looks to me like your doing it right.
To locate JRI installed with rJava, use system.file("jri",package="rJava") in R.
set that path to your path (environment variables in windows),
restart your netbeans. and try to run your program again
As part of my python-based program, I have to call a Java program - solved that perfectly with os.system(). It worked well, until I moved the entire thing from one directory to the other. I changed all the filepaths in the python code, and the java program - as best I can tell, I don't really understand java - relies on relative file paths, which weren't changed during the move. But now, the java program won't open. The command line appears then vanishes almost instantly, so I know that os.system() is working. It must be to do with the filepath I'm using in os.system, as when I change that back to the original filepath it works perfectly fine again. Code below:
os.system("java -jar C:\\Documents and Settings\\enginx_mgr.ISIS\\My Documents\\ISAProgramFiles\\JPivSource\\jpivc.jar %s"%fileNames)
Where fileNames is a variable thingie passed to the java program as an argument, which I'm fairly sure isn't the problem. If I call the python program directly from cmd.exe, then it gives me back the error message "Unable to access Jarfile C:\Documents". I thought this might have to do with the spaces in the filepath, so I put underscores in:
os.system("java -jar C:\\Documents_and_Settings\\enginx_mgr.ISIS\\My_Documents\\ISAProgramFiles\\JPivSource\\jpivc.jar %s"%fileNames)
And it gave me the same "Unable to access Jarfile" message, but this time with the full filepath. Trying os.path.exists() on the filepath returns true, so python knows its a real filepath; I guess it must be the command line disagreeing with it, but I don't know why. Any ideas?
Edit: Original filepath, if its of interest, was C:\Inetpub\ftproot\JPivSource\jpivc.jar
Edit 2: Its almost certainly not the filepath, going by the answers below and the fact that none of them work (and that the original filepath works). Checked the security options out of a hunch, and I have full control over the .jar file, as does the system, so its not that it can't access it for security reasons. Still at square zero.
Not a direct answer but ...
I think it is better to call .bat file instead of direct call to java with many command line option. This way you will not need to change Python program to add some other options (like -Xms2048m or -Dfile.encoding=utf8).
Such .bat file is also much easier to debug.
Your problem looks to be caused because of a typo somewhere. This should fix it:
Open Windows Explorer
right click on the file
click "Properties"
copy the location
paste that location into your script, with directories escaped.
You have to put quotes around your path.
os.system('java -jar "C:\\Documents and Settings\\enginx_mgr.ISIS\\My Documents\\ISAProgramFiles\\JPivSource\\jpivc.jar" %s' % fileNames)
I'm sorry for offering up another file path solution, but this wasn't mentioned, and it seems likely that the changing of paths would be causing the issue. So, if you wouldn't mind humouring me?
os.system("java -jar C:\\Documents\ and\ Settings\\enginx_mgr.ISIS\\My\ Documents\\ISAProgramFiles\\JPivSource\\jpivc.jar %s"%fileNames)
All I've done differently, is escape the spaces with a backslash.
You said that os.path.exists is returning True, and that's fine, but you're trying to execute a command line program by passing it a number of arguments. The program reading the arguments will interpret the string as several strings because of the spaces.
You could also try altering the quotes that you are using:
os.system('java -jar "C:\\Documents and Settings\\enginx_mgr.ISIS\\My Documents\\ISAProgramFiles\\JPivSource\\jpivc.jar" %s' % fileNames)
That file path you're using does look quite strange.
Synopsis: When calling an executable that links to shared libraries from Java code on Tomcat, I get errors on Windows 2003 whereas the executable works great on a command prompt.
I wanted to do this in Linux, but, alas, got outvoted and have to implement it using Windows Server 2003. Here it goes,
I have a simple Java code running on Tomcat which, when it receives a "start" signal from another server has to run an external executable (written in C++, using shared library DLLs from OpenCV and ffmpeg) like so
String cmd = "c:\\workspace\\process_video.exe -video " + filename;
// Execute the command
Process proc = null;
try {
proc = rt.exec(cmd);
} catch (Exception e) {
System.out.println("VA-> Exception thrown in running the command!");
errorOut.append(e.getStackTrace().toString());
}
Now, when I run the command in process_video from a DOS command prompt, it works (doesn't matter which directory it's issued from). However, when it is run through the Tomcat->my Java code->rt.exec() chain, cmd doesn't get executed, although the exception doesn't get thrown. When I examine Windows event logs, I see an APPCHRASH event for process_video with Fault Module Name cv110.dll, which is one of the OpenCV DLLs I link from cmd.
One solution would be to stuff all the DLLs used in process_video into the tomcat\lib directory, but this hurts my programmatic sensibilities, so I want to know if there is a better way to solve this issue. What user does Tomcat use when running executables on Windows? Maybe I can give more privileges to that user? Should I add the DLL paths to Tomcat's configuration file?
Any help will be much appreciated,
Thanks!
Cuneyt
Add an entry in the PATH evironment variable that points to where your DLLs are. If this doesn't work for your app, you can try adding the entry to Tomcat's PATH. You have to modify the PATH variable of the process that will be loading the executable. Since your Java code probably shares a JVM (and hence a process) with the Tomcat executable, that will dictate which environment the PATH variable will need to be updated.
This is a Windows problem, not a Tomcat problem.
By default, Windows looks in %Path% for DLLs, which may not include the directory of the EXE file.
You can fix this by creating an empty file called process_video.exe.local in the same direcotry as the EXE ( i.e. c:\workspace )
You can also create a .manifest file, but this is a bit more complicated.