iTerm2 shell integration throws "Looks like paste bracketing was left on..."

[madsem]

################ fish, version 3.0.2 3.0.2

Darwin vm 17.7.0 Darwin Kernel Version 17.7.0: Wed Apr 24 21:17:24 PDT 2019; root:xnu-4570.71.45~1/RELEASE_X86_64 x86_64

xterm-256color

###############

I get this warning sometimes, since I installed the iTerm2 shell integration, and added it to the end of my fish config:

...
...

##
# iTerm2
##

# set material design color preset
echo -e "\033]1337;SetColors=preset=material-design-colors\a"

# shell integration
source ~/.iterm2_shell_integration.(basename $SHELL)

Warning:

I'm not 100% sure what causes this, but I suspect it happens when iterm2 inserts a mark, not sure though. it just happened last time when the small blue triangle was exactly in the position of my prompt, as seen on the screenshot.

It happened a few times now already, not when running specific commands though... happened with ls -al ... and also when I ran a which ...

[faho]

Pretty sure that means you'll need to update iterm or its shell integration - this is the same as #4521, which was fixed on fish's side by fd10c29211dd1bf6780e690975414066f9a1e15c (in 2.7.1, by disabling PWD reporting for iTerm) and in iTerm by https://github.com/gnachman/iTerm2/commit/65c5d46db6c86e5d4aee9cfb649fd243f6b61cd6, included in 3.1.6.

Alternatively, something in your config is triggering this, and you'll want to remove it.

[madsem]

@faho thanks for the quick reply!

iTerm is the latest version: Build 3.2.9

This is my whole ~/.config/fish/config.fish:

# disable greeting
set fish_greeting

# if there's a .secrets file, source that
set secrets ~/.secrets
if test -e secrets
    source secrets
end

# source global envs / exports
source ~/.config/fish/envs.fish

# source aliases
if status --is-login
    source ~/.config/fish/aliases.fish
end

# source abbreviations
if status --is-login
    source ~/.config/fish/abbreviations.fish
end

# add entries from paths file to $PATH
source ~/.config/fish/paths.fish
for entry in $entries
    set -g -x PATH $entry $PATH
end


# Fisher Package Manager
# https://github.com/jorgebucaran/fisher
if not functions -q fisher
    set -q XDG_CONFIG_HOME
    or set XDG_CONFIG_HOME ~/.config
    curl https://git.io/fisher --create-dirs -sLo $XDG_CONFIG_HOME/fish/functions/fisher.fish
    fish -c fisher
end

##
# Fish syntax highlighting - oceanic material color style
##
set -g fish_color_autosuggestion '555'  'brblack'
set -g fish_color_cancel -r
set -g fish_color_command 82aaff --bold
set -g fish_color_comment red
set -g fish_color_cwd green
set -g fish_color_cwd_root red
set -g fish_color_end brmagenta
set -g fish_color_error brred
set -g fish_color_escape 'bryellow'  '--bold'
set -g fish_color_history_current --bold
set -g fish_color_host normal
set -g fish_color_match --background=brblue
set -g fish_color_normal normal
set -g fish_color_operator f78c6c
set -g fish_color_param eeffe3
set -g fish_color_quote c3e88d
set -g fish_color_redirection brblue
set -g fish_color_search_match 'bryellow'  '--background=brblack'
set -g fish_color_selection 'white'  '--bold'  '--background=brblack'
set -g fish_color_user yellow
set -g fish_color_valid_path --underline

##
# spacefish theme customization
##
set -g SPACEFISH_DIR_COLOR c792ea
set -g SPACEFISH_GIT_BRANCH_COLOR ffcb6b
set -g SPACEFISH_AWS_SYMBOL "☁️  "


##
# iTerm2
##

# set material design color preset
echo -e "\033]1337;SetColors=preset=material-design-colors\a"

# shell integration
source ~/.iterm2_shell_integration.(basename $SHELL)

PS: Shell integration was installed yesterday, so it should be up-to-date.

[madsem]

Also I've the read #4521 and there it was predictable, here the warning appears erratic, and I honestly couldn't figure out yet what triggers it.

I can run any command multiple times, for example cd ~/something, nothing happens. I open a new terminal tab, run the command from history and the warning appears. But also not every time I open a new tab... Completely erratic behavior atm.

[faho]

This is my whole ~/.config/fish/config.fish:

Yes, but it's not your entire config, given that you're sourcing a whole bunch of stuff. Something there is sending some sequence at a time when iTerm doesn't expect it. You'll have to disable parts to figure out where it is. It's likely to be an event handler, which you can find via functions --handlers.

[madsem]

@faho I've followed your advice, but so far it didn't change anything. What I did was:

• I emptied the complete config file I've pasted above.
• I left only the line

# shell integration
source ~/.iterm2_shell_integration.(basename $SHELL)

Then I opened a new tab in iterm2, and it is still happening.

I was able to find a way to repeat the results also, it always happens when I clear the terminal with cmd + k and then type ~ followed by enter.

I've also confirmed that nothing is cached, by closing iterm2 completely and then restarting it. It is still happening, with cleared config file

[madsem]

PS: here is the output of functions --handlers:

➜ functions --handlers
Event signal
SIGTRAP fish_sigtrap_handler
SIGWINCH __fish_winch_handler

Event variable
PWD __z_on_variable_pwd
fish_color_cwd __fish_repaint
fish_color_cwd_root __fish_repaint_root
fish_key_bindings __fish_reload_key_bindings
fish_user_paths __fish_reconstruct_path

Event generic
fish_command_not_found __fish_command_not_found_handler
fish_exit __fish_disable_bracketed_paste
fish_preexec __fish_disable_bracketed_paste
fish_preexec iterm2_preexec
fish_prompt __fish_enable_bracketed_paste

[madsem]

Also uninstalled z, as I saw it was using a function with PWD. But again, no change, still happening.

As you can see, now there's only fish internal functions left:

➜ functions --handlers
Event signal
SIGTRAP fish_sigtrap_handler
SIGWINCH __fish_winch_handler

Event variable
fish_color_cwd __fish_repaint
fish_color_cwd_root __fish_repaint_root
fish_key_bindings __fish_reload_key_bindings
fish_user_paths __fish_reconstruct_path

Event generic
fish_command_not_found __fish_command_not_found_handler
fish_exit __fish_disable_bracketed_paste
fish_preexec __fish_disable_bracketed_paste
fish_preexec iterm2_preexec
fish_prompt __fish_enable_bracketed_paste

[faho]

Okay, most likely something is causing the order to be wrong - iTerm is kind of finicky about this, to facilitate detecting if pb was left enabled. Personally I think that's overblown.

Unfortunately I have no way to test this because iTerm is mac-specific, and I don't have a mac. I'd be quite surprised if this was the first we heard about it with 3.0.2 though, so it's probably a change in iTerm (in which case the 3.3 beta might be of interest) or a change in your config that you haven't ruled out, like any functions you override.

Either way, I'm afraid I can't be of much assistance, so I'll have to ask @fish-shell/contributors to help.

[madsem]

thanks @faho!

[gnachman]

Yipes, this has been a longstanding bug in iTerm2 that happens if you use fish on one host and a different shell on another host. What happens is this:

1. Launch fish
2. Fish turns on paste bracketing. The prompt (because of shell integration) reports the hostname, localhost.
3. User types ssh example.com, hits enter.
4. Fish turns off paste bracketing
5. ssh runs
6. Remote host has shell integration installed and reports its host name, example.com.
7. ssh terminates
8. Fish turns on paste bracketing
9. The prompt reports the hostname, localhost.
10. iTerm2 shows a warning that paste bracketing was left on, since the hostname changed after paste bracketing was enabled.

Commit 44d743c99 works around this by disabling the paste bracketing warning when the shell is fish (which can be inferred from shell integration's header). It would be better if there were some way to defer enabling paste bracketing until after the prompt has been printed, though. Not sure how hard that is to change in fish, though.

[faho]

It would be better if there were some way to defer enabling paste bracketing until after the prompt has been printed, though.

Basically not something we'd want to do. We'd typically add a new event and then use it as our paste bracketing trigger, but printing after the prompt carries a rather large risk of throwing the cursor etc off.

We can reorder the other sequences, though I'd love it if we found a better way?

What if we marked "yes, this is our stuff" before any other sequence?

[madsem]

@gnachman also happens without any remote ssh connection... Like i wrote above, it happens also on a fresh terminal window if you type ~ and then hit enter.

Ps: I’ve used the iterm2 popup message and selected “never show again”, since then it doesn’t happen anymore.

[gnachman]

What if we marked "yes, this is our stuff" before any other sequence?

That would work. Do you have a control sequence in mind? Probably want to use CSI because all terminals are good at ignoring unrecognized CSI sequences, not so much for OSC for DCS.

[gnachman]

Like i wrote above, it happens also on a fresh terminal window if you type ~ and then hit enter.

@madsem I can't reproduce this with a stock config using iTerm2 3.2.9. If you can still get this to reproduce, please file an issue at https://iterm2.com/bugs. You can re-enable the warning with Prefs > Advanced > Always turn off paste bracketing when host changes.

[madsem]

@gnachman I disabled per your instructions, and can reproduce it. Filing bug report on iterms channel. Thanks! :)

[zanchey]

@faho, is there more to do here? It seems reasonable to me to try and turn on paste bracketing after the prompt is printed - perhaps we could try it and see if there is any fallout?

[4rc0s]

I still see this when closing an SSH session. My Mac is using fish and my remote systems are generally bash. What's the recommended action to take?

[gnachman]

@4rc0s I can't reproduce this. What version of fish are you using? Please file an issue against iterm2 and include a debug log as described in the new-issue template. https://iterm2.com/bugs

[faho]

Bracketed paste is now handled internally, I'm assuming this should be fixed as of #10359.

If not someone with a mac please holler.

[krobelus]

yeah there were definitely some cases where we'd leak bracketed paste settings that are fixed now

[ariscript]

I get this warning when SSHing from my mac to a VM, where both machines are using fish. The warning happens as soon as I enter SSH, not when I exit. Happens with no fish config at all, so I don't think it's my fault.

[faho]

I get this warning when SSHing from my mac to a VM, where both machines are using fish.

@ariscript Are you using a fish with #10359, i.e. after the last release?

[ariscript]

Local version is 3.7.1, remote is 3.7.0. apt doesn't seem to have the latest release yet, I'll try it out.

[faho]

apt doesn't seem to have the latest release yet, I'll try it out.

To be clear: after the last release. This isn't released yet.

[ariscript]

I see. I don't then (though I did just update my VM to use 3.7.1). I thought it was released already.