It may be a hidden -d directive somewhere.
you said there is a system which can display on to this reflexion X running windows workstation, which eliminates the misconfiguration of the x server on the PC
while the successful terminal displaying on your screen, do a ps -ef | grep xterm and at the same time run the same command in an endless loop, capturing output to a file while you try starting up the xterm from the system with failures. Exemplifying:
sys1 : where it runs and displays fine
sys2 : where it errors out
on sys1:
export DISPLAY=a.b.c.d:0.0
xterm
ps -ef | grep xterm (after the xterminal displays on your workstation)
on sys2:
create file logger.sh
#file: logger.sh
while true
do
ps -ef | grep xterm >> /tmp/dump
done
chmod 700 logger.sh
export DISPLAY=a.b.c.d:0.0
./logger.sh &
xterm
(wait until it errors out)
kill %1 (assuming this is the first job running in the background)
at this point examine the /tmp/dump file to see if the command is running with a -d directive, i.e, instead of accessing the xterm binary, you may be running a script called xterm which may in turn be running the actual xterm binary with a -d option.
also, you can try to invoke xterm using its full path name.
if all of these did not give you anything different, assuming OS versions of sys1 and sys2 are equal, I would suggest copying the xterm binary from sys1 to sys2:/tmp/xterm
then try to run xterm by invoking command /tmp/xterm. if this runs okay, you may probably rule that you had a corrupt binary.
good luck.
________________________________
UNIX because I majored in cryptology...
