iTerm 3.0.4 Shell Integration Issues w/ imgcat and SCP

481 views
Skip to first unread message

Kris McCann

unread,
Jul 2, 2016, 11:02:44 AM7/2/16
to iterm2-discuss
I'm trying to get the shell integration going, and some aspects of it seem to be working fine. Marks are working fine, blue on success, red on failure, and I'm able to right click and view return codes, so I believe overall that the shell integration is working.

However, both imgcat and SCP integration are failing.

Running the following command should show an animated gif:


But instead, the marker is blue to indicate success, and nothing happens, it just returns to the prompt. The same happens with any image, local or remote.

I've tried updating and replacing the file ~/.iterm2/imgcat, and the same thing. I've also added ~/.iterm2 to my paths so that it can find the script.

I'm seeing a similar behaviour from the SCP functionality. Dropping a file on to the terminal while holding down option does nothing, the file springs back to the finder window. Doing it without holding option just outputs the local file path to the prompt. Manually running the it2dl correctly echos the usage with no parameters. With a directory it warns that it's a directory. With a valid file, as with imgcat, it just returns to the prompt with no action.

The "Download with SCP" menu item is greyed out. It displays "Download with .SCP" only, no host info. I've set up hosts so that running hostname -f outputs the same host that my .ssh/config file is configured to point to, but I've also set it to use a full host name, and I've tried exporting iterm2_hostname. The menu item remains greyed out regardless. If I run:

scp user@host:~/.iterm2/download.sh ~/download.sh

then the file copies as expected, so everything should be good with SCP.

At this point I've tried just about everything I can think of. I have iTerm2 running so close to the configuration that I want, but I just can't seem to get SCP and imgcat to behave. Anything that you can do to point me in the right direction would be appreciated!

Thanks,

Kris.

George Nachman

unread,
Jul 2, 2016, 1:01:04 PM7/2/16
to iterm2-...@googlegroups.com
Ugh, sorry this has been such a pain for you. Let's figure it out and improve it so other folks don't go through this.

On Sat, Jul 2, 2016 at 8:02 AM, Kris McCann <kr...@adeptmedia.ca> wrote:
I'm trying to get the shell integration going, and some aspects of it seem to be working fine. Marks are working fine, blue on success, red on failure, and I'm able to right click and view return codes, so I believe overall that the shell integration is working.

However, both imgcat and SCP integration are failing.

Running the following command should show an animated gif:


But instead, the marker is blue to indicate success, and nothing happens, it just returns to the prompt. The same happens with any image, local or remote.

I've tried updating and replacing the file ~/.iterm2/imgcat, and the same thing. I've also added ~/.iterm2 to my paths so that it can find the script.


Is this on your Mac or are you ssh'ed somewhere? imgcat relies on base64, and if your base64 is missing or weird in some way that could cause a problem. One test you could perform is to verify that imgcat is producing correct output:

% curl -s http://media.giphy.com/media/6uMqzcbWRhoT6/giphy.gif | imgcat | hexdump -C | head
00000000  1b 5d 31 33 33 37 3b 46  69 6c 65 3d 73 69 7a 65  |.]1337;File=size|
00000010  3d 34 39 39 33 37 39 3b  69 6e 6c 69 6e 65 3d 31  |=499379;inline=1|
00000020  3a 52 30 6c 47 4f 44 6c  68 6b 41 45 73 41 66 65  |:R0lGODlhkAEsAfe|
00000030  56 41 4d 32 30 62 70 42  6d 46 57 35 56 4a 76 48  |VAM20bpBmFW5VJvH|
00000040  52 62 49 68 57 43 70 6c  32 4e 4d 6d 56 4d 72 6d  |RbIhWCpl2NMmVMrm|
00000050  70 64 2b 6e 59 70 38 6d  32 68 70 52 36 52 32 6b  |pd+nYp8m2hpR6R2k|
00000060  71 41 4b 75 5a 64 4c 6d  74 68 6e 64 56 46 4d 71  |qAKuZdLmthndVFMq|
00000070  62 51 37 65 4b 4e 59 68  6e 4a 57 56 49 46 61 64  |bQ7eKNYhnJWVIFad|
00000080  34 4a 6c 6c 43 45 71 69  45 52 4b 75 45 4e 70 70  |4JllCEqiERKuENpp|
00000090  7a 49 31 63 32 42 55 63  78 45 56 4a 47 4a 53 67  |zI1c2BUcxEVJGJSg|

I try to handle the variety of base64s that I've encountered in the wild, so let me know what's happening here and I can update the script if this is the issue.
 
I'm seeing a similar behaviour from the SCP functionality. Dropping a file on to the terminal while holding down option does nothing, the file springs back to the finder window. Doing it without holding option just outputs the local file path to the prompt. Manually running the it2dl correctly echos the usage with no parameters. With a directory it warns that it's a directory. With a valid file, as with imgcat, it just returns to the prompt with no action.

These are two separate problems:

1. The file springs back. 
Do you have shell integration installed on the remote host? This is what happens if we think you're trying to upload a file to your mac, and it suggests that shell integration is only installed locally (so even though you're ssh'ed, iTerm2 thinks you are still on localhost). Based on what I see below, I guess you have it installed but it's not behaving well.

2. it2dl fails
This points to base64 weirdness too. It's very similar to imgcat. If we fix imgcat we'll fix this too.
 
The "Download with SCP" menu item is greyed out. It displays "Download with .SCP" only, no host info. I've set up hosts so that running hostname -f outputs the same host that my .ssh/config file is configured to point to, but I've also set it to use a full host name, and I've tried exporting iterm2_hostname. The menu item remains greyed out regardless.

Can you confirm you get the blue/red marks when you're sshed to the remote host, and not just locally?

One useful debugging step is to select Edit > Edit Session… and set the badge to:
\(session.username)@\(session.hostname):\(session.path)

This shows what iTerm2 thinks your username, hostname, and working directory are set to. Since Download with SCP is grayed out, it's likely that the username or hostname is not set properly. I'm sure it's not set correctly, but it would be interesting to see what it's set to.

One possibility is that you have something in your shell login scripts (bashrc and friends) that conflicts with shell integration and the escape sequences that communicate the hostname, etc., are not being sent. Try removing everything except the shell integration "source" command from your login scripts. Depending on your shell that would be:

bash: .bashrc, .bash_profile, .profile
tcsh: .tchsrc, .login
zsh: .zshrc
fish: Everything in .config/fish

If this is the issue let me know and I can try to find a workaround. Sometimes it's as easy as changing the order in which things are loaded.

Finally, you could file an issue and include a debuglog. Go to https://iterm2.com/bugs. The bug template describes what you need to do.

Best,
G

Kris McCann

unread,
Jul 2, 2016, 1:32:17 PM7/2/16
to iterm2-discuss, gnac...@llamas.org
Hey George, thanks for the response.
 
Is this on your Mac or are you ssh'ed somewhere? imgcat relies on base64, and if your base64 is missing or weird in some way that could cause a problem. One test you could perform is to verify that imgcat is producing correct output:

% curl -s http://media.giphy.com/media/6uMqzcbWRhoT6/giphy.gif | imgcat | hexdump -C | head
00000000  1b 5d 31 33 33 37 3b 46  69 6c 65 3d 73 69 7a 65  |.]1337;File=size|
00000010  3d 34 39 39 33 37 39 3b  69 6e 6c 69 6e 65 3d 31  |=499379;inline=1|
00000020  3a 52 30 6c 47 4f 44 6c  68 6b 41 45 73 41 66 65  |:R0lGODlhkAEsAfe|
00000030  56 41 4d 32 30 62 70 42  6d 46 57 35 56 4a 76 48  |VAM20bpBmFW5VJvH|
00000040  52 62 49 68 57 43 70 6c  32 4e 4d 6d 56 4d 72 6d  |RbIhWCpl2NMmVMrm|
00000050  70 64 2b 6e 59 70 38 6d  32 68 70 52 36 52 32 6b  |pd+nYp8m2hpR6R2k|
00000060  71 41 4b 75 5a 64 4c 6d  74 68 6e 64 56 46 4d 71  |qAKuZdLmthndVFMq|
00000070  62 51 37 65 4b 4e 59 68  6e 4a 57 56 49 46 61 64  |bQ7eKNYhnJWVIFad|
00000080  34 4a 6c 6c 43 45 71 69  45 52 4b 75 45 4e 70 70  |4JllCEqiERKuENpp|
00000090  7a 49 31 63 32 42 55 63  78 45 56 4a 47 4a 53 67  |zI1c2BUcxEVJGJSg|


Both locally on my Mac, and remote on my Ubuntu VPS.

On my local machine I get:

curl -s http://media.giphy.com/media/6uMqzcbWRhoT6/giphy.gif | imgcat | hexdump -C | head
00000000  1b 5d 31 33 33 37 3b 46  69 6c 65 3d 73 69 7a 65  |.]1337;File=size|
00000010  3d 34 39 39 33 37 39 3b  69 6e 6c 69 6e 65 3d 31  |=499379;inline=1|
00000020  3a 52 30 6c 47 4f 44 6c  68 6b 41 45 73 41 66 65  |:R0lGODlhkAEsAfe|
00000030  56 41 4d 32 30 62 70 42  6d 46 57 35 56 4a 76 48  |VAM20bpBmFW5VJvH|
00000040  52 62 49 68 57 43 70 6c  32 4e 4d 6d 56 4d 72 6d  |RbIhWCpl2NMmVMrm|
00000050  70 64 2b 6e 59 70 38 6d  32 68 70 52 36 52 32 6b  |pd+nYp8m2hpR6R2k|
00000060  71 41 4b 75 5a 64 4c 6d  74 68 6e 64 56 46 4d 71  |qAKuZdLmthndVFMq|
00000070  62 51 37 65 4b 4e 59 68  6e 4a 57 56 49 46 61 64  |bQ7eKNYhnJWVIFad|
00000080  34 4a 6c 6c 43 45 71 69  45 52 4b 75 45 4e 70 70  |4JllCEqiERKuENpp|
00000090  7a 49 31 63 32 42 55 63  78 45 56 4a 47 4a 53 67  |zI1c2BUcxEVJGJSg|

On the remote Ubuntu box I get:

curl -s http://media.giphy.com/media/6uMqzcbWRhoT6/giphy.gif | imgcat | hexdump -C | head
00000000  1b 5d 31 33 33 37 3b 46  69 6c 65 3d 73 69 7a 65  |.]1337;File=size|
00000010  3d 34 39 39 33 37 39 3b  69 6e 6c 69 6e 65 3d 31  |=499379;inline=1|
00000020  3a 52 30 6c 47 4f 44 6c  68 6b 41 45 73 41 66 65  |:R0lGODlhkAEsAfe|
00000030  56 41 4d 32 30 62 70 42  6d 46 57 35 56 4a 76 48  |VAM20bpBmFW5VJvH|
00000040  52 62 49 68 57 43 70 6c  32 4e 4d 6d 56 4d 72 6d  |RbIhWCpl2NMmVMrm|
00000050  70 64 2b 6e 59 70 38 6d  32 68 70 52 36 52 32 6b  |pd+nYp8m2hpR6R2k|
00000060  71 41 4b 75 5a 64 4c 6d  74 68 6e 64 56 0a 46 4d  |qAKuZdLmthndV.FM|
00000070  71 62 51 37 65 4b 4e 59  68 6e 4a 57 56 49 46 61  |qbQ7eKNYhnJWVIFa|
00000080  64 34 4a 6c 6c 43 45 71  69 45 52 4b 75 45 4e 70  |d4JllCEqiERKuENp|
00000090  70 7a 49 31 63 32 42 55  63 78 45 56 4a 47 4a 53  |pzI1c2BUcxEVJGJS|
 
These are two separate problems:

1. The file springs back. 
Do you have shell integration installed on the remote host? This is what happens if we think you're trying to upload a file to your mac, and it suggests that shell integration is only installed locally (so even though you're ssh'ed, iTerm2 thinks you are still on localhost). Based on what I see below, I guess you have it installed but it's not behaving well.

I do have shell integration installed both on my Mac, and on the Ubuntu box. I have a second VPS as well that I haven't installed shell integration on, and I get the blue marker on the VPS on which it is installed, which would seem to suggest that it's at least partially working. 
 
2. it2dl fails
This points to base64 weirdness too. It's very similar to imgcat. If we fix imgcat we'll fix this too.

I figured it2dl was just the script that the upload/download menu functionality hooked into. I also downloaded different versions of imgcat and download.sh that you'd posted elsewhere just to test, and the behaviour is consistent.
 
Can you confirm you get the blue/red marks when you're sshed to the remote host, and not just locally?

Yep, see above. Blue/red markers appear in shell for all systems that have the integration installed.
 
One useful debugging step is to select Edit > Edit Session… and set the badge to:
\(session.username)@\(session.hostname):\(session.path)

Well this is interesting. Setting the badge to that just creates an overlay on the window that says "@:" (no quotes). It seems it's not picking up any of the session info.

I've tried setting the badge both from a local shell, and when shelled into a remote box, and the result is the same. 
 
One possibility is that you have something in your shell login scripts (bashrc and friends) that conflicts with shell integration and the escape sequences that communicate the hostname, etc., are not being sent. Try removing everything except the shell integration "source" command from your login scripts. Depending on your shell that would be:

I tried removing everything from my startup/profile scripts except for:

source ~/.iterm2_shell_integration.`basename $SHELL`

I get the blue/red markers, but the session info remains blank when trying to read it into the badge, and the problems remain.
 
Finally, you could file an issue and include a debuglog. Go to https://iterm2.com/bugs. The bug template describes what you need to do.

I'm looking into this now. Hopefully have a proper bug report up for you soon.

Thanks for your help on this, I know it's not exactly the end of the world, but the features would come in pretty handy for me, and I'm stubborn enough to have already burned a bunch of time trying to get them up and running!

Cheers,

Kris. 
Reply all
Reply to author
Forward
0 new messages