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:curl -s http://media.giphy.com/media/6uMqzcbWRhoT6/giphy.gif | imgcatBut 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.
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 | head00000000 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|
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 failsThis points to base64 weirdness too. It's very similar to imgcat. If we fix imgcat we'll fix this too.
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)
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:
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.