remoteDebuggerConsole - Linux

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.

Try executing the following command at the command prompt on that machine

env

Whats the value of TERM ?

Actually turn OFF autolaunch and start the app manual from the command line once its transferred
That should work

Alright Norm, appreciate the feedback. Let me try this and I’ll let you know…

[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.

Decompress the file & the run it

the stub is not the debugger
its just an app to help move the item from one machine to another

if you ran the stub as

./RemoteDebuggerConsole &

then it runs in the background & you get the cmd prompt back right away

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:

http://documentation.xojo.com/index.php/System_requirements

I’ve tried this on multiple machines, VMWARE, etc. with no success.

C’mon Xojo this is just crazy :frowning: - Look at the first screenshot

It looks like the remote stub code is the problem on first run just a shell (syntax) error after extracting the gz archive.

/debug/DebugrdlWatchDog/DebugrdlWatchDog

bash: Linux: command not found

Where is the (dot-slash) for #bash …?

/debug/DebugrdlWatchDog/./DebugrdlWatchDog

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.

Don’t play with your $TERM :frowning: lol

[b]root@deborah:/home/xojo# 02:40:54 AM: Stub->IDE OLLEH, 1.9.0fc43, 6, Rem ddress: 192.168.56.1
02:41:02 AM: Decompressing DebugMyApplication.tar.gz
Launching /home/xojo/DebugMyApplication/DebugMyApplication
hello world

[/b]

:slight_smile: yep works ok

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

change_term is Joe’s script above.

Is this on radar for being fixed properly w/in the remote debugger?

Its been reported <https://xojo.com/issue/33678>
Beyond that “no comment” - you know that