GNOME Bugzilla – Bug 749084
Terminal should issue a confirmation popup when pasting multiple lines
Last modified: 2021-06-10 20:56:57 UTC
It's far too easy to copy and paste a block of text by mistake into a terminal. For example, you copied a command you wanted to paste, then you copied some text for other purposes and forgot about it, then you go to the terminal and paste, thinking you are pasting a line, and instead you paste 500 lines of text (e.g. code in some programming language), which has potentially disastrous effects, the most relevant being: - if accidentally pasting dozens of lines of code, though most result in errors, there are high chances that more than a few happen to be valid (though nonsense) bash commands, and you may end up creating dozens of files with nonsense names, and in some cases even deleting files - you loose all your bash history, because it has a limit and you fill it with garbage. So, when you paste into the Terminal and the pasted text is more than one line, it should ask for confirmation. There should be a "don't ask again" checkbox for those who may be annoyed by this prompt. The "don't ask again" would last for the current session; perhaps a way could be designed to have some setting editable somewhere for those who want to disable this feature completely. But it should be enabled by default. That you can destroy a system just by accidentally pasting a document into a terminal, is simply ridiculous.
It's more-or-less a dup of bug 697571. As stated there, bash-4.4 will have support for bracketed paste mode, that is, any paste performed to a bash will be enclosed between special escape sequences that bash recognizes, and it doesn't immediately execute the commands. I see this as a way better solution than gnome-terminal bringing up a popup. That popup would be way too annoying, would make it really cumbersome to paste into e.g. editors. Adding a "don't ask again" checkbox would defeat the whole purpose of the feature. Probably most people would enable that sooner or later, and would eventually accidentally paste garbage to a terminal that no longer brings up this popup and executes those lines as commands right away. Whenever I accidentally paste garbage (or type a password as a command), I follow by executing "kill -9 $$". This leaves no chance for the current bash to save its history.
> Whenever I accidentally paste garbage (or type a password as a command), I follow by executing "kill -9 $$". This leaves no chance for the current bash to save its history. Goog. However: - then you the commands you had typed before pasting garbage are lost too - this doesn't fix the damage done by the random commands executed by pasting garbage. > Adding a "don't ask again" checkbox would defeat the whole purpose > of the feature So all the popups that we commonly see in other UIs which have a "don't ask again" checkbox are useless? Note that the "don't show again" would only last for the current session. If one checks that, it means that she's going to paste several multiline blocks, so one assumes she has to know what she's doing. Also, pasting blocks of multiple command lines is far from common, isn't it? Regarding the "bracketed paste mode", I don't completely get it. Once it is supported, what exactly will happen when you paste a multiline text? If they are actually several command lines and you want to execute them, what will you have to do?
(In reply to teo from comment #2) > Goog. However: > - then you the commands you had typed before pasting garbage are lost too > - this doesn't fix the damage done by the random commands executed by > pasting garbage. Sure, I didn't mean this as a solution, rather an idea to consider after you accidentally paste loads of garbage. > So all the popups that we commonly see in other UIs which have a "don't ask > again" checkbox are useless? > Note that the "don't show again" would only last for the current session. > If one checks that, it means that she's going to paste several multiline > blocks, so one assumes she has to know what she's doing. And is she going to find and revert the corresponding setting once she's done pasting the multiline blocks? Or close the terminal and open a new one? What if she just continues using the same terminal and then accidentally pastes garbage? She'd still be hit by whatever your current concern is. So your proposal only offers a partial protection against the problem, and at the same time introduces a significant amount of inconvenience/annoyance. That's why I'm really not happy about this direction. The "don't ask again" checkboxes are I believe about way less critical issues, not where the popups prevent you from causing damage. E.g. there's no such option in "quit without save" kinds of dialogs. Also it's probably not an appropriate solution when there are security aspects of the issue (see the other bug). > Regarding the "bracketed paste mode", I don't completely get it. Once it is > supported, what exactly will happen when you paste a multiline text? If they > are actually several command lines and you want to execute them, what will > you have to do? I don't know what would exactly happen, it's up to bash to decide. I haven't tried it, not even sure if its development source code is available. You should try to find it, or ask your questions on their mailing list. (By the way, I have pasted garbage quite a few times already, and it never caused any harm. Maybe I was just lucky. I have lost much more work by other mistakes I made, like typing "cp a b" and prematurely hitting enter instead of completing to the intended command "cp a b here/".)
> And is she going to find and revert the corresponding setting once > she's done pasting the multiline blocks? Or close the terminal and > open a new one? Ideally the setting should be present in some menu. Otherwise, close and reopen the terminal (but that would be suboptimal). > The "don't ask again" checkboxes are I believe about way less critical > issues, not where the popups prevent you from causing damage. > E.g. there's no such option in "quit without save" kinds of dialogs. There is, however, for the "replace file?" popup when you try to paste a file where a file of the same name exist. Only in that case it's not called "don't show again" but "replace all" or something like that. You may object that only applies to the bunch of files you have selected to paste right now. Then consider FileZilla: when you upload a bunch of files and there is a clash, a popup appears that ask you what to do (overwrite, skip, etc), and there is: - a checkbox named "always use this action ..." -- a nested checkbox "apply this only to the current queue" And then all those settings can be found and reverted in the menus. That's the ideal model. > I don't know what would exactly happen, it's up to bash to decide. > I haven't tried it, not even sure if its development source code > is available. Oh, well, then it sounds like something that won't happen in the near future. I don't think Gnome Terminal should wait until that lands (just to find out whether or not it actually solves the issue at hand) > (By the way, I have pasted garbage quite a few times already, and it never > caused any harm. Maybe I was just lucky.) Yes you were. Perhaps your garbage wasn't php code. I pasted the contents of PHP files by accident just a couple of times or three, and in one case I created tons of garbage empty files with funny names. God knows if I created some more files in some subfolders (unlikely) or if I deleted something.
(In reply to teo from comment #4) > There is, however, for the "replace file?" popup when you try to paste a > file where a file of the same name exist. Only in that case it's not called > "don't show again" but "replace all" or something like that. > You may object that only applies to the bunch of files you have selected to > paste right now. Exactly. > Then consider FileZilla: when you upload a bunch of files and there is a > clash, a popup appears that ask you what to do (overwrite, skip, etc), and > there is: > - a checkbox named "always use this action ..." > -- a nested checkbox "apply this only to the current queue" > And then all those settings can be found and reverted in the menus. > That's the ideal model. I don't know FileZilla. I wouldn't go as far as stating that this is "the ideal model", especially given my concerns which I've already mentioned. It's one possible model to consider. > Oh, well, then it sounds like something that won't happen in the near > future. Major bash releases happened every 2-3 years so far. More than 1 year has already elapsed since the last. Given that the current issue has been there forever in all terminals, waiting for another year or two for a nice solution is IMHO not that bad at all. Solving in bash has the advantage that it'll work in all terminals, not just gnome-terminal. Sure, this is gnome-terminal's bugtracker, but I do every once in a while contribute to other terminals as well, and would ideally prefer a cross-terminal solution for this problem rather than a g-t-specific one, if feasible. > I don't think Gnome Terminal should wait until that lands (just to > find out whether or not it actually solves the issue at hand) Just because I haven't looked at the details yet, I have no reason to assume that bracketed paste mode in bash fails to address the problem it was meant to address.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7561.