Running executables in an XTERM
Hi,
I have an application that requires a working terminal to run. The "Execution Window" of studio 11 does not have terminal support (ie. cursor is not addressable).
My app needs to run inside an xterm or vt100 terminal. How do I get my application to run within an xterm from Studio 11 IDE. And how would I debug an application that runs inside an xterm using the IDE?
[389 byte] By [
edsel_adap] at [2007-11-26 9:04:00]

# 1
It would be much more convenient for you to [i]attach[/i] to the app you wish to debug than to [i]start[/i] it from the debugger. If it is possible with your app, I sugget you do so. In this case, your app is working right where you started it and debugger works somewhere else and they don't impede each other.
# 2
There is a feature ind bx to have dbx attach the output of the program it
is debugging to a named pseudo-tty.
I think the steps go like this:
1. start an xterm without a shell in it
2. find out what pty this xterm is using
3. start up the debugger
4. set the "run_pty" dbxenv to point at this pty
dbxenv run_pty /dev/pts/NN
5. set the "run_io" dbxenv to the type "pty".
dbxenv run_io pty
6. run the program
That should result in the program's output and input going to the xterm.
From the dbx helpfile:
dbxenv run_pty <ptyname>
# Sets the name of the pty to use when
# $DBX_run_io is set to `pty'. Ptys are
# mainly used by GUI wrappers for dbx.
Actually, I think it is okay to have a shell running at the same time
in the xterm.
You can start an xterm, and then type "tty" in the xterm window.
It will echo the pseudo tty for that window.
# 3
How do you start "xterm" without a shell in it?And if you start it with the shell that you application and shell will share the same input and make a mess on the screen.
# 4
> My app needs to run inside an xterm or vt100
> terminal. How do I get my application to run within
> an xterm from Studio 11 IDE.
This problem is solved in Sun Studio 12 IDE.
Users have a choice to run executable in a built-in I/O window
or in an external terminal (gnome-terminal or xterm).
The default is external terminal (/bin/gnome-terminal).
> And how would I debug
> an application that runs inside an xterm using the
> IDE?
It is not supported yet in Early Access release, but we plan to
provide this option. I hope it will be in Sun Studio 12 FCS release.
You can download Sun Studio 12 Express 3 release from:
http://developers.sun.com/sunstudio/downloads/express.jsp
Thanks,
Nik
# 5
But the RunExecutable window _is_ a terminal and it _does_
accept cursor addressability. I wrote it.
It accepts ANSI escapes like these
http://enterprise.aacc.cc.md.us/~rhs/ansi.html
Also if your application requires pty support, i.e. it expects
isatty() to return true, that works as well.
Have you actually tried it?
I should note that it's not %100 ANSI compliant.
It will handle 'more', 'vi' and shell cmdline editing
but midnight commander stresses it.
# 6
Ivan,If you know the details about the RunExecutable window you might be able to help with my problem witch CURSES.Could you, please, check out topic: Dbx Process I/O Window and CURSES problems ?ThanksI will respond to some xterm issues in the next message
# 7
I was previously asking a question how to run xterm without a shell in it.
I did not get any response but here is a simple trick how to run application from Studio 11 IDE and redirect I/O to xterm window.
The xterm (to my knowledge) has to be always associated with some running application.
The problem is that the application I/O is interfering with I/O of the program you are debugging.
THIS IS A HACK.
Write a simple c program (s.c):
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
printf("pty:%s\n",ttyname(0));
close(0); close(1); close(2);
fclose(stdin); fclose(stdout); fclose(stderr);
for(;;) sleep(10);
}
compile:
cc s.c
and execute ?do it login as the same user as you are running Studio11 to avoid permissions issues.
xterm a.out
Now you have running xterm with application which is ignoring I/O
The only text displayed in the xterm window is the name of pty
Go into IDE debugger and load the application you want to debug in xterm window
Set the I/O for the program to the pty from the xterm screen
Make sure your environment has set proper TERM.
Start debugging. All I/O will go through xterm window.
Once you are done just close the window (xterm) or CTRL_C from it.
Let me know if it helped
Message was edited by:
Well the Forte6U2 did not have this kind of problems. The Output window was working just fine as a xterm replacement. For the development environment like Studio11 there should be a nicer way how to do this.
coinserv
# 8
There is yet another way to work around this w/o writing
C code and mucking with pty's.
- In the SunStudio11 IDE issue Tools->Allow ss_attach_requests
- IN an external terminal of your choice issue
$ ss_attach <your_application>
ss_attach will cause the IDE to popup a dialog asking if you
want to attach to the application. This has the advantages of
- no need to discover and shuttle PID's all the time.
- can attach to the application from it's very beginning (i.e.
no need for spin loops and such.
# 9
#1 When I try it I will get this error:
ss_attach: trying to connect to IDE ...
ss_attach: could not connect to external start service -- service not registered
Any idea?
#2 ?I am afraid that this will work similar as attaching directly from the debugger. Once you do it you will loose ability to do memory checking and some other stuff.
Look at my message in the topic: Inability to use RTC when attaching to a process.
Thanks
# 10
on ss_attach failing:Run the utility "smctl diag" in the term you are running ss-attach and theterm you started the IDE from. They need a common rendezvous point.It usually diverges if $DISPLAY is different.
# 11
Yes,
That is it. Thank you very much.
I am normally running Studio directly from windows manager with its own user id etc. If I run it from the command line, from the same session, ss_attach works just fine.
However, as I mentioned before the ss_attach is just an easy way how to attach to the running process.
The method I described before will enable you to start a process directly from the debugger IDE, and run it in a xterm window. This will enable you to use all features of the debugger, like checking memory access, memory use, running collector for performance analysis etc.