:: As I understand things "xterm" at command line should start an
:: Xterminal and "xclock" should start xterm with clock.
: It looks like you're trying to start xterm from console (non X) mode.
More fundamental: given the discussion and list of things attempted
in the original post, I think there's a basic misconception involved.
This is perhaps due to the basic naming infelicity involved in
the fact that an Xterminal and xterm are only vaguely related;
they certainly aren't the same thing, nor does either of them
directly start the other.
Let's start from the bottom. You have the X server, the executable
often actually called "X", or at least a wrapper around the executable
is called "X". The server is rarely started by itself; it is usually
started by the command "startx", or possibly xinit. Another common way
it gets started is by xdm, the display manager, which then puts up a
GUI login prompt. Starting the server is what creates the display; until
you've done it, you'll get the "can't open display: :0" message. Note
well: setting the DISPLAY variable doesn't start the server, it merely
tells X apps which server they should be displaying on.
( Note: some people think the X server is the client, and all the apps
are servers. That's not true; the X server offers access to the
display, keyboard, and mouse hardware as a service; the apps are
all clients of this service. )
Now. In linux, you can simply say "startx" from the command line,
and it'll start the server, and start a few initial applications,
including the window manager (note: the window manager is "just"
another X application). Given linux's virtual terminals and they
way they work, you can also say "xdm" from a command line as root,
and you'll get a GUI login window.
The "few initial applications" that get started are usually started
by running a user-supplied shell script, $HOME/.xsession or $HOME/.xinitrc,
depending on exactly how it gets started... (I like to link both of those to
the same file, so I don't have to wonder which one I'll get).
Now, once the server is started, you can start applications from anywhere
(modulo permissions) by setting DISPLAY, or using the -display command line
option for those apps (ie, most of them) that recognize it. But mostly,
you don't have to think about it, because startx sets the DISPLAY
for you when it starts the initial applications, and anything started
by those initial apps will inherit that setting, and so on. And when you
do start apps like xterm and xclock, things are simple: xterm creates
a "dumb(ish) terminal" emulation, normally running a shell, and xclock
starts a clock display.
:: (ultimately I want to run xterm from a remote computer with ssh, but
:: first things first, I can't even get it to run locally)
Here you must avoid trying to tell ssh what to do, X-wise.
Ssh understands X, and takes care of all the details; the most
common problems are trying to do things ssh has already done.
So. From a dead standing start at the non-X text console, you type
"xstart". That'll start the server. You'll get a KDE or GNOME desktop,
or maybe you'll get something simpler, but the next stage is to start an
xterm, or equivalent. In KDE, for example, you can normally just click
on the picture of the CRT with a seashell in front of it, and you'll get
an xterm-like KDE app running with a shell reading commands (oh, aren't
icons so cute). Sometimes, you'll already have an xterm running. It
all depends on which apps your .xinitrc or .xsession decides to start.
OK, now you've got a dumb-CRT-like window you can type commands into.
Just type "ssh -X remotehost". You'll get a command shell on the
remote host. Then simply start more apps from that shell, and they'll
run remotely and display locally.
Hope this helps.