I am writing an android SSH Client. I have a terminal object that controls the view and an SSH object to send commands to the server.
My problem is that the terminal displays in color during all sessions but when an ncurses application opens, (tmux for example), the terminal displays in black and white.
I was able to find this: http://invisible-island.net/ncurses/ncurses.faq.html#white_black
I am not really sure what that means. Can anyone guide me on more documentation on this, or if there are any open source Java clients that support this feature. I am not really sure how to fix this.
Ok, so you launched the application without the TERM environmental variable set appropriately, and that meant that during the initialization routines the remote operating system believed it wasn't talking to a terminal that could support colors.
Now that you have it set correctly, your colors work. Congratulations! However, setting it inside the application is going to be quite a trick. This is because it needs to be set before you application launches. Otherwise, when the application launches, the low level libraries you are linking into will query the "environment" to see what kind of terminal it has, which determines what kind of terminal codes will be emitted by your application.
This all happens before you app launches; so, effectively, you can't really do it from your application. However, the real solution is a bit more interesting.
SSH makes very few assumptions about the display capabilities of the remote machine. The best way to "fix" this is to have the SSH client set the terminal type according to the SSH client's capabilities. Check your ssh client configuration to see if you can pass in a "better" terminal type.
In fact, having the host operating system assume the client's capabilities will create issues; however, demanding that every ssh client be configured to hand off it's terminal capabilities properly can be logistically impossible. So, you may want to strike a compromise. On the ssh server machine, try dropping a "wrapper script" to launch the application with a color terminal script. It would read something like
#!/bin/sh
TERM=xterm-256color
export TERM
exec launch-app "$#"
and be saved as launch-app-color or something similar.
Related
I have a java application and two different wireless network connections (wifi) on my desktop.
This is a desktop application, not android.
One method of this applicaiton works well with wifi1, second method works well with wifi2.
So far in order to use different methods I have to change wifi settings on my desktop manually.
Is there any way I could change wifi connection setting from the application programmatically ?
Java is a High-Level, Platform-Independent programming language. Network settings, and how you control them will depend on your Operating System, and to my knowledge there is no simple way to expose this in Java.
'
Luckily, some platform-dependent code mixed with Java can help you achieve the result you're after.
The Java
See the Runtime.exec() method, which allows you access to the Windows Command Line or the Mac/Linux Terminal.
The Windows (Adjust for other OS'es)
Now that we have access to the Command Line, we have to run the proper, platform-specific command. See this tutorial for Windows.
Note that it is not a good idea to modify a user's network settings (or anything else external to your application) without their consent.
Well what I am trying to do, in the long run, is to change some LAN properties when the an ethernet cable is connected to a computer.
I want to run my Java program each time a LAN network is detected. I found a couple questions as to how to do this in C++, but nothing related to Java, specifically. Would this just involve the way I distribute my final application? As in, I could use Jar2Exe Wizard to package my Java program as a Windows service and then just figure out how to run that at startup. But is there any way to do this within the Java program itself?
Don't know what your specific need is but you could try this. This shows how to run windows commands from inside java so you wont have to create an external batch file.
How to Execute Windows Commands Using Java - Change Network Settings
Also check out this answer which talks about retrieving network name in java. then you can combine both!
How to get the wifi network interface name in java
I have written a server in Java that allows clients connected to it to control the mouse and keyboard of the computer. To do this it uses the java.awt.Robot class.
I need this server to run in the background and start automatically. The first OS I am tackling this problem on is Debian based (Ubuntu 11.04) and a daemon seems like the obvious choice. The problem is that when the daemon is started during boot or during the installation of my debian package (whose postinst script starts it using /etc/init.d/pc-remote-server start) I get this error:
java.awt.AWTException: headless environment
at java.awt.Robot.<init>(Robot.java:97)
at com.se.pcremote.server.CommandExecuter.<init>(CommandExecuter.java:72)
at com.se.pcremote.server.PCRemoteServer.<init>(PCRemoteServer.java:215)
at com.se.pcremote.server.PCRemoteServer.main(PCRemoteServer.java:122)
Is there any way I can use the java.awt.Robot class from within a daemon process? Could I spawn a secondary process from the daemon process that is not a 'headless environment'? Or is there a better way for me to get a 'service' like result that does not have this limitation?
"Headless" means that this code needs access to a graphics environment, and it hasn't.
You can run in headless mode by supplying a system property which provides a crude implementation which gives just the basics for running applications, but which most likely cannot support Robot. Try it however first.
If you cannot do that, you need a graphics environment for your process. The usual way to do this is to run a VNC X-server as it doesn't require physical hardware, and then connect to it.
I assume, you must set the DISPLAY variable correctly (in the environment of the robot process at the time when the robot process is started) for this to work -- in your case you would need to specify a display in your DISPLAY variable which is created some time after the program is started. --
No idea whether this really works, but you could give it a try and report back here whether it works.
Alright, after doing some more research and trying some more options here is what I came up with:
Can I use java.awt.Robot from within a daemon? No.
Further down in my question I elaborated a little:
Is there any way I can use the java.awt.Robot class from within a daemon process? No. As above.
Could I spawn a secondary process from the daemon process that is not a 'headless environment'? Not that I could figure out. It was going to be a lot of work if I did do it anyway.
Or is there a better way for me to get a 'service' like result that does not have this limitation? Yes! Use the desktop environment! In my case since I was using Ubuntu the desktop environment was Gnome. Gnome has a Startup Applications feature that runs off .desktop files on a global and per-user basis as described here. They also provide information on the structure of these .desktop files here. I added a .desktop file to /etc/xdg/autostart (the global autostart folder) that ran my Java 'service' and it worked like a treat.
I want to facilate my client to run java program through UNIX command prompt using some shells. It'll look more effecient if they would be able to give input through some GUI. So it can be tested immedietely. I dont want prefer unix commands fro input.
Can somebody tell me how to run Java swing or applet programs in UNIX?
As Thompson mentioned, looking at Java Web Start could be a good idea.
Otherwise, if what you want is to execute, using a *NIX-like terminal, an application located on a remote host and have it rendered on your local display, then you need to do a few things:
you need a working X server on the local machine
you need to export the DISPLAY to the local machine (you can do this by setting up the DISPLAY environment variable on the remote system)
then you need to start your Java app from the command-line.
Hope this helps.
Here's an example of how to export your display over SSH.
Java programs use the X windows system (just like any other GUI on Unix). Assuming your X windows system is setup correctly, you should just open up a JFrame and do your GUI coding just like Windows.
Using the command prompt to launch a GUI is so last millennium. If you can distribute from a server, look into Java Web Start to provide the end-user with a simple and painless install.
Oh, and of course, follow Starkey's advice to throw a JFrame into the mix.
If you have an X-server installed locally, Putty can tunnel the X11-graphics generated by Linux Java back from the server to your local machine, and view it there.
If the above doesn't make sense to you, your next best bet is either running the Java code locally with Java Web Start (and code it to communicate back to the remote server) or run Servlets inside a Java Web Server running on the remote host.
In other words, GUI over a Putty connection is not something which is easily done.
I'm developing a Mac App in Java that logs into any one of our client's databases. My users want to have several copies of this program running so they can log into a couple clients at the same time, rather than logging out and logging back in.
How can I allow a user to open several copies of my App at once?
I'm using Eclipse to develop, and Jarbundler to make the app.
Edit: More Importantly, is there a way to do so in the code base, rather than have my user do something funky on their system? I'd rather just give them a 'Open New Window' menu item, then have them typing things into the Terminal.
You've probably already gotten enough code that you don't want to hear this, but you should really not be starting up two instances of the same application. There's a reason that you're finding it so difficult and that's because Apple doesn't want you to do it.
The OSX way of doing this is to use the Cocoa Document-based Application template in XCode. Apple Documentation: choosing a project.
This is something users are very accustomed to, and it works just fine. FTP programs, IRC clients, and many other types already use different "document" windows to point to different servers or channels. There's nothing inherently different about pointing to different databases.
Depending on how much code you've written, and how your application is designed, this may be pretty much impossible to implement without starting over. Developers who are encountering this problem during design phase, however, should definitely take Apple's advice.
From the Terminal, I can run
open -n -a appName.app
Then from Applescript, I can run
tell application "Terminal"
activaate
do script "open -n -a appName.app"
end tell
Then from Java, I can execute that script. Then, I can stuff that Java code into an Action. Then, stuff that action into a menu item that says "Open New Window".
That's what I'm going with for the moment. Now I just need to get the appName.
From the Terminal (or in a script wrapper):
/Applications/TextEdit.app/Contents/MacOS/TextEdit &
Something like that should work for you.
To do this in Java:
String[] cmd = { "/bin/sh", "-c", "[shell commmand goes here]" };
Process p = Runtime.getRuntime().exec (cmd);
If you are developing it in swing, you should just be able to instantiate the top Frame to create a new window.