Gns3-gui: Problem opening terminal when path to telnet includes a space

Created on 7 Nov 2017  路  15Comments  路  Source: GNS3/gns3-gui

Hi, this is for 2.1.0rc4 on MacOS.

I keep multiple copies of the GNS3 app (and swap out configs between the versions), so I end up with directories like /Applications/GNS3 2.app/... When I select iterm 3 and GNS3 tries to use the included telnet, the space in the path trips it up:

sh-3.2$ exec /Applications/GNS3 3.app/Contents/Resources/telnet 10.127.49.20 2047
sh: /Applications/GNS3: No such file or directory
sh: exec: /Applications/GNS3: cannot execute: No such file or directory

Bug

Most helpful comment

That doesn't work.

As an example let's take the simplest terminal command "Terminal" (I added a line break for clarity) :

osascript -e 'tell application "Terminal"' -e 'activate' -e 'do script
"echo -n -e \"\\033]0;%d\\007\"; clear; telnet %h %p ; exit"' -e 'end tell'

Now you exchange telnet by (for example) "/usr/bin/telnet", that gives:

osascript -e 'tell application "Terminal"' -e 'activate' -e 'do script
"echo -n -e \"\\033]0;%d\\007\"; clear; "/usr/bin/telnet" %h %p ; exit"' -e 'end tell'

Now the quotes of the osascript are incorrect, the starting quote of "/usr/bin/telnet" terminates the do script command. No terminal window will appear.

It's depends of the terminal command, which quotes are correct, sometime " are fine, sometimes \" are needed, sometimes even ' might be best. For me the simplest way is to reverse your change and quote the telnet command in the OS X predefined commands.

So the new predefined command for Terminal would be (without the line break):

osascript -e 'tell application "Terminal"' -e 'activate' -e 'do script "echo -n -e \"\\033]0;%d\\007\"; clear; \"telnet\" %h %p ; exit"' -e 'end tell'

All 15 comments

As a workaround in the preferences console settings replace telnet by \"telnet\" (the backslashes are important).

I have pushed a fix but this needs to be tested on macOS before we can close this issue.

That doesn't work.

As an example let's take the simplest terminal command "Terminal" (I added a line break for clarity) :

osascript -e 'tell application "Terminal"' -e 'activate' -e 'do script
"echo -n -e \"\\033]0;%d\\007\"; clear; telnet %h %p ; exit"' -e 'end tell'

Now you exchange telnet by (for example) "/usr/bin/telnet", that gives:

osascript -e 'tell application "Terminal"' -e 'activate' -e 'do script
"echo -n -e \"\\033]0;%d\\007\"; clear; "/usr/bin/telnet" %h %p ; exit"' -e 'end tell'

Now the quotes of the osascript are incorrect, the starting quote of "/usr/bin/telnet" terminates the do script command. No terminal window will appear.

It's depends of the terminal command, which quotes are correct, sometime " are fine, sometimes \" are needed, sometimes even ' might be best. For me the simplest way is to reverse your change and quote the telnet command in the OS X predefined commands.

So the new predefined command for Terminal would be (without the line break):

osascript -e 'tell application "Terminal"' -e 'activate' -e 'do script "echo -n -e \"\\033]0;%d\\007\"; clear; \"telnet\" %h %p ; exit"' -e 'end tell'

Indeed I had doubts this would work. I'll change the terminal commands directly.

I think only "iTerm2 2.x" and "iTerm2 3.x" commands need to be changed but cannot test it myself.

Royal TSX command is broken in 2.1. I tried to fix that by replacing quoted telnet word. Again, this will need to be tested by someone on macOS.

pastedgraphic-1

I'm quite confused about your changes. https://github.com/GNS3/gns3-gui/commit/0a7b6d81d878677f04a09a36b23723fbd4cd129b modifies telnet to "telnet" in the Terminal and Terminal/tabbed settings, the \ is eaten by python. Change https://github.com/GNS3/gns3-gui/commit/5d45dbebf63ea7f5782569486ecb7afe4fd88205 replaces "telnet" to the unquoted telnet command.

That way Royal TSX should work again, as the telnet string is no longer modified. But for the Terminal settings we are at the same situation as on the beginning, the telnet command is inserted without quotes. And iTerm won't work on OS X 10.13, as the telnet command is not replaced.

Honestly I think the best way is to get a (used) MAC, so you can test before you publish something. If that's too expensive, I suggest to drop the support for the MAC platform.

Apple removing telnet has definitely brought us more issues than we thought grrrr, thanks Apple!

I hoped to quickly fix that but I agree this is not going to work in long term if I cannot test my changes on macOS but that would be a shame to drop that platform just because of this... Anyway I will be able to get a used Mac in December.

I like to let you know my thoughts about this issue:

What's special in OS X is that a new terminal window is complicated to start, it starts with a fresh environment, OS X 10.13 lacks a telnet executable and the quoting is complicated. The command string is embedded in python, then interpreted by the shell, after that by applescript. Quoting \and " in this environment is really hard. Well, the python quoting could be made easier by using raw triple quotes. The missing telnet executable in 10.13 has been resolved by adding it into the GNS3 app bundle

I've got two ideas to handle this:

  1. Replace the telnet string by the full path to the telnet executable (current way)
    The difficulties is, that there are commands (for example Royal TSX) where you don't want to replace telnet, while you want to do this in others. My suggestion is to use a special telnet string, i.e %telnet%, to mark that this should be replaced. Furthermore the telnet command must be quoted to allow spaces in the path. That can't be done globally, as the current quoting depends on the environment, it is used. So the quoting has to be done in the command string. For example the Terminal command would be (as a python string with raw triple quotes): r"""osascript -e 'tell application "Terminal"' -e 'activate' -e 'do script "echo -n -e \"\\033]0;%d\\007\"; clear; \"%telnet%\" %h %p ; exit"' -e 'end tell'""". So the replace command in telnet_console.py and all OS X console commands, that needs telnet replacements have to change.
  2. Insert the GNS3 PATH into the new terminal window
    In this case no replacement of the telnet command is needed. Only the console commands have to changed to put the PATH into the new terminal window by using the applescript term system attribute "PATH". For the Terminal command: r"""osascript -e 'tell application "Terminal"' -e 'activate' -e 'do script "echo -n -e \"\\033]0;%d\\007\"; clear; PATH=\"" & (system attribute "PATH") & "\" telnet %h %p ; exit"' -e 'end tell'"""

As a special offer I can implement and test that on my iMac. Well at least the Terminal and iTerm settings, but these should be the most critical ones.

What's special in OS X is that a new terminal window is complicated to start, it starts with a fresh environment, OS X 10.13 lacks a telnet executable and the quoting is complicated. The command string is embedded in python, then interpreted by the shell, after that by applescript. Quoting \and " in this environment is really hard.

Indeed, this is really hard :(

I like the %telnet% idea but I think I prefer the GNS3 PATH one. Actually I tried this first but couldn't find how to have applescript take it into account. The GNS3 path is updated there https://github.com/GNS3/gns3-gui/blob/2.1/gns3/main.py#L135 and the environment passed there https://github.com/GNS3/gns3-gui/blob/2.1/gns3/telnet_console.py#L74 when calling the terminal application.

Feel free to implement the %telnet% idea if this one is too problematic.

As a special offer I can implement and test that on my iMac. Well at least the Terminal and iTerm settings, but these should be the most critical ones.

Thanks a lot, this will allow to fix that before the 2.1.1 release :+1:

Created pull request https://github.com/GNS3/gns3-gui/pull/2340, please review.

What I can't test is the behavior of the frozen app, when adding the app directory to the PATH. I haven't found any documentation, how the app is created. So this test must wait until you merge my PR and then a nightly build is created.

Now let's wait for the nightly build :+1:

Looks good here. Tested with Terminal, Terminal tabbed, iTerm2 2.x and iTerm2 3.x.

As an example in iTerm2 3.x it shows the following telnet command string: sh-3.2$ PATH="/Applications/Lokal/GNS3 test.app/Contents/MacOS:/Applications/Lokal/GNS3 test.app/Contents/Resources:/usr/bin:/bin:/usr/sbin:/sbin" exec telnet 127.0.0.1 5001

@CapnCheapo: please test as well.

I tested on a remote macOS. Everything looks good.

Thanks a lot @ehlers!

Was this page helpful?
0 / 5 - 0 ratings