telnet
Rogier Schoenmakers
How can I find out if someone is running the java program on a telnet
program?
Thanks
Rogier.
Philip Niznik
>
> Hi,
>
> How can I find out if someone is running the java program on a telnet
> program?
ps -aux | grep java
pip
>
> Hi,
>
> How can I find out if someone is running the java program on a telnet
> program?
ps -aux | grep java
Joona I Palaste
> ps -aux | grep java
Which only works if you have telnetted into a Unix system. The telnet
protocol places no such restriction.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"A bee could, in effect, gather its junk. Llamas (no poor quadripeds) tune
and vow excitedly zooming."
- JIPsoft
pip
>
> pip <p...@costreduction.plseremove.screaming.net> scribbled the following:
> > Rogier Schoenmakers wrote:
> >>
> >> Hi,
> >>
> >> How can I find out if someone is running the java program on a telnet
> >> program?
>
> > ps -aux | grep java
>
> Which only works if you have telnetted into a Unix system. The telnet
> protocol places no such restriction.
Well, sometimes it's just better to guess what someone means as I don't
have esp. You could argue that the question make no sense, but that
would not be helpful.
Rogier Schoenmakers
What I'm trying to find out is if someone is running via telnet, so that the
Java program does never attempt to show nothing but text, so no graphical
components. It is because I use someone else's display to run the program, who
could be a mile away, and I try to avoid the program to show an unknown screen
on some computer all of a sudden, especially since most users won't have a
clue what is going on when they get into this situation. So the java program
needs to find out just before showing the JFrame whether it should start the
program in command line mode, or GUI mode.
So how can I let the java program find out if it's running via telnet? I don't
really understand what I can do using the "ps", and my experience & knowledge
of UNIX / telnet is limited. Any practical idea?
Thanks!
Rogier.
Joona I Palaste
> Hi,
> What I'm trying to find out is if someone is running via telnet, so that the
> Java program does never attempt to show nothing but text, so no graphical
> components. It is because I use someone else's display to run the program, who
> could be a mile away, and I try to avoid the program to show an unknown screen
> on some computer all of a sudden, especially since most users won't have a
> clue what is going on when they get into this situation. So the java program
> needs to find out just before showing the JFrame whether it should start the
> program in command line mode, or GUI mode.
> So how can I let the java program find out if it's running via telnet? I don't
> really understand what I can do using the "ps", and my experience & knowledge
> of UNIX / telnet is limited. Any practical idea?
Now I understand. You want to know from your Java program, if it's been
started from the system console, or over telnet. AFAIK there is no way
to find out that information.
Trying to display graphical components when no graphics are available
results in some kind of Exception, so it might be possible to try and
catch that Exception to see if your program is running in "text only"
mode.
This is not just a Java problem - I don't know of any way to determine
the starting place of a C program, either. If anyone over at
comp.unix.programmer can, please tell me.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"'I' is the most beautiful word in the world."
- John Nordberg
pip
>
> Hi,
>
> What I'm trying to find out is if someone is running via telnet, so that the
> Java program does never attempt to show nothing but text, so no graphical
> components. It is because I use someone else's display to run the program, who
> could be a mile away, and I try to avoid the program to show an unknown screen
> on some computer all of a sudden, especially since most users won't have a
> clue what is going on when they get into this situation. So the java program
> needs to find out just before showing the JFrame whether it should start the
> program in command line mode, or GUI mode.
>
> So how can I let the java program find out if it's running via telnet? I don't
> really understand what I can do using the "ps", and my experience & knowledge
> of UNIX / telnet is limited. Any practical idea?
>
> Thanks!
> Rogier.
This may seem simple, but how about using a run-time paramater to tell
your app that you don't want GUI? Joona is right in thinking that there
is no obvious way to detect this.
Patricia Shanahan
This is a good thing to provide anyway, if it makes sense at all for the
program to run without the GUI. There can be situtions in which a GUI
gets in the way - for example, it is easier to automate non-GUI control.
Patricia
Stephen Langhardt
that's a real question. If you connect to a unix system via telnet and try to open
a window (e.g. creating a Frame) you normally will get an error message like
'unable to open DISPLAY' unless the unix system has allowed others to open a
window. If you're comming from another unix system, you may redirect the window to
your own system by setting the DISPLAY environment variable (export
DISPLAY=<myComputer>:0.0 or setenv DISPLAY <myComputer:0.0 depending on the shell
your are using) and allowing the the unix system to open a window on your computer
(using xhost). If you come from a windows system you need a running X11 server
(e.g. Xwin32) to do the same.
To be sure not to open a window on a different computer do the following:
1. create a telnet session
2. set the DISPLAY to anything that doesn't exist (e.g. NONE).
3. start the java application
This application will get an Exception when creating a frame (I think when
invoking show() or setVisible(true) but I'm not sure, I've nerver tried it). So
catch this Exception and you know that it's a remote connection.
Hope this helps
Stephen
Rogier Schoenmakers schrieb:
Gordon Beaton
> What I'm trying to find out is if someone is running via telnet, so
> that the Java program does never attempt to show nothing but text,
> so no graphical components. It is because I use someone else's
> display to run the program, who could be a mile away, and I try to
> avoid the program to show an unknown screen on some computer all of
> a sudden, especially since most users won't have a clue what is
> going on when they get into this situation. So the java program
> needs to find out just before showing the JFrame whether it should
> start the program in command line mode, or GUI mode.
>
> So how can I let the java program find out if it's running via
> telnet? I don't really understand what I can do using the "ps", and
> my experience & knowledge of UNIX / telnet is limited. Any practical
> idea?
If it's simply the presence of a windowing environment that you're
trying to detect, the usual way is to look at the value of the DISPLAY
environment variable. If it's set, then a windowing environment is
available and the user has told you (via DISPLAY) where he wants any
windows to appear. If it's set in other cases, the user has a
misconfigured environment and the program, upon failing to open the
GUI, can report this at the command line.
It is DISPLAY that Java uses when it opens any windows in an X
environment, i.e. they don't simply open on the screen that happens to
be connected to the computer where the application is running, which I
think is the situation you are trying to avoid.
The next problem of course is checking the environment from Java, an
inconvenience at best that requires something like this:
String[] cmd = {"/bin/sh", "-c", "echo $DISPLAY" };
Process p = Runtime.getRuntime().exec(cmd);
BufferedReader br = new BufferedReader(
new InputStreamReader(p.getInputStream());
String display = br.readLine();
br.close();
However I still agree with the others that the user should be able to
use a command line argument to run in text-only mode, regardless of
whether DISPLAY is set or not.
/gordon
--
[ do not send me private copies of your followups ]
g o r d o n . b e a t o n @ e r i c s s o n . c o m
ericsson research
stockholm, sweden
Rogier Schoenmakers
Gordon Beaton wrote:
>
> If it's simply the presence of a windowing environment that you're
> trying to detect, the usual way is to look at the value of the DISPLAY
> environment variable. If it's set, then a windowing environment is
> available and the user has told you (via DISPLAY) where he wants any
> windows to appear. If it's set in other cases, the user has a
> misconfigured environment and the program, upon failing to open the
> GUI, can report this at the command line.
>
> It is DISPLAY that Java uses when it opens any windows in an X
> environment, i.e. they don't simply open on the screen that happens to
> be connected to the computer where the application is running, which I
> think is the situation you are trying to avoid.
>
Exactly...
>
> The next problem of course is checking the environment from Java, an
> inconvenience at best that requires something like this:
>
> String[] cmd = {"/bin/sh", "-c", "echo $DISPLAY" };
> Process p = Runtime.getRuntime().exec(cmd);
>
> BufferedReader br = new BufferedReader(
> new InputStreamReader(p.getInputStream());
>
> String display = br.readLine();
> br.close();
>
> However I still agree with the others that the user should be able to
> use a command line argument to run in text-only mode, regardless of
> whether DISPLAY is set or not.
Hi All,
thanks a lot for all the input. The command line arguments I had already
putten in place ;-)
The problem is indeed that I don't want the program to display a Frame on
some (unknown) screen, when a user runs it without any parameters on
telnet. The system variable DISPLAY is set to a screen away. The only
reason for running the graphical interface is for updating preferences, so
the program will not do anything useful this way without a "GUI", unless
parameters are used.
I don't see the reason why some user wants to run the application on a
telnet machine, and then having it displayed on a different monitor on a
different workstation (X) , though he could have run the application on X
in the first place. Or am I wrong?
Anyway, if I can get the program to find out if it's running on telnet, I
can always include an argument option so that it bypasses the telnet
check, and thus giving all the functionality ever wanted...
Anyway, running the app anywhere but telnet, it should start up with the
GUI, the user not needing any arguments.
I'm going to try your ideas, and I'll be back to you if it worked or not
;-)
Thanks again,
Rogier.
Gordon Beaton
> The problem is indeed that I don't want the program to display a
> Frame on some (unknown) screen, when a user runs it without any
> parameters on telnet. The system variable DISPLAY is set to a screen
> away.
DISPLAY should normally be set to the screen where the user is in fact
sitting, or not at all. However sometimes there is a valid reason for
setting the DISPLAY to a screen on a completely different host than
your own. And yes, there are misconfigured systems as well as users
who simply don't know better. When you telnet to a remote machine
DISPLAY does not get set automatically, it gets set by something in
the user's login scripts.
> I don't see the reason why some user wants to run the application on
> a telnet machine, and then having it displayed on a different
> monitor on a different workstation (X) , though he could have run
> the application on X in the first place. Or am I wrong?
Your use of X here is potentially confusing - I think (but I'm not
sure) that you're using it as a placeholder for a hostname, but it's
the name of the windowing system commonly used on Unix (and that's
what I'm referring to in the text below).
It is extremely common to run Unix applications (also graphical ones)
on other machines, but with DISPLAY set to the local screen. That's
the way that X works, and it's the reason for setting DISPLAY in the
first place. For example I currently have 13 windows open; 3 of them
are programs running on the local host, 6 of them are running on a
second machine, 3 on a third machine and 1 on a fourth machine. One of
the remote applications is netscape, which for various reasons I don't
want running on the local machine, and I wouldn't use it if I were
forced to run it locally or in text mode.
I would consider an application that didn't respect my DISPLAY setting
to be seriously broken, because its behaviour would be different from
virtually all other programs running under X.
Rogier Schoenmakers
yes, with 'X' I ment a host, sorry for that, but like I said, I'm not a
UNIX man (yet).
This is actually the error I get when running the Java program without the
DISPLAY variable set to (in this case) useless:0.0 :
Exception in thread "main" java.lang.InternalError: Can't connect to X11
window
server using ':0.0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at <Unloaded Method>
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName0(Compiled Code)
at java.lang.Class.forName(Compiled Code)
at
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvi
ronment.java:63)
at java.awt.Font.initializeFont(Font.java:262)
at java.awt.Font.<init>(Font.java:292)
etcetc...
If I run it on the local Unix machine (with a GUI), it does run perfectly,
but as you can see, not in Telnet. Maybe my solution of using the DISPLAY
variable to solve my problem isn't the right way to go, I don't know. But
it is a solution. And if it would have been easy and reliable finding out
if I was actually running on telnet, it would be a acceptable solution,
but now I'm not so sure.
Gordon, could you tell me what this does exactly (including sh)
String[] cmd = {"/bin/sh", "-c", "echo $DISPLAY" };
Process p = Runtime.getRuntime().exec(cmd);
Thanks again. If anyone has any other idea(s), please feel free to post
them!
Rogier.
Rich Gray
I don't really have an answer, but the real problem is detecting what
kind of display device is being used, not how the program is
being accessed.
Would it be possible to get ahold of the TERM environment variable?
If so, would it have a meaningful value?
On a related question, is there a curses like package for Java???
What would be great would be a package with things like checkboxes,
pull-down menus, etc that would look nice in either text mode or
full GUI.
Rich
mailto:richN...@plustechnologies.com (remove NO SPAM to reply)
Gordon Beaton
> This is actually the error I get when running the Java program
> without the DISPLAY variable set to (in this case) useless:0.0 :
>
> Exception in thread "main" java.lang.InternalError: Can't connect to
> X11 window server using ':0.0' as the value of the DISPLAY variable.
[...]
> If I run it on the local Unix machine (with a GUI), it does run
> perfectly, but as you can see, not in Telnet.
This problem is easily solved by setting up the remote environment to
correctly point at your local display, and setting the local display
to allow the remote process to connect.
On the remote host, set the DISPLAY variable to point to your local
host, something like this:
if your shell is bash, ksh etc:
export DISPLAY=somehostname:0.0
or, if your shell is csh, tcsh etc:
setenv DISPLAY somehostname:0.0
Now try running your program again, and see if the GUI comes up in the
right place.
At this point you might get a different error, this time complaining
that the client was not authorized to connect to your display. This is
not a big deal, because the X server normally prevents remote users
from connecting unless you tell it otherwise.
There are various ways to fix this part, depending on how the X server
is configured and also how your accounts are set up, i.e. do you have
the same home directory on the remote and local machines (do you see
the same files?)
The easiest way is to do the following, to let any clients on the
remote machine connect to your display. Type this on your local host:
xhost +remotehostname
Keep in mind that this is not a good permanent solution, because it
allows anyone at "remotehostname" to connect to your display. But test
it and see if you can start your program now. Afterwards, type
"xhost -" to remove the permission.
A better way is to transfer your X server's authorization key to your
account on the remote host. This shouldn't be necessary if you already
have the same home directory on both machines, because the file
containing the authorization keys is already be visible on both
machines. On the local host, type this:
xauth list
to see a list of authorization keys that you hold. One of them points
to the local display (if there are two, the one that doesn't say
"/unix" is the one you want). Triple-click on it to mark the whole
line.
Now on the remote machine, type "xauth add " and paste in the marked
line before pressing enter. Now your account on the remote machine
also has a key to use the local X server.
All of the above might sound complicated but really it isn't, and once
you understand how the DISPLAY and the authorization work together,
you can use the same technique to run any kind of program remotely
(but still use the local screen).
If you want to learn more about this, read the manpages for X (long)
and xauth, and see also question 42 in the comp.windows.x faq:
http://www.faqs.org/faqs/x-faq/part2/
> Gordon, could you tell me what this does exactly (including sh)
>
> String[] cmd = {"/bin/sh", "-c", "echo $DISPLAY" };
> Process p = Runtime.getRuntime().exec(cmd);
It starts a shell that does "echo $DISPLAY" so that your Java program
can read the value of the environment variable.
Thomas Dickey
> On a related question, is there a curses like package for Java???
only JNI, afaik - an example is
http://www.pitman.co.za/projects/charva/index.html
--
Thomas E. Dickey <dic...@radix.net> <dic...@herndon4.his.com>
http://dickey.his.com
ftp://dickey.his.com
Gordon Beaton
> In comp.unix.programmer Rich Gray <richN...@plustechnologies.com> wrote:
>
> > On a related question, is there a curses like package for Java???
> only JNI, afaik - an example is
>
> http://www.pitman.co.za/projects/charva/index.html
Here are a couple more (also JNI):
http://www.connix.com/~psantoro/jnicurses/jnicurses.html
http://www.bmsi.com/tuipeer/
And this, which isn't a curses package but give you access readline
command editing and history, which sometimes is enough:
http://www.bablokb.de/java/readline.html
Rogier Schoenmakers
before I kick someone of his workstation ;-)
Gordon Beaton
> Does this all work on a machine with NT running telnet? (I'm asking
> this before I kick someone of his workstation ;-)
I assume that the remote machine is running Unix since you can telnet
into it.
If your local machine is NT and you are running an X server on it then
it will work, although the commands to allow the remote application to
connect to the display will be different. In this case you should
consult the documentation for your X server.
If the local machine is NT and it isn't running an X server, then the
Java application on the remote won't be able to connect to the local
display anyway. In this case, make sure that the DISPLAY variable is
not set on the remote.
Rogier Schoenmakers
Rogier.
Victor Wagner
: Rogier Schoenmakers <rog...@xilinx.com> scribbled the following:
:> Hi,
: This is not just a Java problem - I don't know of any way to determine
: the starting place of a C program, either. If anyone over at
: comp.unix.programmer can, please tell me.
But there are the ways. There is shell command tty, which lets you
to determine whether your controlling terminal is console or pseudo tty.
There is shell command w which displays list of users currently logged
in and shows which machine they are logged from.
There is program sudo, which makes decisions to allow or deny access
based (among other things) on the host current user is logged in from.
Its source is freely available, so you can download and study it.
--
My apologies if I sound angry. I feel like I'm talking to a void.
-- Avery Pennarun