So my question may be a little wide so I'll narrow it down here, I have been able to develop code that easily opens command prompt. My question is this, through say the IDE Eclipse, if I ran my program their that printed out HELLO!, how could I make it appear on the command prompt WITHOUT!!! actually accessing command prompt and running my code their?
More calarification? I need a line of code or method that when its executed it opens the command prompt and writes hello. Many would say why not have it run to say hello there but thats defeating the purpose of my task. To clarify further, if I was to run this in windows command prompt instead of eclipse, it would still open a new command prompt window and write hello in their acting as the System.out,
THANKS!
Disclaimer: I don't recommend this, just answering the question
You'd have to run Java in each console with an application that was listening for data from the controlling application (not going to get into how that communication could work, but sockets would be an obvious choice).
The listening application could then write to the console when it receives data from the controlling application - more trouble than it's worth imho
Related
Is it possible to create for only one process two different CLI (CommandLineInterface)?
I would like to have one CLI with my real program, and another CLI for a chat, so that i can send command to my program and send messages in the chat at the same time, and obviously have different views for the program and the chat.
(edit)
the program is a game and the chat is to make communication between all player, but when i start my program in eclipse, that program strat with only a console and here i would like to have two console in one there is the game with its action and state and in the other one i would like to have all the messages in the chat.
I know that i can build another process from zero and integrate it with process builder, but i would like to have all in one process.
If I assume that by CLI you mean the main terminal from where you execute your program, the answer is NO, regardless the OS.
There are couple of options to implement additional CLI interfaces in the same process:
listening on socket and waiting for client(s) to connect by e.g. telnet
opening a window that implements the CLI
under UNIX you can spawn e.g. a xterm and process its IO in your process
Under Linux or OSX, just open a new terminal window, and you will have an additional CLI to work with, and yes, you can try your program from those two different environments simultaneously and independently.
Under Windows, I couldn't say. You're probably using cygwin or something like that, so you should probably try to be a bit more specific in your question to get more attention.
I have a .jar runnable running on my server. When I run the file locally I am able to see its output via my IDE. Similarly I can connect via SSH and run the file and see the output, but when I close the session the JAR exits.
Is there any way to have my application continuously running and then tapping into the java applications output using a terminal service like SSH without having to stop/start the application.
Any help would be appreciated.
You can use either screen or nohup
What is happening is that when you close your SSH session, there is a hangup call made to the program.
You could use nohup. Nohup stands for "no hangup"
nohup java -jar myJar.jar > outputFile.txt
That would run the program in the backround and send all output to outputFile.txt. When you end your session it will continue running. You must use a kill command to kill it.
The second option is you could use screen which essentually creates a detachable "ghost session". When you run screen it looks like you are in a different ssh session. Then when you detach from screen, the processes continues in the backround. When you exit your ssh session, screen continues to run.
You simply ssh back into the server, and re-attach to your screen session, and like magic, your program is still running with all relevent output. A simple read on the man page should catch you up on how to do this.
man screen
Lastly, I decided to add this third option, not because its viable, but simply so you can understand that it is an option. (Some people would claim this is the only REAL option as it is what your SUPPOSED to do. Frankly I couldn't care less and think you should do whatever is the easiest to get to your goal.)
You can also edit your program to swallow the hangup signal. The program would then always run in the backround. You can then use
java -jar myJar.jar & > outputFile.com
The & tells the command to start a new process (aka run in the backround) and the > sends the output to a file. This is how normal server applications like tomcat or spring boot work. They simply swallow the hangup call.
I was recently trying to make a Swing GUI to send and receive commands from a third party command line program. I used the same procedure as used and working for Command Prompt, i.e., ProcessBuilder class to execute and then used BufferedReader to read responses from the program. I can surely mention it again that I could read some response, at least, from the Windows command prompt(sometimes I needed to use a Scanner in stead). When I used the same on this command line program,
It didn't show up
It didn't respond to either BufferedReader or Scanner.
I searched the internet and found a monotonous reply from it that executing the same procedure on them both is not the same thing because they are not the same things. I have not been able to complete my project till now, but I can sleep a little more at ease if I get to know what is the difference between them, their execution, aren't they same, is there any way in which we can actually bring them together and that my problem can be solved?
Most likely the program starts its own shell and does no longer interact with the original one. (You would notice this if the program opens a new window)
Or the program needs some specific library to be present to be able to interact with a shell (readline seems to be the case here) and that is not present in your Java Environment.
As a quick hack you might try to start bash (or cmd) that then starts the tool. bash and cmd have readline library. I don't have a windows ready here but as a guess just try to call your program like cmd urjtag.exe instead of just urjtag.exe that way you start a cmd process (with that you can interact) and that cmd starts the urjtag.exe where you already know that it can interact with.
Either way the problem lies in the way the program you want to call interacts with the shell and you should ask the authors of the program how it does and how you can connect to it.
From the UrJTAG documentation:
JTAG (IEEE 1149.1) is a serial interface for testing devices with
integrated circuits.
and
UrJTAG is a software package which enables working with JTAG-aware
(IEEE 1149.1) hardware devices (parts) and boards through a JTAG
adapter.
It is not a command prompt.
It is not meant to be used as a command prompt for generic programs.
So, as other monotonous responses have already told you, it and the windows command prompt are not the same thing, even though you seem to think they are. It has a very specific use-case as described in the documentation.
The windows command prompt is a special program which invokes specific executables and passes command line arguments to them in a specific way.
The java.exe executable is designed to understand this kind of invocation.
Since the UrJTAG executable it is not a generic command prompt, it doesn't do what the windows command prompt does, and so will not work for running Java programs like you want.
I am writing a java program that runs under unix.
It would like run forever. But when I start it from command line, I have to leave that window open always until the program stop.
Could anyone give me some idea about how can i run it at back end? Just start it from command line then I could close that command line.
Thank you very much.
If you don't want to "daemonize" it you can just use nohup:
$ nohup your-program &
$ exit
and your-program will continue to run in the background until it finishes.
You're asking about making your program a "daemon". Check out these links about daemonizing java programs, and this one about daemonizing any process in linux.
...Another option is to use the "screen" utility. Its a little tricky if you've never used it, but you can do things like launch a job in a terminal at work and easily reconnect to the same terminal from anywhere else to check on the status of the job. I use it for connecting to servers where I run long-running jobs. Without using screen my process would die if my local machine crashes, or the power goes out, or fire, etc.
that might be some kind of a silly question for you guys, but anyways: Is it possible to start the Java-console (as it is shown in Eclipse) parallel to the actual SWT-GUI?
The console contains an awful lot of debugging-information and I want my testers to be able to see what's currently going on. Obviously, they're not gonna use Eclipse...
Start your program using java instead of javaw.
Another way is that you abstract your logging mechanism so that it uses console if one is attached to the process (when started with java or within Eclipse) or puts the messages in a separate window the user can open if they want.
Run the application with the parameters:
-console -consoleLog