“UNC paths are not supported” error in “SVN Info” command - java

I am trying to run the command:
cmd.exe /X /C "svn --non-interactive info <file name>
by using commandline.class from the API (org.codehaus.plexus.util.cli) which is called by
SVNInfoCommand.class(org.apache.maven.scm.provider.svn.svnexe.command.info)
It works fine when I pass a filename which exists in C:\ drive.
But it returns the following error when I pass a filename which exists in shared location or network drive. Error: "UNC paths are not supported. Defaulting to Windows directory. svn: '.' is not a working copy"
Current working directory is being set using the method setWorkingDirectory( String path ), but I suspect working directory is not being set when we use shared locations(UNC Paths).
EX: \Test_Location\Test_File
This command works fine when I pass the “absolute path” of filename located in shared drive.
(\Test_Location\Test_File)
Please let me know why we get this error when we use UNC paths even after setting the working directory.

By default, the Windows command processor (cmd.exe) doesn't support UNC paths.
You can alter this behavior by adding a dedicated registry key, as described in Microsoft KB 156276.
Alternatively, you can map your UNC path to a standard drive letter, and then use that.

Related

Hadoop '-classpath' is not recognized as an internal or external command, operable program or batch file

I'm trying to install hadoop on my computer (Windows 10, 64 bit) but when I go to test if it installed, I keep getting the error:
'-classpath' is not recognized as an internal or external command,
operable program or batch file.
I have no idea why this is happening. I thought my system variables were set correctly but apparently not. I was just wondering if anyone could tell me what is going on with this -classpath stuff. Below is a snapshot of the error
enter image description here
And here are further images of my stem and path variables. As well as a snapshot of the bin directory in hadoop.
enter image description here
enter image description here
For me the problem was that %JAVA_HOME% included a space in the path C:\Program Files\Java\jdk1.8.0_191. After changing it to C:\Progra~1\Java\jdk1.8.0_191 it started to work.
So check that all the relevant env variables (Java, Hadoop) are defined without spaces.
You have problem with your path . Your path contains some spaces. Just remove the spaces .
Suppose any folder name in your path is like
Hadoop folder
You can clearly see the space in your folder name in your path so you just rename the folder name as
Hadoopfolder
Or
Hadoop-folder
Just rename it everywhere and try to install it again .

Java:System cannot execute the specified program

The javac -version gives the proper version of javac.
But, java -version gives the error as
"System cannot execute the specified program"
The PATH variable is set properly as "C:\Program Files\Java\jdk1.8.0_102\bin"
It is not programming question. But you have to add your %JRE_HOME%\bin to PATH variable
That specific error is likely related to the evaluation of a symlink to the java executables.
Normally, an invalid executable name (meaning, one that is not found in the path) will yield an error with the following text:
'javax' is not recognized as an internal or external command, operable program or batch file.
As you are receiving a different error, this is likely not your issue.
When java is installed on a Windows PC, the installer creates a directory (usually with the path of C:\ProgramData\Oracle\Java\javapath, and places 3 symlinks in it. They are for java.exe, javaw.exe, and javaws.exe. This prevents your path from becoming too cluttered with potentially colliding executable names.
javac.exe (and keytool, etc) work because you added your JRE/JDK bin folder to your PATH. But why does doesn't java/javaw/javaws work? Because it finds the javapath directory above first (PATH is searched left to right). You can see this issue by using the where command. For example:
C:\>where java
C:\ProgramData\Oracle\Java\javapath\java.exe
C:\Program Files (x86)\Java\jre1.8.0_31\bin\java.exe
C:\>where keytool
C:\Program Files (x86)\Java\jre1.8.0_31\bin\keytool.exe
This would be an alright situation, except that the javapath\java.exe symlink is not working, a policy is disallowing its execution, or its path is wrong.
From an administrative command prompt, run the following command. The result should be similar to below
C:\>fsutil behavior query SymlinkEvaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are disabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.
If "Local to local" symbolic links are disabled, that is your problem (as this settings prevents the following reparse points)
You can enable them with the following command:
fsutil behavior set SymlinkEvaluation L2L:1
Double check that the setting changed with the query subcommand. You do not have to restart for this setting to take effect.
If that does not resolve your issue, ensure that the destination of the symlink exists. Try running it via Explorer; a console dialog should pop up then close. If it does not, an easy way to confirm it's correct is to right click the symlink and select "Open File Location". If a error dialog appears stating 'Problem with Shortcut: The item 'java.exe' that this shortcut refers to has been changed or moved [...]', then the path is incorrect.
You can see what the path is set to via the 'Shortcut' tab in the properties of the symlink. If the path is wrong, you can delete the symlink and then recreate it via the mklink command. Delete the symlink and then from an administrative command prompt, run the following; be sure to replace the second path with that of your actual JRE/JDK!
mklink C:\ProgramData\Oracle\Java\javapath\java.exe "C:\Program Files (x86)\Java\jre1.8.0_91\bin\java.exe"
At that point, run 'java' from the command line and see if it works.
If it does not, navigate to your desired java.exe, view its file properties, and ensure there is no "Unblock" button available on the bottom. If there is, click it.
you need to set the PATH variable(jre/bin/) in environment settings.
in cmd , set PATH ="C:/ProgramFiles/java/jre*/bin"

Finding program's own location (path) [duplicate]

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

bash: jar: command not found

I'm using Jenkins to deploy the build.
We need to extract files from a .war into some directory.
We have an .xml file which includes commands to extract the files from the .war file and start the server.
The build is being created properly but the .war extraction is not happening and the destination folder is being left empty. The Jenkins Console shows the following output:
[sshexec] bash: jar: command not found
As read from other answers, I have set the PATH properly in .bashrc or in .profile but I'm still facing the same issue.
Install Java devel as follows:
yum install java-devel
To be specific, JAVA bin directory is not in your PATH variable. Add it to PATH variable. In order to search the executables, the OS need to have a list of directories to look up. So, Add the directory which contains 'jartool in thePATH` environment variable
Note : For Windows, Path separator is (;) and for Unix-like OS, Path separator is (:)
The "[sshexec]" tells me you are using some Jenkins plugin to execute a command on a remote host.
This usually means Jenkins executes this (or an equivalent thing by implementing the SSH protocol natively):
ssh user#remotehost 'jar arg1 arg2...'
What happens here is the sshd daemon on the remote host will execute the default shell of the user and ask the shell to execute the command line. The shell is typically not executed as a "login shell", meaning the shell will skip the initialization steps that login shells normally do when the user logs in interactively.
You can study man (name of your shell) to see exactly what the difference is between a shell executed with -l option and one executed without it. In the case of bash it essentially means .profile and .bashrc will not be executed, so any PATH modifications you might have there will not take place.
I think your best bet is to provide the full path to the jar command when you want to execute it.
As you are executing the command on remote host so, it will invoke the new Shell on the remote host. The PATH which you have set in the current host .bashrc file will not make any difference. Instead if you set the PATH for Java in remote host's .bashrc things should work else if you are running any script then mention the complete path for JAR like /usr/jdk64/jdk1.8.0_40/bin/jar -tf /tmp/jars/abc.jar while invoking the command on remote host.
Two ways to do:
export PATH=$PATH:/usr/jdk64/jdk1.8.0_40/bin ---> in remote host's .bashrc
/usr/jdk64/jdk1.8.0_40/bin/jar -tf /tmp/jars/abc.jar --> invoke the jar command with complete path for JAR from remote host.

Executing a batch file from Java does not give access to full PATH

I am writing a Java utility that executes a batch file to generate a PDF using the DITA toolkit and Apache FOP. It finishes by using pdftk to watermark the front page. If I execute the batch file in Windows using Start>CMD, this line in the batch file works:
pdftk "%DITA_OUTPUT%book.pdf" multibackground C:\doc_build_system\watermark.pdf output "%DITA_OUTPUT%external.pdf" compress verbose
When I execute the batch file by Runtime.exec() the same line fails.
The cause of the failure is that the PATH variable is incomplete when executed through Java. It should have an entry like:
C:\Program Files (x86)\PDFtk Server\bin\
...but it does not. I tried to force execution through CMD by invoking runtime.exec("cmd /c batchfile.bat") (rather than just directly invoking the batchfile) but this also had no effect.
Any ideas?
You can try to set the path manualy before your start your java in cmd:
start cmd.exe. Then type:
SET PATH=%PATH%;C:\Program Files (x86)\PDFtk Server\bin
java MyProgram
If that is working you have to check if edited the right PATH variable. In Windows you can have different PATH environment variables for each user, plus there is one system-wide PATH variable (see screenshot) that will always be applied and combined with the user variables.
e.g. if you did set the path for your user and then use administrator for elevated rights to execute java, the PATH won't be set properly.
Make sure to use the system variable.
Also make sure to restart windows after you did edit the variable, because open applications and consoles will usually only fetch environment variables once at start up.
Just take pathman from the Windows Server 2003 Resource Kit:
USAGE:
/as path[;path[;path ...]]
Adds the semicolon-separated paths to the system path.
/au path[;path[;path ...]]
Adds the semicolon-separated paths to the user path.
/rs path[;path[;path ...]]
Removes the semicolon-separated paths from the system path.
/ru path[;path[;path ...]]
Removes the semicolon-separated paths from the user path.

Categories