I am trying to call WMIC.EXE from Java to acquire battery information.
Here is the source in JavaX (an extended Java dialect): http://tinybrain.de/1001824
To see the equivalent Java source, look here (just the first 60 lines are important, really).
You can run this program with x30.jar - or by just compiling and running the Java source.
Basically it just produces a process (via a .bat file) and gets its output. The "backtick" function works fine with everything else, including stuff on Windows. Just not with WMIC - everything hangs.
The command run is this:
WMIC Path Win32_Battery Get EstimatedChargeRemaining /Format:List
Running this in the command prompt works fine... just not in Java. Java is weird with subprocesses, really.
Any ideas? Thanks...
I believe this is a duplicate of https://stackoverflow.com/a/13367685/3196753.
Quoting:
You will need to get and close your OutputStream before getting and using your InputStream. That will confirm to the process that you've started that you have finished sending input (in this case, no input) to the process.
p.getOutputStream().close();
Remember that on the Process object, getInputStream() input comes from the output stream of the process, and getOutputStream() output goes to the input stream of the process.
Related
I made a way to make my program, written in Java, update itself. The final JAR is wrapped in a EXE file, through Launch4j tool.
You need to know this piece of code:
System.getProperty("java.class.path").replaceAll("\\;\\.$", "")
gives me the actual path of the EXE. I tested it and it seems to be always working. This is important for the problem.
Now, basically the program pings a webpage and reads a series of values, which one of them is the latest version of the program. If it's greater, the program notifies the user for the update. So, the program downloads the remote data (updated EXE file) and stores them in the current running EXE file, whose filename is obtained through the method explained above. It works, but here comes the problem.
I could simply launch the downloaded EXE file and System.exit the current one, but I cannot do this, because my program works with smart cards: if two or more programs use the same smart cards, the new one won't work (I don't know why, I even restart the provider each time, but this is another story). So I prevent users from starting multiple istances of the program.
(My customers are not so smart to manually open the program each time they need it, so I needed to override the close button to make it stay in traybar, and wake up everytime it is needed. I even make it starts when Windows boots up).
So I have to close the current instance of the program, and launch again.
How I do this? I write a batch file which will basically look like this:
#echo off
taskkill /f /pid <pid of the exe program>
ping 127.0.0.1 -n 3 (this is a way to wait. I will eventually lower the waiting)
C:\Users\Mark\Desktop\program.exe (string generated by the method above. It should launch the program)
exit
Once written to disk, I execute it through Java:
Runtime.getRuntime().exec("cmd /c start " + batchFile.toString());
"batchFile" variable is a File object.
The problem is that the new downloaded program is not launched. A console window appears, shows the result of "taskkill" and "ping" (I will eventually mute them), but the program does not start. If I launch the batch file manually, it does.
Why? I really don't understand this behaviour.
Do you have any advice?
Thanks in advance!
TL;DR version:
The batch file executed by my Java program does not start the exe file written in it. Why?
I have the feeling you are trying to overwrite an executable file (EXE) that is currently running. AFAIK Windows locks such files and thus your updates should never happen.
To resolve your problem: I would split your application in two.
One part ensures the other part has the latest version, then executes that latest version.
For Java, something like this has been developed many years ago as WebStart technology, was marked as deprecated for Java 9 and removed thereafter. Meanwhile there is the project https://openwebstart.com/ that you might want to check out.
I built a GUI in JavaFX with FXML for running a bunch of different Python scripts. The Python scripts continuously collect data from a device and print it to the console as it's collected in a loop at anywhere from around 10 to 70 Hz depending on which script was being run, and they don't stop on their own.
I want the end-user to be able to click a button on my GUI which launches the scripts and lets them see the output. Currently, the best I have done was using Runtime.exec() with the command "cmd /c start cmd /k python some_script.py" which opens the windows command prompt, runs python some_script.py in it, and keeps the command prompt open so that you can see the output. The problem with this is that it only works on Windows (my OS) but I need to have universal OS support and that it relies on Java starting an external program which I hear is not very elegant.
I then tried to remedy this by executing the python some_script.py command in Java, capturing the process output with BufferedReader, creating a new JavaFX scene with just a TextArea in an AnchorPane to be a psuedo-Java-console and then calling .setText() on that TextArea to put the script output in it.
This kinda worked, but I ran into many problems in that the writing to the JavaFX console would jump in big chunks of several dozens of lines instead of writing to it line by line as the Python code was making Print() calls. Also, I got a bunch of NullPointerException and ArrayIndexOutOfBoundsException somewhat randomly in that Java would write a couple of hundred lines correctly but then throw those errors and freeze the program. I'm pretty sure both of these issues were due to having so much data at such high data rates which overflowed the BufferedReader buffer and/or the TextArea.setText() cache or something similar.
What I want to know is what approach I should take at this. I cannot migrate the Python code to Java since it relies on someone else's Python library to collect its data. Should I try to keep with the pseudo-Java-console idea and see if I can make that work? Should I go back to opening a command prompt window from Java and running the Python scripts and then add support for doing the same with Terminal in Mac and Linux? Is there a better approach I haven't thought of? Is the idea of having Java code call Python code and handle its output just disgusting and a horrible idea?
Please let me know if you would like to see any code (there is quite a lot) or if I can clarify anything, and I will try my best to respond quickly. Thank you!
My solution was to still call the Python code from the Java Processbuilder, but use the -u option like python -u scriptname.py to specify unbuffered Python output.
The Java program has to launch few prorams that are launched using a command promt(one of them is nginx). How could I handle and send commands to the program from my Java application?
I found this library http://commons.apache.org/proper/commons-cli/usage.html But I'm not sure how it helps..
I do NOT need code. I need an explanation on how things like these work.
Well keep in mind its never a nice solution.
You act like you would be on a command line so you execute Commands like you would on the shell. And does always depend on your platform.
You said you don't want code, I will give it to you anyway ;)
Runtime rt = Runtime.getRuntime();
Process pr = rt.exec("service nginx start");
That is done with plan java.
I highly advise you to use a script language for that. Thats just not Java.
additional info:
One thing to remember is to use the streams on process to send input and check output (from Process class)
abstract InputStream getErrorStream()
Returns the input stream connected to the error output of the subprocess.
abstract InputStream getInputStream()
Returns the input stream connected to the normal output of the subprocess.
abstract OutputStream getOutputStream()
Returns the output stream connected to the normal input of the subprocess.
If you need to execute shell commands, this can be achieved like so (This example uses bash as the executing process)
Process p = Runtime.getRuntime().exec(new String[]{"bash","-c","my_script.sh"});
You'll have to write your own script for this, but you don't even have to put it in a file. If you wanted to give user-like input to a command, keep in mind that you can pipe in the result of an echo to a command and it will act as a user typing that command. e.g
echo 1234 | pinTaker.sh;
This will effectively "type in" 1234 to the pinTaker script. This can also be used for things like typing in a password for ssh (Though this is not a good idea, it's a good example..)
I'm writing a shell script that's supposed to do the following.
- run a Java application that produces output
- run a shell command that produces output
- gather both outputs and send them out in an email
I have control of the source code of all the steps above.
Is there a best practice in gathering output from different sources? Should I redirect everything to a single temp file? Should I write different output to different files then concatenate them? What are the pros and cons of each approach?
If you don't worry about using just Java you could use the Runtime class to execute the shell command withing java (through exec) command, this will return you a Process object on which you have either getInputStream and getOutputStream so you will then be able to process the output of both the Java program and the shell command inside just one place and do whatever you want (keeping it in memory and directly send it by redirecting the outputstream to the inputstream of what you use to send the mail, with another exec) or saving it or whatever.
I'd favor using a second wrapper script which
calls the java program
calls the shell script
Captures output to a single file
reformats that output
suitable for mailing out Actually
does the mailing
Assuming you are using a unix shell, mailing/formatting and shell script calls are much simpler from the command line.
I am trying to write tests that interact with GDB but am having trouble capturing the output. I would like for a log file to be generated which looks like what would have been seen in a terminal had the test been executed by hand. GDB is proving to be very stubborn when it comes to capturing its output however.
I've been able to write Expect scripts which are able to interact with GDB and whose output can be redirected to a log file but I don't want to write my tests in TCL. I'm hoping to use Groovy, which is compatible with Java. For some reason with Perl's Expect and ExpectJ the program output always goes to the terminal and can't be redirected to a file.
I tried starting a GDB process from Java using ProcessBuilder and it mostly works but the output of print statements never appear on stdout and can't be captured. I thought if Expect works then I'd launch expect from Java and have it interact with GDB but in this case most of the program output is lost, never appearing in the stdout of the created process.
So my question is, how can I write a test in Groovy (Java would be fine as well) which interacts with GDB and can capture all of the output?
Pseudo-code:
process = "gdb -q".execute()
waitForPrompt()
send("file exec")
waitForPrompt()
send("run")
send("quit")
Log file:
(gdb) file exec
Reading symbols from exec...done.
(gdb) run
Starting program: exec
<... output ...>
Program exited normally.
(gdb) quit
One possibility is that the GDB output is being dumped on standard error and you are only capturing standard output. You should be able to fix this with a redirect, something like this I think:
process = "gdb -q 2&>1".execute()
A second guess is that it may be worth checking what "show interactive-mode" says in the working and non-working cases. If they differ try "set interactive-mode off" before you do anything else.
A third option is to use GDB's logging facility to write the log file ("set logging file " and "set logging on") and avoid having to capture the output yourself.
If your test involves using gdb to actually debug something, as opposed to testing gdb itself, you should probably look into using the gdb/mi interface.