I am trying to install WFDB Toolbox system-unspecifically in my systems (Ubuntu Linux 64bt/OS X El Capitan/Windows 10 education). I need to get the Matlab Path i.e. set in /usr/local/MATLAB/R2016a/toolbox/local/pathdef.m by Java/Matlab own means. However, I did not find an approach for that.
Pseudocode
matlabpath=char(java.lang.System.getProperty('user.path'));
where I tried in path also matlabpath.
I have specific locations where I keep sufficient permissions for Matlab.
I need the approach i.e. user.path such that I know where I need to keep sufficient privileges.
Warning that I get when installing WFDB in Ubuntu Linux 64 bit and Matlab 2016a, which is a complication of not being able to manage the path non-system-specifically
Warning: Unable to save path to file '/usr/local/MATLAB/R2016a/toolbox/local/pathdef.m'. You
can save your path to a different location by calling SAVEPATH with an input argument that
specifies the full path. For MATLAB to use that path in future sessions, save the path to
'pathdef.m' in your MATLAB startup folder.
> In savepath (line 169)
Java would be the best solution for this, but Matlab's own solution is ok too.
How can you get Matlab's path by Java/Matlab?
The "MATLAB Startup Folder" can mean many things depending upon the user's configuration as well as the operating system.
The Mathworks has a whole page about this here.
One way is to ensure that the startup folder is the same as the userpath (how you do this depends on your OS so see the link above). Then you can access that from within MATLAB using the userpath command.
folder = userpath
If you're on Linux, you can ensure that the userpath is used as the Startup Folder by following this excerpt from the link above.
Default Folder on Linux Platforms
On Linux® platforms, the default startup folder is the folder from which you started MATLAB.
To specify the userpath as the startup folder, set the value of the environment variable MATLAB_USE_USERWORK to 1 before startup. By default, userpath is userhome/Documents/MATLAB, and MATLAB automatically adds the userpath folder to the top of the search path upon startup. To specify a different folder for userpath, and for other options, use the MATLAB userpath function.
There is another option (on newer versions of MATLAB) that would allow the user to set their startup path to whatever they want and you still be able to determine it.
Since R2014b, users can specify the initial working path in the preferences (MATLAB General -> Initial Working Folder). You can check if the user has specified a custom initial working directory using the following commands
settings = Settings;
folder = settings.matlab.workingfolder.InitialWorkingFolder;
Disclaimer: This functionality was discovered by looking at MATLAB's own matlabrc file and while there is some documentation for Settings it's likely not officially supported, so use at your own risk.
Related
I have a software tool that I am working on in Java. It will be deployed to both Windows and Linux. I am at the phase where I am trying to determine the best course of action for saving the user's installation directory (where i will store all external files). Ideally I want the user to be able to move the program to any directory they choose (even after installation) and it will still be able to find the installation directory.
I have considered using environment variables to save the path but I am not sure if that is the best practice.
What is the standard practice for saving a path to an installation directory on Linux and Windows? (I am open to making different install logic for each OS)
Edit
After a bit more research, I have found that the /etc folder for linux is where I should store data and the Registry for windows. Can anyone confirm this?
In Windows, registry works great. Here's an example from a product I use (evo5.0 with eurovoiceHMP):
Locations of config and logging folders can be configured manually via the registry,
eurovoiceHMP and evo5.0 then "find" these folders under registry:
HKLM/Software/eurovoice
Specific registry setting examples:
HKLM/Software/eurovoice/HMP:
evoHMPLicencePath C:\ProgramData\eurovoice\HMP\Config\Licences.txt
InstallPath E:\hmpTest
HKLM/Software/eurovoice/evo50:
evo50SystemVoiceFilesDir C:\TeleSage\sysvox
InstallPath C:\Program Files\evo5.0
evo50LogDir C:\TeleSage\Logs
We are using YAJSW to wrap our Java application as a Windows Service. While testing workstation images there is a warning from the corporate McAfee Antivirus because on launching the service, the jnidispatch.dll is copied from the jna-4.1.0.jar to a new name in a temporary folder.
Adding the dll signature to the antivirus rules prevents a showstopping error but a severe warning pops up every time.
We tried copying the jnidispath.dll to C:\DLLfolder and adding to wrapper.conf the line:
wrapper.java.additional.4 = -Djna.boot.library.path=C:/DLLfolder/
We then added C:\DLLfolder to the Windows System %PATH% and rebooted Windows.
However when monitoring the Windows Service start, we can still see the DLL being extracted from the Jar instead and the antivirus complains.
The comments in the YAJSW code native.java say:
When JNA classes are loaded, the native shared library (jnidispatch) is
loaded as well. An attempt is made to load it from the any paths defined
in <code>jna.boot.library.path</code> (if defined), then the system library
path using {#link System#loadLibrary}, unless <code>jna.nosys=true</code>.
If not found, the appropriate library will be extracted from the class path
(into a temporary directory if found within a jar file) and loaded from
there, unless <code>jna.noclasspath=true</code>.
What step are we missing?
I confirm we resolved with the following actions:
1) added -Djna.nounpack=true to wrapper.conf
2) deleted the 2 jnidispatch.dll 32-bit and 64-bit DLLs from the JAR
3) Placed the DLLs on the Windows path
Please note to install the Windows Service, the jnidispatch.dll is required.
Big thanks to technomage!
Say I have JNI.dll. It depends on native.dll. Now my Java application calls System.loadLibrary("JNI").
Will the following folder layout work?
MainFolder
|--main.exe
|--SubFolder
|--JNI.dll
|--native.dll
My guess is, there are 2 levels of dependency resolution.
[Level 1]:
System.loadLibrary("JNI") uses JVM property java.library.path to locate JNI.dll.
[Level 2]:
JNI.dll relies on Windows system mechanism to locate native.dll.
Is this correct?
If I set %_JAVA_OPTIONS% as -Djava.library.path=MainFolder\SubFolder, I think it can cover the search for JNI.dll. But will it cover the search for native.dll, too?
ADD 1
It seems my guess of 2 levels got confirmed from here: How to add native library to "java.library.path" with Eclipse launch (instead of overriding it)
See comment by kevin cline. But the mentioned solution with LD_LIBRARY_PATH environment variable only applies to Linux.
ADD 2
I think I didn't make my question clear. Let me put it this way.
My confusion is: the JNI.dll depends on native.dll. Both of them are not in the main.exe's current working directory. Actually they are in a sub folder of CWD.
If I run main.exe directly, I just need to set the java.library.path = <other path>\MainFolder\SubFolder. Both DLL are found correctly.
But if I run my project from Eclipse, besides setting the java.library.path, I have to put the "\MainFolder\SubFolder" in the %PATH% environment variable.
I just don't know why Eclipse is so different.
1)It searches in the current Directory.
2)System folder typically C:\Windows\System32 (use CSIDL_SYSTEM with shgetspecialfolderpath() to get the rigth folder on the given system)
3)Windows folder (C:\Windows )(CSIDL_WINDOWS with shgetspecialfolderpath() to get the right folder on the given system)
4)All the folders listed under PAth environmnet variable
A similar link: Must I place all dependent DLLs into the JDK's bin folder?
Inspired by this thread:System versus user PATH environmental variable...winmerge works only if I add the path to the user PATH
I start to wonder maybe my User %Path% is too long. So I moved the folder path containing my dependent DLL from the end of User %PATH% to the beginning. It works now!
At first, I conclude that one who implemented the Windows' DLL lookup algorithm has some truncation issue. And I almost consider it as another annoying Windows Bug.
But I wrote another Windows application which has similar DLL dependencies to confirm my guess. That application works fine! So I have to review my conclusion.
I checked my User %PATH% entry one by one, and place the folder to each possible location. And finally, I find the root cause.
I have a C:\MinGW\bin entry in User %PATH%, which happens to contain a
libstdc++-6.dll (977KB) but unfortunately, which isn't compatible
with the one I need (825KB). It only works if I place my folder before MinGW.
Now this issue seems resolved. But another one comes up, do I need to switch back and forth if I want to use both my DLL and the MinGW?
I have a Java desktop application that I have written.
During the execution I create folders and files at the default path name defined in the system.
Java.io.files clearly states: By default the classes in the java.io package always resolve relative pathnames against the current user directory. This directory is named by the system property user.dir, and is typically the directory in which the Java virtual machine was invoked.
In addition, I am using IzPack to enable installation and shortcuts creation.
When I'm running my application on my XP computer, after the installation I get a desktop shortcut, and the mentioned files and folders creation are at the location that Izpack installed the Jar. which is the expected behavior.
But when I test this out on a Vista machine, the folders and files are created on the desktop! even though the Jar is at the correct location (c:\program files.. etc).
I want those files to be created at the same folder the Jar is in, and most certainly not at the desktop.
Can anyone give me any insights on what is going on here?
It's because in Vista/Seven, writing to the Program Files folder requires administrative interference, so JVM looks for the next writable location as a fallback: the Desktop (or the User Documents directory). You can easily determine the User home directory in a unified manner on all OSs, though, which is way better than just letting the JVM pick a -- hopefully -- reasonable location.
Since this is a known bug for JVM on Windows, if that doesn't help, the fallback is to check the System Environment variable USERPROFILE which should point at the correct user home folder:
String userHome = System.getenv("USERPROFILE");
I have a NetBeans RCP application that's currently working on Windows and I'm trying to make Linux compatible. The application creates folders and files and modify files as well.
It works fine on Windows without any modification but on Ubuntu it fails creating folders during start up. I know it's a permission issue.
What are my options?
Can the application itself assign the permissions it needs like by running a script using ProcessBuilder?
Thanks in advance!
It all depends on who you are when running the process on Ubuntu, and the path of the folders that you're trying to create. Does this user have permissions to create the folders in that directory? What sort of data are you writing out to disk? Can you use a platform neutral mechanism thats user oriented, like Java Preferences or perhaps:
System.getProperty("user.home")
-or-
System.getProperty("java.io.tmpdir")?
You either need to create required folders as part of a setup process or restrict your IO to folders you have access to (the users home and the temp folder). Notice that on Linux there are standard locations where many folders should be placed and that administrators will frown upon applications that do not follow these standards.
Can you tell what files/folders you need for what purpose?
Looks like the cause of the problem is the difference in path delimiter between Windows and Linux. On linux you should use normal slashes. The error mentions the path:
/home/javier\marauroa.trace.db
As the \ is not a path delimiter but the escape character it is trying to create a file in the folder /home where it does not have permissions.
The path should be:
/home/javier/marauroa.trace.db
You might want to consider putting your apps files in a subfolder called .yourappname so then it would become
/home/javier/.yourappname/marauroa.trace.db
This is what many unix applications do and hide it in normal file listings. To get the path seperator for the system your application is running on you can use the following static field:
java.io.File.seperator