Charles Hargrave

+ Follow
since Apr 29, 2010
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Charles Hargrave

Twikki from "Buck Rogers" (80's TV show)
V.I.N.CENT from "The Black Hole"
Maximilian from "The Black Hole"
A robot from "Yo Gabba Gabba" (a kids show)
Cylon from "Battlestar Galactica" (1980's).
Cylon from "Battlestar Galactica" (2000's).
Maria from "Metropolis"
The robot from the "Fantastic Four" cartoon (late 70's, early 80's).
7 Ark 7 from "Battle of the Planets"
Robot dog from "Battle of the Planets" (I can't remember its name)
Robot versions of "Bill and Ted" from "Bill and Ted's Excellent Adventure"
Rover from "Planet 51" ?
10 years ago

naved momin wrote:
but still this is also not working ,
now what should be wrong

I have to agree with Joanne; you need to look at the 'cmd.exe' options.

You have 2 basic typos going on here. When you try to execute programs on any operating system through Java, you NEED to specify the complete file name (including the extension --> cmd.exe).

The other problem is your second argument in the array. It has a slash at the start. Based on previous replies above, it seems you're being recommended to give the 'cmd.exe' program to have a '/C' option, THEN the path to the .bat file. Basically, 3 arguments but you're giving it 2 and those have typos in them.

On Windows, if you get a return code 2 (for missing file), you'll need to fix the path to the file.

10 years ago

naved momin wrote:
thanks for the help charles..
what i m doing is quite simple but my problem is process gets hanged
let me rephrase it to you , i have a file ( this file has two statements first and second accept user input and echo that out using
so when i m executing that file through Runtime.exe() , i m getting the input ie
enter msg
but when i m entering the msg the process gets hanged up or even deadlock
so i m searching solution for that , let me give you the code so that you can understand what is going on and can even isolate problem ?


You're making Java run your program in an 'interactive' way as if someone is running FirstApp and entering commands directly. You have my apologies; I forgot to mention one other thing you needed to do when you make your program run this way.

Look at your Gobbler class's run() method at line 65 from your previous post. You need to add something to put in a newline (ENTER key / carriage return) after the command but before the flush() call at line 66. This is because your FirstApp is reading the showInputDialog String's value which does NOT have a newline (ENTER key / carriage return). It's like someone typed the answer but never hit the ENTER key, so the Process deadlocks.

Here's the only change I made to your code (at line 2 below):

I hope that helps,
10 years ago

BufferedReader br = new BufferedReader(new InputStreamReader(;

Just an observation, but that seems like a lot of text to expect a user to type in correctly to make your program do something.

It sounds like you want your Java program to start up some other program, then have your Java program pass the user's input (commands) to the other program while it is running? If that is what you meant, you need to get that Process instance's output stream (see ProcessBuilder.getOutputStream(); it'll connect to the STDIN of the other program) and write the user's commands to it. If you want to feed in the contents of a file to that program's STDIN, in Java 1.7, look at ProcessBuilder's redirectInput(File file) method.

You might not need to bring up another console window; you could use the same one that the Java program is using but you'll need to put in code to know when to quit sending input to the other program. If the other program is simple enough that it can use command line parameters to tell it what to do, I would go with that approach. With the command line parameter approach, you can check all of the parameters before you try to execute the other program.

Without knowing any details about what the program is supposed to do, I can't make any other recommendations for fear of misdirecting you. Good luck to you.

10 years ago

Arka Sharma wrote:All I'm trying to say is that seems to be some race condition or some synchronization problem.

I wouldn't call it a problem exactly. Sometimes you want to execute a program and let it run independently while your Java program continues to run; it depends on what that program does.

About synchronous / asynchronous operation, yes, you are right. Quoting from the the JDK API's ProcessBuilder page:

There is no requirement that a process represented by a Process object execute asynchronously or concurrently with respect to the Java process that owns the Process object.

If you need the program to run synchronously, it is possible. I've done this in the past but can't remember exactly how I did it; I'll have to get back to you on this. If you're not opposed to using API's for this, the Apache Commons Exec project might be useful to you, but its documentation assumes you know how Java executes other programs in detail. Executing other programs with Java can be tricky.

10 years ago

Jeff Verdegan wrote:

uniojn qoifazy wrote:
so , i think the problem is like you said , generates a lot of screen output, it can fill up the the stderr and stdout streams and cause the process to lock up.
am i wrong ? do you have any idea to solve the problem ?

As I already stated, try this:

I completely agree with Jeff, and yes, if the stderr and stdout streams fill up, it will cause the process to lock up.

Please read the article that Jeff put in his last post. We have both mentioned that article in our previous replies; that's how important it is to solving your problem. It explains the problem much better than I can and it is still very accurate and useful for more than 10 years since it was written. The only update it needs is to mention the ProcessBuilder class (it was added to the JDK a few years later).

If you are not using Java 1.7:
You will need to write a thread class to read and clear the data from the stdout and stderr streams. Look at Listing 4.5 on page 4 of the article that Jeff just posted. Look at the StreamGobbler class in that listing; that will read and clear data from any output stream you give it.

Now look at how the GoodWindowsExec class uses the StreamGobbler class in the main() at lines 60 - 70; that is very important to solving your problem.

If you are using Java 1.7:
The updates to the ProcessBuilder class can help you create a Process object with stream gobbling very easily. You could use ProcessBuilder's redirectError(File file) and redirectOutput(File file) methods; they redirect the stderr and stdout output streams to files. If you don't want to save the output to a file, specify the file names as '/dev/null' in UNIX (Linux) or 'NUL' in Windows so the output will be thrown away. With all of this detail, you should be able to fix your code.

10 years ago

Jeff Verdegan wrote:


We're not redirecting into -f 5. Those args are completely unrelated to the redirection. We're redirecting our input to come from the file specified by the "path" variable.

Java doesn't know or care anything about those args or the redirection. It just passes that all on to the /bin/sh command.

The structure looks correct, and since my similar /bin/ls command worked fine, and since his command works find without the -f 5, I have to guess that the -f 5 is either invalid to start with (hence my suggestion to try it directly on the command line) or else using -f 5 produces enough output on stdout or stderr to make it block.

Re: 'redirecting into -f 5', I don't know why I said that; I guess I was still waking up. Thanks for pointing that out so I wouldn't cause the OP to go down the wrong path.

As for the stdout and stderr streams, I agree. I suspect the '-f 5' causes 'flow-print' to write a lot of output and lock up the process (probably the stderr stream). I've worked with Java executing other programs a lot in the past and ignoring the stdout and stderr streams will cause you a lot of misery with 'chatty' programs.
10 years ago

uniojn qoifazy wrote:
hi Charles Hargrave ,
it's need to use the redirect (<) to input file ,

it's work in java , but when i add "-f 5" it's failed ,
so , i think Java class that can handle redirect (<) , but i don't know why can't add more parameter (-f 5 ) ??

I'm guessing that the redirect into the '-f 5' is treated differently through Java. You might want to try restructuring the command to see if you can work around it. I have no idea what the '-f 5' does for the 'flow-print' command.

As Jeff mentioned in his last reply, about gobbling up the stderr and stdout streams, I strongly recommend implementing the things in that article - especially for production code. Even though that Java article is old, it's been remarkably accurate for the past 10 or so years. If the 'flow-print' command's '-f' option generates a lot of screen output, it can fill up the the stderr and stdout streams and cause the process to lock up. The size of the stdout and stderr buffers is different for each OS.

Also another observation: if this is for a Java 1.7 environment, its ProcessBuilder class (a Process building class) has changed and has added methods to redirect output streams (stderr, stdout) and input streams (stdin) to File objects. For Java 1.7, to 'gobble' up streams (read them but discard the content), you might be able to create a File instance that points to "/dev/null" and use the ProcessBuilder instance's 'redirectOutput(File)' and 'redirectError(File)' methods. It's just an idea - I have not tested it.

10 years ago
At the risk of asking a silly question, is there any flow-print command line option for specifying an input file? Is it really required that you use the redirect?

If you have to pipe the file content into the command, there's probably a Java class that can handle that (never used it myself though).

I still think the easiest option would be to put the UNIX commands inside a UNIX shell script and have it accept a parameter for the input file's name (to be used in the UNIX command).

Oh well, it's late. If I think of anything else, I'll post again.
10 years ago

I don't have access to a UNIX server at the moment so I can't test your code but I saw something that stands out to me.

You are not consuming (reading) any content from the stderr output stream. If your process's stderr or stdout streams fill up with content, they will lock up your process; this causes problems for a LOT of people when they execute native code through Java.

In short, you need to create threads that will read the content from the stdout and stderr streams after you execute the command (rt.exec() line). Read this article and see page 4 for a good example about it (it's the StreamGobbler class).

As for how you set up the cmdlinux[], I'm not sure if the redirect (<) will cause you trouble in there or not. I usually don't run native programs through Java on a UNIX system but it might be worth it to put those commands into a shell script and make your Java code execute the shell script.

10 years ago

Winston Gutkowski wrote:

kerthi Joe wrote:But when i run this program am getting "The java class could not be loaded. java.lang.UnsatisfiedLinkError: D:\DLL_file\TRNSACTN.DLL: Can't find dependent libraries" .
Am i missing anything here.?

Well I've never done it myself, but it appears to be telling you that the library contains links to other dependant libraries that it can't find - presumably because you haven't told it where to look for them.


I agree with Winston.

Your TRNSACTN.DLL file might also need other DLL's too. Looking at the command line and such, it looks like you're on Windows. I'm going to suggest an approach to this. If you already have a Microsoft development tool of some kind on that PC (ex: Microsoft Visual C++), look for the 'depends.exe' program on your PC; it's a dependency walker tool. If you have it, use it to find out what DLL dependencies your program/DLL file has.

I'm going to guess that the original program was made through an IDE of some kind (MS Visual C++, Visual Studio, C#, Intel FORTRAN, etc) and was compiled in a manner where it expected the other redistributable files (DLL's) would already be on whatever PC you wanted to install the program to.

10 years ago