I have created one automated test which is running a bat file. This abc.bat is generated using application assembler plug-in. Inside bat file, class path has been set and Java commands has been executing). On Linux, it's working fine, but on Windows environment, I am getting the error of:
The input line is too long
The path from which batch file is executing is C:\build\work\work1\abc\abc.bat. I have to keep this path, can't reduce it to like C:\build\abc.bat.
I am using process builder to run this abc.bat file.
public Test(Path wp, Path exe) throws IOException {
builder = new ProcessBuilder()
.directory(wp.toFile())
.command(wp.resolve(exe).toAbsolutePath().toString())
.redirectOutput(Redirect.INHERIT)
.redirectError(Redirect.INHERIT);
builder.start();
}
Path wp contains the path of C:\build\work\work1. (I am fetching this path from system environment variables). Path exe contains the path of abc\abc.bat
I have done some research and found out that long path issue can be fixed by changing group policy as shown below:
Hit the Windows key, type gpedit.msc and press Enter.
Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem
and enable win32 long paths.
This doesn't work for me. I am using Windows 10 enterprise, OS build is 14393.1593.
Another way is using Subst command. Manually I can map the drive using command prompt like:
C:\build> Subst X: “C:\build\work\work1”
X:\>abc\abc.bat
It works fine and there is no issue of "The input line is too long". Is this a good way to overcome this issue? and how to automate this using process builder?
According to Microsoft's docs "Maximum Path Length Limitation" that path is not long enough to hit the windows limit.
"The input line is too long" must include other characters, possibly parameters being passed to the bat file, or parameters being used to call that bat file.
To get a better picture of what is actually being executed, turn on command line process auditing in windows. Command line process auditing
If you are somehow hitting that limit, and parameter passing is happening, I suggest finding a different way to get to that information, possibly by saving to and reading from a file.
Related
I am using a .jar file, but unfortunatley as a black box, i.e. I do not know what exactly is in there nor how it all works.
I am sending commands to the Mac terminal from a Python script. I enter the following command:
java -jar jarfile.jar req_data /abs_path/to/required/data input path/to_my_/input/file.txt
This does what I need: analyses input using the 'black box' and creates and new file with analysis output. This new file is created in the folder where jarfile.jar is located.
I want to have this file put somewhere else upon creation.
I have tried using the > operator, specifying a path, e.g.:
java -jar jarfile.jar req_data /abs_path/to/required/data input path/to_my_/input/file.txt > /output/path/
this created a file in my desired location, but it was simply the message from Terminal, saying "The operation was carried out successfully" - the analysis results file was created in the same folder as before.
I tried %*> too, but it threw an error.
As a poor workaround I now have a function, which retrospectively finds and moves all the newly created files (analysis output) to my desired folder.
Is there a way to control the output files with the command line within the original command? Or is it something that is specified somewhere in my jar file? My problem is that editing it is not allowed.
I'm new to python. However, I may suggest to try few things, if they can work for you. Apology me, if does not work! I believe that you have already done the following step:
import subprocess
subprocess.call(['java', '-jar', 'Blender.jar'])
Like, if you have a properly configured jar path, then can run jar directly.
Secondly, look at the cwd parameter (is used for executable). Include a cwd param as x
def run_command(command, **x):
with subprocess.Popen(command,...., **x) as p:
for run_command specify the path of either the working directory (possibly it should be) or the full system path. I'm not sure, just try both.
for outputline in run_command(r'java -jar jarfilepath', cwd=r'workingdirpath', universal_newlines=True):
print(outputline, end='')
Alternatively, you can try to run command from the directory in which you wish to store output file. Try: run the popen as
subprocess.Popen(r'directory of running command', cwd=r'workingdir')
where workingdir could be your current directory path.
If it does not work, try without r'. If still does not work, try doubling slash in the path like (C:\\ abc\\def)
Issue Environment : Windows Server 2008 R2 Build 7601
I have a batch file SomeBatchFile.bat which uses %~dp0 to get the script location. But when it's executed on Windows Server 2008 R2 Build 7601 from a java program, its showing a buggy behavior.
Here is the behavior,
1) When executed like this
Process proc= Runtime.getRuntime().exec("c:\\full\\path\\SomeBatchFile.bat");
Keeping the SomeBatchFile.bat file in C:\full\path (essentially giving the actual full path), its returning the expected result c:\full\path\
2) But when executed like this
Process proc= Runtime.getRuntime().exec("SomeBatchFile.bat");
Keeping the SomeBatchFile.bat file in C:\Windows (essentially a location that is a part of environment variable PATH).This returns a wrong value instead of the BAT script location, its returning the java program location from where this script is called.
This is the script file I am using,
REM Just prints the script location to a file
set MY_HOME=%~dp0
echo %MY_HOME% >> test_out.txt
REM And some other business logic here ...
On Windows Server 2003, this is working absolutely fine.
Any idea why this happens like this ? Is this Java/Windows Bug ? And how to resolve this ?
If you are trying to launch script in a relative path, you should also give a try for these syntaxes:
Process proc= Runtime.getRuntime().exec(".\\SomeBatchFile.bat");
or
Process proc= Runtime.getRuntime().exec(".\SomeBatchFile.bat");
or
Process proc= Runtime.getRuntime().exec("./SomeBatchFile.bat");
One of the three should work.
I've tried to replicate your problem, and the only way I get to do it is if the batch file is executed quoted, that is, if when the java program invokes the cmd instance to handle the batch file execution, the batch file name is "SomeBatchFile.bat". You can try to execute your batch file from command line calling it with quotes to see the problem.
That is, a simple batch file as
#echo %~dp0
placed somewhere in the path (by example, c:\windows\test.bat), when called from command line, from any folder, without including the path to it, without quotes (just type test.bat), you will retrieve the correct folder. But, if the same test is done calling the file as "test.bat" you will retrieve the current folder
D:\>type c:\windows\test.bat
#echo %~dp0
D:\>
D:\>test.bat
C:\Windows\
D:\>"test.bat"
D:\
D:\>cd temp
D:\temp>test.bat
C:\Windows\
D:\temp>"test.bat"
D:\temp\
I don't have access to neither 2003 not 2008 to check, but "probably" the configuration on batch file invocation was changed.
Here (in this case the problem raised from c# and the reference is to the full batch file name, but it is the same problem) you will find why this happens.
If the batch file name does not contain spaces or special characters you can simply use something like
Runtime.getRuntime().exec("cmd.exe /c SomeBatchFile.bat")
Or, if you can not avoid the quotes in the file name, you can change the batch file to use a subroutine to obtain the required information
#echo off
setlocal enableextensions disabledelayedexpansion
call :getBatchFolder MY_HOME
echo %MY_HOME%
goto :eof
:getBatchFolder returnVar
set "%~1=%~dp0"
goto :eof
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.
By running the same command from the Eclipse and from the command line I get 2 different results:
With Eclipse everything works fine, however with the command line I get the following error message:
PosixThing.java:17: error: error while writing PosixThing: PosixThing.class (Permission denied)
This error message does not appear if I run "sudo javac PosixThing.java".
As it if was not strange enough, the same code with a different file located in the same directory (Desktop) does not give me any problem. (I am talking about mere txt files just to test the PosixFilePermissions function).
I checked the file permissions and everything is -rw -rw -rw As well as the others'. Do not know why it happens only with that specific file.
Running on Ubuntu 11.10 jdk 1.7.
Any suggestion to what it might be?
It sounds like a file / filesystem permissions problem of some kind:
Check the owner, group and permissions for the file, and all directories on the file pathname.
Check that you are running Eclipse and your command shell as the same effective user.
Check that you are not attempting to write to some kind of "funky" file system; e.g. a Windows file system mounted on Linux, or a FUSE file system of some kind.
If you've got SELinux enabled, check that's not causing the problem. (That's unlikely.)
It is also possible that you are running different releases / versions of Java in the two contexts, or even that Eclipse's file system cache is out of sync. (It is not clear to me what contexts the code is actually running in.)
what i wanted to do is to get all the installed applications in a computer and ihave decided to use the /output command of the command prompt using java. my code was working properly with this line of code in my computer:
Process proc = rt.exec("wmic /output:C:\\Users\\Public\\Documents\\list.csv product get name,version /format:csv ");
however, when i try to run the program in another computer, i encounter the "Invalid XSL format or file name" error. I tried reading other problems and i added this line of code before the code above:
proc2 = rt.exec("xcopy /y C:\\Windows\\System32\\wbem\\en-US\\*.xsl C:\\Windows\\System32\\");
but still nothing happened. the error is still there. anyone who can help me with this problem?
This is a bug in Windows 7 WMIC. When you use (for example) Dutch regional settings in an English Windows installation, WMIC searches for the xsl files inside C:\Windows\System32\wbem\nl-NL, instead of C:\Windows\System32\wbem\en-US where they are.
Workarounds:
Copy or move the C:\Windows\system32\wbem\en-US\*.xsl files up into the C:\Windows\system32\wbem\ folder.
Change your regional settings to match your Windows language version, log out and back in.
Specify the full path: WMIC process get /format:"%WINDIR%\System32\wbem\en-US\csv".