: Jordan Share
: It's been a while since I used xterm, but it seems like putty is a
: pretty close replacement. I tend to just open up another ssh session
: when I want another terminal. With pageant (key agent), this is a 3
: keystroke process for my most common ssh-targets.
But you are presuming that you have a WinDoze PC in front of you. Putty
is a GUI app which runs upon it, provides terminal simulation, and also
understands the ssh protocol(s). Whereas we were discussing what GUIs
to run on linux. (Well... I was.)
On linux, the functionality of a virtual terminal is provided by xterm
(or other similar apps), and the functionality of opening sessions with
the ssh protocol is provided by openSSH. IMO, this is a better way than
expecting every app that might want to have a virtual terminal capability
include code of its own to do so, and better than having to use putty's
virtual terminal when you might prefer another, just because that other
doesn't bundle an ssh protocol suite.
: I tried to find some info on wish, but I can't really tell how it
: would be used. Can you give examples of how you use it? Is it a
: shell that inherently has the ability to make windows on an xserver
: (vs. bash which doesn't) ?
Exactly. Here's a "hello world" program in wish.
#!/usr/bin/wish -f
pack [button .hello -text "hello world" -command exit]
That is, it creates a button displaying the text "hello world",
and when you click on the button, it terminates. You probably
didn't find references to wish because it's better known as "tcl/tk".
That is, the tcl scripting language coupled to the tk widget library.
There are also perl, python, and other bindings for tk. And there are
successor scripting environments for GNU (since Stallman didn't like
either tcl or tk).
You can also do things like
exec foo << [selection get] | xd &
which says, take the current X selection, pipe it through "foo",
and send the result to the "xd" program, which itself is a tcl
script which pops up a window to display what's on it's stdin.
So. Combining these things with some other pre-rwritten scripts,
you can provide an app like
#!/bin/sh
xe -t compare-snips -e '
newop tcl {exec cat >.snip1 << [s]}
newop tcl {exec cat >.snip2 << [s]}
newop tcl {i 1.0 [exec exitok diff .snip1 .snip2]\n\n\n\n}
'&
which allows you to select arbitrary text from any screens on X,
and quickly see their differences. And in this case, since the actual
diff command is made visible by this app, you could edit it to use
tkdiff (another wish script to provide GUI differencing) or to use
spiff (a diff which can be programmed to intelligently understand
the context of the inputs).
This differencing may sound trivial (hey, if it's on the screen, you can
just *look* at to see if it's different, right?), but the selection can
be huge ammounts of information (ie more than fits on the screen), and
the programs you are selecting the text from can be running on any host
anywhere on the net, or even inside vnc sessions to windows or mac
systems, without even having to have filesystems visible to each other.
I find wish a very, very fluid way to interact with unix pipelines.
You can look at http://tcl.sourceforge.net/, and perhaps more
usefully, http://tcl.sourceforge.net/faqs/, which presents some
introductory info on use of tk widgets from perl, scheme, python,
and so on, and about use of tcl/tk on windows and mac.
All this is, of course, a somewhat (ha! "drastically" more like)
difference in how GUI interactions and application packaging tends
to be done in Windows, but has some analogue in activeX or VB and such.
And again, I find it fits in with unix's notions of tool interaction
and specialization (as opposed to the traditional Windows integrated
monoliths) very well.
This is NOT to say it's for everybody or "better than Windows". It's
simply an example of a GUI that fits in with unixy things, and brings
value added to a GUI-bearing connection to a remote unix environment.
:: I am especially fond of wish as a method of integrating the unix
:: pipe-oriented world with X, by creating X-oriented pipe fittings, and
:: allowing selections and text widget content to be used as pipe
:: sources and sinks.
: OIC. That does sound interesting. Can you give me pointers (URLs) to
: more information on this? Or is that like asking "Can you give me
: more information on C?"
Well, hopefully the above gives a starting place. You can also look
at my own (somewhat crude by comparison to the way some folks polish
up apps, but still my) scripts, which give some hint at the way I
normally operate, which is very cut/paste centric,
at http://sheol.org/throopw/#tcl
Hmmmm, I am reminded I haven't updated it in a looooong time. But of
the information there, I still use the cross reference tool (though the
one there is quite old; the one I use has lots more features), and I
still use xe and xd regularly. Plus my mail reader, news reader, and
control panel, are all tcl/tk scripts. As I mentioned in passing
before, of the windows I've got open right now, 11 are tcl/tk windows, 2
are xterms, 1 is a vnc window, and 1 is a mozilla window. There are
more xterms and such inside the vnc window, of course. The "doing
presentations" one pre-dates the widespread use of powerpoint et al.
: What I was trying to get at was that there seem to be a lot of people
: who have windows desktops that want to VNC into their linux boxes just
: so they can have a GUI. And then what do they do with it? Open
: terminals, and/or browse the web. Which they could just do natively
: on windows, and not have to deal with the lag of VNC (even on a
: 100Mbit lan, it can still be laggy).
A reasonable point. The reasons I use vnc are 1) so I can continue to
interact with the tcl scripts I'm used to, and 2) so help with network
lag to remote sites (at some of which, X GUIs are required to run).
This may seem a paradox: I agree that VNC introduces a lag compared
with local operation, but I'm using it to *help* with a network lag
problem. Well, that's because Xvnc processes X events locally at the
remote site, and the pixel update, key, and mouse events are all handled
asyncronously. So, there's an inevitable lag, but VNC helps in this
case compared to actually sending X GUI events over the long haul.
(Though various X protocol compression tools help also, some say better.)
So all in all, yes, LOTS of my interactions with that remote site
occur inside ssh sessions, with the xterm windows local. But for
the cases I'm forced to run a GUI, or when I want to interact with
my own GUI scripts, use of vnc can speed up X interaction over that
distance by a factor of 10 (in a "chatty" GUI app, which most seem
to be these days).
Or put it this way. Let's say we've got "local" (the machine with
the keyboard and display you are sitting at) and "remote" (some machine
elsewhere, upon which you wish to run unixy apps). It's rather senseless
to do "ssh -f remote xterm" instead of "xterm -e ssh remote&", since the
major effective difference between the two is that the former is slower
and has more problems with network bandwidth/latency.
Hence, best to open a VT locally and ssh, rather than opening a VT remotely.
On the other hand, "ssh -f remote j-random-wish-script"
does still make some sense.
Wayne Throop [EMAIL PROTECTED]
_______________________________________________
VNC-List mailing list
[EMAIL PROTECTED]
http://www.realvnc.com/mailman/listinfo/vnc-list
