Well, I was hoping the new debugger console that was released today would fix this… but it hasn’t. I’m running a fresh install of Debian Linux 7.4. Here is the screenshot of the issue I’m still having (have had it for months). Not having a valid working solution is getting to be a PITA, as I’m constantly moving USB drives over/mounting/dismounting/copying files, etc. between tests. ANY advice would be appreciated, or AT LEAST somebody who is actually able to take a few moments with a Debian Linux build and confirm this issue. Thanks!
BTW, I’m using the non-gui install of Linux that only uses the bash interface.
[quote=79617:@Norman Palardy]Try executing the following command at the command prompt on that machine
env
Whats the value of TERM ?[/quote]
TERM=linux
Also, how would I go about launching the app manually without escaping/terminating the debug app? Still fairly new to Linux. If I remember, isn’t an “&” involved? Is that needed to run the debug in daemon mode?
If I run the debugger without autolaunch, it runs up to the ‘Decompressing DebugrdlWatchDog.tar.gz’ then sits there… my only option is to ctrl+c to terminate the debugger to run anything else. If I do that, I can’t run the debug version of my application on that system because the debugger is not then present.
Yeah, I give up. Here’s the issues I’m having with this entire thing…
First (as shown in the original screenshot), it’s not working properly to begin with. I paid for a Pro license, this being included, and it’s simply not working. I don’t think I’m doing anything incorrectly (please advise if I am), as I’m stating my steps clearly to make sure and to provide the ability to replicate the issue. Your assistance is appreciated, but nothing we’re trying is working… and I’m honestly wasting too much time with this to begin with (have been dealing with this issue for well over a month). Nothing I’ve tried, or have been suggested to try, works.
As far as running the stub as ‘./RemoteDebuggerConsole &’ and it suppose to run in the background, giving me the command prompt back right away… it does not. Here is my screenshot of the results:
For simply running the file manually & locally after the stub transfers it, this is what I get… every time:
Again, not upset with you Norman… I HIGHLY appreciate you trying. Just getting frustrated, as I feel I’m running circles with this. Thanks!
Again, for clarification:
This is a CLEAN and FRESH install of the latest Debian Linux (only install options I selected are these… and I’ve tried without the Laptop option selected too, not that I expected that to make a difference):
According to this documentation provided by Xojo, Debian is a supported distro of Linux:
It appears that the Linux remote debugger stub makes an erroneous assumption about the meaning of the TERM variable. It believes that TERM should be consulted to find the user’s preferred terminal to launch, but that very much isn’t what it means. So the command it’s trying to use to launch the application ends up looking like:
$TERM -e /debug/DebugrdlWatchDog/DebugrdlWatchDog
This is something we’ll need to fix in a future version. For now, you can create a file with the following contents:
[code]#!/bin/bash
Remove the -e that will be passed
shift
“$@”[/code]
Then make the file executable, and, before executing the remote debugger stub, set TERM to be the path of this script. Given that TERM affects a lot of things, you’ll want to immediately change it back after launching the stub (or, if you’re using bash, you can invoke the stub as TERM=/path/to/myscript.sh ./RemoteDebuggerConsole &.
This should work, but I’ll admit that I haven’t tried it yet.
Thanks @Joe Ranieri. My solution was to write a script that changes TERM, launches the debugger, then changes it back. I’m not sure the second part is needed, but what the heck.
#!/bin/bash
export TERM=~/bin/change_term
echo Term set to $TERM
~/RemoteDebuggerConsole/RemoteDebuggerConsole
export TERM=xterm-256color
echo Term reset to $TERM