iTerm2 on OSX is warning about "paste bracketing being left on" for 2.7.1b #4521
Comments
|
The only change to our bracketed paste handling since 2.6.0 was 4ff002b, which was supposed to turn it off when fish exits, so this is rather perplexing. So, @psbanka: Just to be clear:
This is something I'd expect with 2.6.0, since that does not turn off bracketed paste when fish dies, so if you upgraded and it just happened that once it'd be something we already fixed (and the detection was presumably just added to iTerm2). But if it happens with 2.7b1 that would be weird. |
|
Yes, just went through those exact steps. You can see me opening and closing tabs/windows in this It turned out I had both fish 2.6.0 installed and fish 2.7.1b installed. I uninstalled both and then installed the newest version alone with |
|
And if you click "Yes" (not "Always" or "Never") on that message it'll just occur again? Because if it doesn't it could just be iTerm remembering what fish 2.6.0 did. Otherwise I'm still struggling to figure out how fish 2.7b1 could in any way make this worse. |
|
That is correct screen-cap |
|
Since, as I said, the only change to bracketed paste from 2.6.0 is to turn it off also when fish exits, can you try reverting that? You don't need to actually function __fish_disable_bracketed_paste --on-event fish_preexec
printf "\e[?2004l"
endThat'll redefine the function without Note that, if this succeeds, it's a bug in iTerm2 - the detection would be wrong. If that doesn't work, we're going to need to re-check some assumptions. |
|
Okay, I don't have much of an idea what any of this is doing, but I'm happy to follow directions and report results. So pasting in that function and executing it and then opening new terminals does not seem to have any affect. |
|
This just started happening for me when I upgraded from 2.6.0 to 2.7.0. It may have something to do with iTerm's shell integration and detecting the shell prompt. It works by adding some lines to your fish_prompt function that emit control codes. When a prompt is detected, it prints that little blue triangle mark by the prompt. You can see it in @psbanka's screen captures, but only on the first prompt. When the feature is working correctly, it shows on all prompts. I do not have it enabled, and never saw the mark before upgrading to 2.7.0, but now it shows on the first prompt after changing directories: I have the shell integration installed on another computer that is still running fish 2.6, so I can see if that changes anything (but cannot test it yet). (By the way, is there an easy way to clear fish's configuration files for a single session, for a kind of "safe-mode", for testing these things?) |
|
I'm also seeing this issue after upgrading to 2.7.0. Is there any information I can share that will help you track down the issue? |
|
Yep, ditto. I don't have iTerm's shell integration enabled either. This is my fish setup https://github.com/REBELinBLUE/dotfiles/tree/master/files/shell/fish |
|
At work now with the computer with shell integration enabled. Just went through carefully watching behavior before upgrading fish, and then after upgrading fish, I did not get any of the paste bracketing warnings. Here is what it looks like at 2.6.0: Turns out it looks the same with 2.7.0: Not sure if this is helpful, but my prompt did not change across the upgrade, and it shows (with shell integration enabled): And on the other computer, with shell integration disabled: |
|
Can share how iTerm is configured to launch fish (ie run command, login shell, exec from |
|
|
I'm getting this too after upgrading from 2.6.0 to 2.7.0. Let me know if there's anything I can paste in to help! |
@leewalsh: What we recommend in our issue template is So, what is still confusing me here is that the only change in 2.7.0 related to bracketed paste is turning it off when fish exits (i.e. doing the very thing that iTerm says it's not). Alternatively, since this seems to be a shell integration thing, it'd be possible that the various event-triggered functions here interfere with each other. We don't actually run any of them in the background or more than one at a time, but I'm not sure if they are always triggered in the same order. So what I'm assuming is:
For some reason, iterm has both "precmd" and "preexec" functions, but they are triggered when the What I'd love to see, @leewalsh, @psbanka, @charleskorn, @richrad, is a recording with asciinema. That way we can both see what is happening and still check the full output. Also, since I'm a bit confused, could everyone tell me again if they see this just with shell integration enabled or without it as well? |
|
And also please try to reproduce with an empty fish configuration - i.e. just move ~/.config/fish away for a bit and open a new session. If that changes anything, please report any custom functions and third-party scripts (OMF, fisherman, ...) you are using. |
|
Still reports with an empty fish configuration. |
|
Oh, one more thing: Because this might be remembered from a previous session and I'm not sure if it's cleared by iTerm, click "Yes" on the notification before checking anything. |
|
@faho, Here is a summary for two different computers
Anything in particular you'd like to see on asciinema? I can do what is in the screenshots again if you just want to see it live. I assume that it won't record the warning or the prompt marks, but maybe it grabs escape codes? I will also test with a clean config for fish and iterm when I get the chance. |
You know, that's quite confusing. The prompt markers are enabled by iterm's shell integration, so there's something going on here.
It'll grab all the output of the fish process, which includes escape codes - including those making up the prompt marks (i.e. it wouldn't show the neat marker character, but
Since this seems to be triggered on Also the output of As always, feel free to censor anything you consider to be personal information - I want to know about your bug, not your bank details. |
|
I've made a recording of what I'm seeing at https://asciinema.org/a/EQaQlJnYGbe2nfWakdGeIZcMC.
Let me know if there's anything else that would be helpful. |
|
I had the same symptoms as the original poster after upgrading to fish 2.7.0. iTerm2 version is 3.1.5
I have never installed Now I have
|
Huh... @charleskorn: Did that session exhibit the prompt marks for you? Do you otherwise get them? Because, looking at the json, I'm not seeing any of iTerm's proprietary escape codes nor any sign of the shell integration. It also includes the bracketed paste end sequence ( What I'd like to find out is if that session actually triggers the issue. Can you set your shell to bash (assuming that doesn't handle bracketed paste itself), then |
|
I was having this issue with iTerm2 ( 3.1.5 ) as well on an early 2015 mbp ( OSX 10.12.6 ) and Konstruktionist's workaround has 'fixed' it. |
|
@faho If you leave on the option To note, I actually got this warning back when bracketed paste was first implemented (whenever that was - 2.6? I keep up with whatever is in master). I just told iTerm to always turn it off so I don't get the notification, but bracketed paste still works fine. I actually tried to go turn the warning back on to see if I still get it, but I can't figure out how to do that one. Doesn't seem to be in the preferences anywhere. The only option about it is under the Advanced preferences, and reads |
|
@Darkshadow2 I found it hiding in ~/Library/Preferences/com.googlecode.iterm2.plist – I think it's NoSyncHaveWarnedAboutPasteConfirmationChange |
|
@richrad Thanks, though I'm not sure that's it. I quit iTerm, launched Terminal, and used |
|
@Darkshadow2, @richrad, In the |
|
@Darkshadow2 Sorry about that, I think I realized it was the wrong one right after I posted this. I've found that there are a couple "NoSync" keys in there that say something about bracketed paste. Nuking 'em all brings back the warning for me. I've had to remove them twice sometimes before it stuck but I think that has to do with the timing of when I edit the file and whether or not iTerm is running when I make the changes. |
|
@leewalsh Ah, you're right. They need to word that setting better... So, turning that to And interesting, I could swear back when I did it I told iTerm to always turn it off (which would have been 'Yes' under that setting). If I set it to Also interesting that even though I removed that from iTerm's preferences, it still remembered. I wonder if there's more than one? Or maybe iTerm was changed recently to default that warning to off. |
I get the prompt marks on the initial prompt, the prompt where I then type
Just tried that now... the warning appears as soon as I start playback. If I then open another tab that runs bash (rather than my default of fish), I don't see the warning. |
So they appear at the first prompt, or after the first command or so? This is really confusing me. The best theory I can come up with is that iTerm, with the "shell integration" setting (not the script) turned on, figures out where fish's prompt is and then sees that bracketed paste is on and assumes it is wrong. There is bb29f9f, which changed the $PWD reporting. This might explain how iTerm is getting these prompt marks and why they only appear when $PWD changes, and how it is only happening in 2.7.0 and not 2.6.0. However, that would mean it's an iTerm bug. Has anyone tried contacting @gnachman? |
Yep, before I even type anything, I see that warning. |
|
LATEST UPDATE: 328439, this is the root cause in fish commits, which added iTerm into the update_pwd list. Remove diff --git a/share/functions/__fish_config_interactive.fish b/share/functions/__fish_config_interactive.fish
index e29c1fc2..dbd57ebc 100644
--- a/share/functions/__fish_config_interactive.fish
+++ b/share/functions/__fish_config_interactive.fish
@@ -271,7 +271,7 @@ function __fish_config_interactive -d "Initializations that should be performed
or set -l VTE_VERSION 0
set -q TERM_PROGRAM
or set -l TERM_PROGRAM
- if test "$VTE_VERSION" -ge 3405 -o "$TERM_PROGRAM" = "Apple_Terminal" -o "$TERM_PROGRAM" = "iTerm.app"
+ if test "$VTE_VERSION" -ge 3405 -o "$TERM_PROGRAM" = "Apple_Terminal"
function __update_cwd_osc --on-variable PWD --description 'Notify capable terminals when $PWD changes'
if status --is-command-substitution
or set -q INSIDE_EMACSUPDATE: I do some experimental fixes to solve this problem. I can't guarantee that I have understood the behavior of iTerm2 correctly and this does not introduce new or even more critical bugs. Here's the patch. Apply to the latest commit of iTerm2 then we have no warning on start and no markers on PWD reporting, while shell-integrations still work. diff --git a/sources/VT100Screen.m b/sources/VT100Screen.m
index 7fa70128..712b0024 100644
--- a/sources/VT100Screen.m
+++ b/sources/VT100Screen.m
@@ -3263,7 +3263,7 @@ static NSString *const kInilineFileInset = @"inset"; // NSValue of NSEdgeInsets
int cursorLine = [self numberOfLines] - [self height] + currentGrid_.cursorY;
VT100RemoteHost *remoteHostObj = [self setRemoteHost:host user:user onLine:cursorLine];
- if (![remoteHostObj isEqualToRemoteHost:currentHost]) {
+ if (currentHost && ![remoteHostObj isEqualToRemoteHost:currentHost]) {
[delegate_ screenCurrentHostDidChange:remoteHostObj];
}
}
@@ -3285,7 +3285,7 @@ static NSString *const kInilineFileInset = @"inset"; // NSValue of NSEdgeInsets
[self setHost:host user:user];
}
[self terminalCurrentDirectoryDidChangeTo:path];
- [delegate_ screenPromptDidStartAtLine:[self numberOfScrollbackLines] + self.cursorY - 1];
+ // [delegate_ screenPromptDidStartAtLine:[self numberOfScrollbackLines] + self.cursorY - 1];
}
- (void)terminalClearScreen {ORIGINAL: I have just tested the PWD reporting manually in bash using printf '\033]7;file://ArkMac.local/Users/arkbriar\a'and got markers on every execution.
And as iTerm2 declares that it supports OSC7, I think this should be an iTerm bug. (Okay, maybe a feature?) I have found that And bash does not do OSC7 current dir reporting so bash does not have this warning. - (void)setHost:(NSString *)host user:(NSString *)user {
VT100RemoteHost *currentHost = [self remoteHostOnLine:[self numberOfLines]];
if (!host || !user) {
// A trigger can set the host and user alone. If remoteHost looks like example.com or
// user@, then preserve the previous host/user. Also ensure neither value is nil; the
// empty string will stand in for a real value if necessary.
VT100RemoteHost *lastRemoteHost = [self lastRemoteHost];
if (!host) {
host = [[lastRemoteHost.hostname copy] autorelease] ?: @"";
}
if (!user) {
user = [[lastRemoteHost.username copy] autorelease] ?: @"";
}
}
int cursorLine = [self numberOfLines] - [self height] + currentGrid_.cursorY;
VT100RemoteHost *remoteHostObj = [self setRemoteHost:host user:user onLine:cursorLine];
if (![remoteHostObj isEqualToRemoteHost:currentHost]) {
[delegate_ screenCurrentHostDidChange:remoteHostObj];
}
} |
Sure it does, on macOS. But I guess just for Terminal.app. See |
Ah, I see it. And I have found the commit that leads to warning and markers. Maybe I should submit a PR? |
|
If I understand how iTerm should be working, those markers are supposed to show up on every prompt, not be non-existant? Shouldn't we be doing the hostname/cwd update on every new prompt instead of on directory changes for it and trying to take care of the warnings some other way? |
|
Actually I haven't enabled the shell-integration for fish. There's another way to add markers to marker cache (besides OSC7). So It's easy to have markers before every prompt.
|
|
@ridiculousfish @zanchey Could we please cut a 2.7.1 release (or 2.7.0.1?) with this fix in it? |
|
I'm still struggling to understand this. Is this an iTerm bug exposed by fish fixed by a workaround? Or a fish bug with a proper fix? Or something else entirely? |
@zanchey: My best explanation is this:
So I don't think there's a real iTerm bug here (though I do believe that message is quite overzealous). I'm also not sure how to actually fix it. Maybe sending the $PWD sequence on every prompt does it? But that just throws up more questions - does it need to be before the bracketed paste sequence (which would make our solution quite fragile as we don't have any way to order event listeners), or does it just need to be on the same line or within a certain timeframe? Or maybe we'd need to actually do the full iTerm integration thing? Or maybe iTerm should stop using the $PWD sequence as an indication of a prompt? |
|
OK, that makes sense. The omnibus commit which added the behaviour makes me wonder whether it was deliberate, but I think backing it out makes sense. I'll try and put a point release out in the next day or two. |
|
Sorry for showing up late to this party. I hope I can still help.
OSC 7 causes iTerm2 to mark the start of the prompt. If paste bracketing is on at the time OSC 7 is received and the hostname in OSC 7 does not equal the existing hostname, you get the warning.
Print it every time. I followed Terminal.app's lead on handling OSC 7 for prompt detection.
I'll change iTerm2 to not show the warning the first time we get a hostname.
Paste bracketing must be off at the time you send OSC 7. Is that feasible? FYI similar warnings exist for mouse reporting and focus reporting, if you plan to use those. |
…eporting when we transition from no hostname to having a hostname. See fish-shell/fish-shell#4521
Better late than never! I think we still have some potato salad left.
Aaah. So I basically got it half-right.
Okay.
It'll require some more work from us, but yeah, it's doable. I can see why you'd want this, so we'll figure something out. |
|
Thanks, folks. |
fish version: 2.7.1b
OS: Darwin 17.0.0 Darwin Kernel Version 17.0.0; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64
$TERM: xterm-256color
Steps to reproduce:
See a message at the top of the terminal: "Looks like paste bracketing was left on when an ssh session ended unexpectedly or an app misbehaved. Turn it off? (Yes/ Always/ Never)"
The text was updated successfully, but these errors were encountered: