I know what you mean; it can be a pain to watch what you copy/paste.  However, I don't think it is konsole's job to 'know' that the user wants to paste.

Generally when performing actions, there is either a moment of consideration before committing, or there is an easy undo. I don't think a universal undo for shell commands is likely in the near future, so I'd like to have some way to preview what is going to happen before it actually happens.

Only pasting up to the first newline is only one possible implementation. If Konsole could for example show the clipboard contents as a tooltip before I release the middle mouse button, it would solve my problem as well. Or like KSirc: warn when pasting multiple lines (KSirc pops up a confirmation dialog when pasting more than about 5 lines).

Well, there is actually a tip for this...

...that pressing Ctrl while selecting text will let Konsole ignore line breaks?

Works fine for me.

>...that pressing Ctrl while selecting text will let Konsole ignore line breaks? 

The question is, why this isn't the default. The current behaviour is somewhat annoying.

It all depends on what you are coping/pasting.  I find that the current default behavior is fine most of the time (copying command output).  

In reaction to #3: that feature controls the copying of text, not the pasting of text. My problem occurred when the selection buffer contained something different than I expected. The line that started with "*" came from a ChangeLog file in Kate, not from Konsole.

Comment #6: Then that is another bug; if you can reproduce it again, open a new bug report.

Ah, I think you misunderstood my original report. What I mean is that in another application I select some text and then in Konsole I press the middle mouse button to paste. That will insert all characters from the selected text into the stdin of the process inside Konsole (typically, a shell).

This is what I wanted to do:
- select (by holding the left mouse button) the file name of the file I want to remove
- switch to Konsole running bash
- type "rm "
- paste using the middle mouse button
- line reads "rm file_that_should_be_deleted"
- I review that command and press Enter to confirm it

This is what happened instead:
- selection buffer contains a line from a ChangeLog file in Kate (for example "* Added some new features:\n- Feature #1\n- Feature #2")
- switch to Konsole running bash
- type "rm "
- paste using the middle mouse button
- line reads "rm * Added some new features:" and is immediately executed because the newline was pasted as well
- bash also tries to execute "- Feature #1", which fails
- after the bash prompt it says "- Feature #2" now
- I find out I pasted the wrong text only after rm has deleted all files in the current directory

What I would like is to have some way to review what is pasted before the newline is sent. If I would have seen "rm * Added some new features:" before it was executed, I would have had a chance to cancel it.

Ahh, yes.  It is helpful to actually read the bug report.  Comment #3 deals with 'copying' and you are interested in 'pasting'

I have to ask why is it that when you 'copy' the filename (from Kate) is there a newline on the end?  When you copy from Konsole, you have to be sure just to select the filename (double-clicking is easiest perhaps).

Hmm, I understand what you want... most of this is just human error (User is unsure what in buffer).  I don't really see how this can be done.  Perhaps Ctrl+Paste removes ALL newlines?  or just the last one.

@ Kurt Hindenburg and Maarten ter Huurne:
It is common to copy and paste terminal commands from places like ubuntuforums.org, and it's easy to accidentally copy multiple lines of text. I've done it, and although it hasn't been disastrous yet, it could be.

For instance, say I want to see if upgrading my system from Kubuntu Dapper to Edgy Eft would create unmet dependencies. I copy "sudo apt-get dist-upgrade" from a how to, with the intention of pasting it in Konsole and inserting the "-s" option to simulate an upgrade. But I accidentally copy a part of the next line too, so when I middle click "sudo apt-get dist-upgrade" executes, I don't know how to stop it, and it completely trashes my computer!

Attributing the problem to "human error" doesn't mean we can't improve Konsole's behavior to make it less dangerous; we install seat belts in cars to make them safer, even though seat belts are only needed because of occasional "human error."

The simplest thing to do would be to filter text that is being pasted to replace newlines with semicolons. That way users could copy multiple commands, but not have them execute automatically. In the example above, for instance, middle clicking would only result in "sudo apt-get dist-upgrade; sud", assuming that part of the next line was copied.

Konsole could probably be patched in minutes. All that needs to be done is filter text that's being pasted and replace \n with ;.

> The simplest thing to do would be to filter text that is being 
> pasted to replace newlines with semicolons.

Yes, that is definitely easy to do, but that will only work in the shell.  If for example you are pasting a block of text into Vim from another source then it would require the user to go back and edit the text afterwoulds to reproduce the new lines.

One possibility might be to make pasting with a substitution of new lines for semicolons or backslashes the default, and add a "Paste Special..." menu option which allows the user to control the behaviour on a case-by-case basis.

I would suggest having a warning dialog that comes when you paste multiple lines:

"Are you sure you want to paste the multiple lines:
---
* Added some new features:\n- Feature #1\n- Feature #2
file_that_should_be_deleted
---
[ ] Don't ask me again
[Paste] [Cancel]"

About the semicolons idea: is it possible for Konsole to check whether or not a shell is running inside it? I guess it would not be too hard for local processes, but as soon as you run something under SSH, there is no way to see whether the program receiving the input is a shell or something else.

What Tom describes is similar to how Konversation handles multi-line pastes and that works well in practice. People who like to live dangerously can use the "Don't ask me again" checkbox, everyone else gets a chance to review their action.

> is it possible for Konsole to check whether or not a shell 
> is running inside it? 

No.  Konsole has no way of knowing what the terminal's foreground process will do with the pasted input.

I would perhaps take Tom's suggestion one step further.  Instead of just asking the user if they want to accept the paste "as is" or cancel it, give the user the option of substituting another character (eg. a semicolon) in place of a new line.

Good point about the semicolons not being good in non-shells. I like Roberts idea better thav Tom's, simply because dialog boxes are annoying for something as basic as copy & paste. What if we add some options to the context menu? Currently it looks like:

Set Selection End
Copy
Paste--------Shift+Insert
Send Signal ->
...

We could keep it that way except when there are newlines in the Clipboard buffer. Then we could change "Paste" to "Paste Multiple Lines" so that the user sees right away that there are newlines in the Clipboard. A submenu would be added with more options, so it would look something like this:

Set Selection End
Copy
Paste Multiple Lines-------- Shift+Insert
Advanced Paste -> (a submenu)
	Paste "as is"
	Paste first line only
	Convert newlines to /n
	Convert newlines to ;
	Add custom conversions...
Send Signal ->
...

The "Advanced Paste" would only be enabled when newlines are in the Clipboard buffer. The "Paste" command (Shift+Insert) would use whichever conversion you selected most recently. To protect first time users, the initial setting could be "Paste first line only" 

Agh.  The indenting got removed. I'll try again.

Copy
Paste Multiple Lines-------- Shift+Insert
Advanced Paste ->
=== Paste "as is"
=== Paste first line only
=== Convert newlines to /n
=== Convert newlines to ;
=== Add custom conversions...
Send Signal ->
...

Not decided upon the exact implementation, but this feature would be useful.  Confirmed.

FWIW, we solved the "Paste newlines" problem in Konversation (an IRC client) by introducing a paste dialog box that allows picking between going ahead with the paste, cancelling the paste or editing the paste. If the user choses to edit the paste he is presented with a text field that visualizes newline characters to remove them easily. The initial dialog box has an "Always do this" option, so one of the three variants can be defaulted to for the future (resetable via the "Warning Dialogs" prefs page in the settings dialog).

I think the use case of wanting to remove newline characters is common enough that it would be worth allocating a menu item, with shortcut to it.

(One thing to add, since I probably didn't make that clear: The dialog box described above is only triggered when the user attempts to paste multiple lines, obviously - which is something that you tend to want to avoid doing on IRC.)

Seems solved to me in 2.0 -- unless Ctrl is held, the final newline doesn't get pasted. 

Previous newlines do, but most of the time when you have multiple lines in buffer you do want to paste them all -- it'd be a PITA to always hold Ctrl when pasting. Or maybe it should be configurable?

Closing for now. Re-open if need be.

Configurable, please, if the default is going to be something other than "do exactly what I told you to without trying to guess if I really meant it". I don't like software that second-guesses me without my approval :-).

See http://permalink.gmane.org/gmane.comp.kde.devel.konsole/7907, I find this change obnoxious.

Now I'm confused, what should be configurable? The KDE3 behaviour is restored by simply holding Ctrl while pasting. I was thinking about making it possible to configure that behaviour to apply to all newlines, not just the last one.

And BTW, while this initially annoyed me as well, when I discovered the Ctrl-hold behaviour and thinking about it, it has started to make sense. It's really easier to hold Ctrl when you _do_ want to paste the newline, than mousing trying to catch the exact end of the line (so that the newline won't get selected) when you _don't_.

I don't know... *maybe* I'd get used to it eventually as well, but my knee-jerk reaction is that I don't want to have to hold some modifier key to make Konsole do what I meant. Philosophically, I feel like the default behavior should be for Konsole to do exactly what I told it to (giving me an option to change that is fine).

I think I'd rather see:
MMB - paste exactly what is on the clipboard
ctrl+MMB - if zero or one newline characters, paste w/o newline, otherwise ask what to do (i.e. give option to paste as-is, edit, cancel, replace newline with some other character, etc)

...and I suppose an option, even "on" by default, to flip the behavior would be OK.

The only time I ever have problems in KDE3 is when I'm wrong about what the clipboard contains, or when Konsole has added newlines to something that's not supposed to have them.

Conclusion: none, except that so far the change just rubs me wrong...

Please see Comment #8 for a detailed description of what caused me to file this bug. Leaving off only the last newline does not prevent the a wrong shell command being executed. It could definitely be a useful feature, but it's mostly unrelated to this bug.

What is most important to me, is that there will be a way to prevent a shell running in Konsole from executing something that I accidentally pasted without me pressing Enter. Whether that is done by pasting only until the first newline, by a confirmation dialog (a la Konversation) or in some other way does not really matter to me.

I also don't really mind what the default behaviour is. I personally feel that the defaults should be on the safe side, but if that annoys too many hardcore shell users, I have no problem toggling a checkbox in Konsole's config dialog.

Hm, my version of Konsole still executes terminating newlines, but I'm not using SVN. I agree with Mathew from the description that this "solution" is not as good as it should be. Konsole shouldn't secretly censor the buffer. Also, this ignore-the-last-newline thing doesn't solve Maarten's example (Comment #8), which was that of accidentally pasting the wrong buffer (which is very easy to do when using middle click to paste).

Here's my idea of the "ideal" interaction that protects newbies, allows users to double-check their clipboard content, and only annoys advanced users (like Mathew) once.

Mockup: http://img208.imageshack.us/my.php?image=konsolemulitplelineswx5.png
(Note: I didn't check the mockup for HUI guidlines compliance, but it makes sense to me.)

Newbies encountering the dialog the first time may say, "WTF? I pasted multiple lines?" They will get to see their clipboard contents (and possibly edit it) before hitting [Apply]. Users like myself and Maarten, who occasionally paste multiple lines intentionally, but are nervous about blindly executing clipboard content, will like the "Replace /n with ;" option with the "Remember my choice" option: I can paste multiple lines, double check to make sure I pasted what I wanted, and hit Enter to execute them all. Advanced users like Matthew may say, "What is this?", note that "Execute content as is" is selected by default, grumble about "dumbing down" software, check "Remember my choice" and hit apply, and they are never bothered again.

Oops, screenshot didn't show "Execute content as is" selected by default. It should have. http://img407.imageshack.us/my.php?image=konsolemulitplelinesvs2.png

> Conclusion: none, except that so far the change just rubs me wrong... 

I think the change was accidental as a by-product of re-writing the selection code.

> MMB - paste exactly what is on the clipboard 

That is exactly what happens.  Open a text editor, type in "ls" and create a new line.  Select "ls" and the new line and paste it into Konsole.

The change is that Konsole in 3.5 appears to append a new line character to the end of the text when making the selection if the rest of the line (beyond the last character) is selected.

I did not notice this behavior, so Konsole in 4.0 just copies the characters into the selection buffer until it gets to the last character on the line and then stops.  If you actually select one or more characters on the line below you can see that Konsole does actually include a new line in the right place.

> Here's my idea of the "ideal" interaction that protects newbies, allows users to double-check their clipboard content, and only annoys advanced users (like Mathew) once. 

It annoys me because I like the "Strip only terminating newlines" idea and it doesn't seem to offer a radio button for that which could then be combined with the "remember my choice" checkbox.

>The change is that Konsole in 3.5 appears to append a new line character to the end of the text when making the selection if the rest of the line (beyond the last character) is selected. 
> 
> I did not notice this behavior, so Konsole in 4.0 just copies the characters into the selection buffer until it gets to the last character on the line and then stops.  If you actually select one or more characters on the line below you can see that Konsole does actually include a new line in the right place.

Hmm... I thought this was intentional, since holding Ctrl gives back Konsole in 3.5 behaviour.

> Hmm... I thought this was intentional, since holding Ctrl
> gives back Konsole in 3.5 behaviour. 

The state of the Control modifier determines whether line breaks which Konsole inserts to wrap long lines of text are preserved in the copied output.  In other words, copying a block of text with Control pressed and pasting it will give output laid out exactly as it is seen in Konsole.  That it results in an extra new-line character at the end which can be used to paste-and-execute is a side-effect.  

I have to say, I personally prefer the new behavior and find it more predictable.  

Sigh... This is worse than I thought (possibly because I am suppressing the knowledge that Konsole does not actually copy what I want it to copy, due to finding it so backward).

Selecting past the end of the line should put that newline on the clipboard. Period. Doing otherwise is a break of behavior that affects *all* applications (e.g. copy/paste from konsole to kwrite), because suddenly konsole doesn't want to copy what you asked it to copy. MMB paste in my current build (trunk, maybe 1 week old), does seem to paste exactly what is on the clipboard, but ctrl-MMB *adds a newline*, which I think is just silly.

So, please make konsole *copy what I selected*. Maybe a better way is making it easier to not select the final newline (say, by making the hit area 5 chars or 50% of the remainder of the line, whichever is less, before the newline is also selected, and maybe making ctrl+select never select the newline). IMO this would be the "right" fix.

Revision 780739 fixes the bug so that the behaviour is consistent with Konsole in KDE 3.5 and other terminals.  In other words, dragging the cursor beyond the end of the text in the last line of output 'selects' the new line character as well.

Actually fixing this particular report requires a more deliberate approach.

> ctrl-MMB *adds a newline*, which I think is just silly. 

That is something which is deliberate and was added in prior to KDE 4 by someone else.  I presume the reason was so that the name of a command or a filename could be selected using double-click or triple-click selection (which doesn't include a new line at the end of the selection) and Ctrl+MMB paste explicitly adds in a new line character to do paste-and-execute.

>So, please make konsole *copy what I selected*. Maybe a better way is making it easier to not select the final newline (say, by making the hit area 5 chars or 50% of the remainder of the line, whichever is less, before the newline is also selected, and maybe making ctrl+select never select the newline). IMO this would be the "right" fix.

Not to get into a big argument, but I'm just as sick and tired of wasting time because it's difficult to select everything but the final newline and therefore, just as irritated by the original behaviour.

If they do change it back, I want a toggle to undo the downgrade.

> I'm just as sick and tired of wasting time because it's difficult to select everything but the final newline

Yes, I feel your pain (it bugs me too at times), which is why I suggested (and still do suggest) "making it easier to not select the final newline".

I think that is something of a related topic to controlling paste (which needs to know how to deal with multi-line, as well), but is an equally valid issue.

In fact, I think I'll... er, re-open bug 64295.

> It annoys me because I like the "Strip only terminating newlines" idea and it doesn't seem to offer a radio button for that which could then be combined with the "remember my choice" checkbox.

@ Stephan Sokolow: Hm, well, I was assuming that replacing newlines with semicolons would be enough, because I couldn't think of a situation where you would select multiple lines of text, and want all but the very last line executed. But I've got nothing against including such an option. I updated the mockup to include a "Ignore last newline" option.

Updated mockup - included new option and reworded others.
http://img143.imageshack.us/my.php?image=konsolemulitplelinesqm9.png

On a separate note, copying text from Konsole is a separate issue from pasting. However, I'm interested in that discussion as well - bug 64295 is the wrong place though, lets move that conversation to Bug 152774.

...except bug 152774 is *also* about pasting. Meh... I opened bug 158726.

Another reason why preview of pasted text might be interesting:

http://yro.slashdot.org/story/10/01/14/1818222/Tynt-Insight-Is-Watching-You-Cut-and-Paste?art_pos=1

This "Tynt" malware is (apparently...) able to change text you copied from a web page into something else while pasting it. For now, it is rather innocuous (only appends attribution), but it's only a matter of time before malicious web masters use it to append \nrm -rf $HOME\n to the selected text, making copy-pasting commands from forums a really dangerous undertaking.

Would it be possible for Konsole to distinguish a pasted newline from the keypress of the "Enter" button?

If so, Konsole could buffer (delay the submission of) all input (pasted or not) until the user physically applies force to the Enter button. Until that, the user may edit the multiple lines (using arrow keys as in a text editor). As a bonus, a different keypress can be invented to insert a newline inside the text without submitting (e.g. Ctrl+Enter, just like instant messaging).

Dear sirs, I was directed here from the mailing list. 

On the mailing list I had proposed a different way to tackle this problem, which I think is better.
After reading the comments in this bug page I have also re-elaborated a bit, so here it is, improved version:

The Konsole-devel team should create a new (configurable) hotkey for "paste without newlines".  This one should be used preferably by most users, while the normal "paste" hotkey, which would retain its current behaviour, would be used only when users are "really really sure" of what they are doing. [*]

In order to "be really really sure", prior to use the normal "paste", the users could e.g. make a test paste onto a text editor to check what the buffer really contains. But the need to do this would be very rare because the "paste without newlines" can do most things already.

For the internal behaviour of "paste without newlines" hotkey, I think that the best approach is probably to replace a newline with the sequence "; \\n", that is: semicolon, space, backslash, newline. If there is a \r\n probably the \r should be removed in advance, and then the above replacement for \n should be performed. Also tabs at the beginning of lines should be removed or better replaced with spaces (see below).

This replacement sequence has the advantage that it can be used to paste a multiline script into vi or nano without altering the meaning [**], but it can also be used in bash for obtaining something visually very similar to what is copied (so that the user can immediately see whether he has pasted the correct thing or not without re-parsing with the eyes), and which also maintains the meaning, but does not execute automatically.

However, since I foresee that the decision of the exact newline replacement sequence can cause a flame-war and also seems to be an important matter because a wrong decision can drop the usage of the new hotkey from 99% to 85%... (=15 times more chances for a mistake) I can suggest that the replacement sequence for that hotkey should be made customizable.

If you want to provide a customizable replacement sequence for this "paste without newlines" hotkey, I recommend the following two fields to be put in the Profiles-configuration:
- field#1: characters to be removed
- field#2: characters which should replace the newline

Pay attention now: you might think deciding field#1 be easy, while field#2 be more difficult, but it's not so. Deciding field#1 is actually more difficult.

In field#1 I believe most people would want "\r\t" so to remove both CR and TAB (each of them placed anywhere on the string, even multiple times). The reason for tab, *VERY IMPORTANT*, is that if a line starts with \t (can happen when copying loops from bash scripts) bash starts the command completion routine and this wreaks havoc on the multiline script. Execution would *NOT* be correct.

To understand what I mean, paste this mini-script into bash (I don't know if this bugzilla allows me tabs... the second line has 2 tabs in front of it, please reproduce it in Kate):
#------start------
echo foo; \
		echo bar; \
echo baz
#------end------
output == "foo\nbaz\n" and no "bar" output, i.e. it doesn't work.
That's why you also need \t deletion or replacement with spaces.

*BUT* users of Python wouldn't probably want "\t" to be there, because in Python the tabs have a meaning and should be kept. 
However in python interactive shell it can still be very difficult to use this hotkey effectively for multiple lines, due to the newlines and indentation both being basically required by the language, so Python users might give up on trying to use the "paste without newlines" when in python interactive shell, and use the standard "paste" there. And hence again they might still want \t to be present in field#1 for a better use within Bash.

A better handling of \t would be replacing that with a customizable number of spaces, and only if it is at the beginning of a line. This requires a separate customization field, but would retain the visual indentation and thus enhance the similarity of the pasted content to the original one, so that the konsole user can more easily check that what is being pasted is really what s/he intended.

In field#2 I would put "; \\n" so that the script retains its visual shape, but other people might want just "; " so as I said there is no one size fits all. (please note that the second version still doesn't improve python interactive shell use)

So this is my vote to make it customizable. 
Or if you really don't want to, my vote goes for a fixed configuration of: field#1="\t\r" and field#2="; \\n".


Regarding the paste via middle-click, I have disabled it via xmodmap (xorg). It was too dangerous to have two buffers imho, too error-prone, too many times I was pasting from the wrong one, and with the newlines enabled it would go executing immediately. However if you would map the middleclick to the algorithm of "paste without newlines", but using text from the x11's selection-buffer, I would re-enable it.


[*] In order to make the former the default, you could set the keys so that from the next version of konsole the default keys used for "paste" (shift-ins) now become the default keys for "paste without newlines"; and standard "paste" hotkey now gets a more complicated set of keys by default such as alt-shift-ins.

[**] I would discourage the use of the standard "paste" hotkey even in vi/nano, or you will learn to use it, and you will eventually use it also in bash by mistake. So the new "paste without newlines" should try to replace "paste" as much as possible in most environments, such as at least bash and vi/nano, possibly also python interactive shell, etc.

Thank you

(in reply to comment #41)
Sounds awfully complicated and prone to breakage (just think about continuations which don't involve semicolon such as pipes or quoted strings, or non-shell text altogether)

Please, whatever you do, don't throw away the "normal" copy-paste, and keep it easily accessible (maybe using a checkbox somewhere in the config "I know what I'm doing")

A safer alternative would be:
- if single newline at end: just drop it
- if multiple newlines: on paste, pop up a dialog with "text contains multiple lines, are you sure to proceed?" along with first couple of lines and last couple of lines.

Transparently changing newlines into semicolons could potentially introduce more problems than it solves (pipes,...) and makes the pasted text look like a garbled mess.

As for the point of "knowing what you are pasting": a good start would be to fix the handling of "loss of selection" event. In the old days, when a window lost the selection, it would unhighlight it. Some rare applications, such as xterm, still do, and this is good.

But almost all the other apps (and konsole too...) have lost this ability over the last few years, and continue showing a selection long after they've lost it. This is confusing, and dangerous, because you cannot trust what you see. Usually, it's not that much of an issue because smart user select only just before pasting, but imagine what happens if you're interrupted in the middle of something, and come back to your work later on.

Alain, you are right about the pipe followed by (whitespaces and then) a newline, I wasn't aware that it was possible, so this is to be handled separately. 
Also newline within a string should be handled differently, but actually this one is not easy because its behaviour depends on whether there is already an opened doublequote in the part of text before the paste point. So let's disregard this (people can still use the normal paste).
However the substitution proposed by many (newlines --> semicolon) makes sense in most cases.

I maintain my proposal of an additional "paste without newlines" (or "paste special") hotkey.

I think that such new hotkey could be connected to either a confirmation dialogbox showing the text being pasted, as you proposed (especially useful if it shows the FULL text and it is editable), or a predetermined substitution algorithm, as I proposed. The choice between the two should be configurable from the Profiles-configuration.

The old normal "paste" hotkey should still be accessible.

I update my "substitution sequence" proposal:
- If there is only one newline at the end of the text being pasted, remove that. 
		End.
- Else:
	- removal of \r from everywhere
	- replacement of \t from everywhere where with a customizable number of 
		whitespaces, so to not trigger bash completion which would break everything. 
		(I have now noticed that bash substitution happens everywhere and not 
		only at the start of a line)
	- replacement of \n with "; \\\n" (semicolon, whitespace, backslash, newline) 
		EXCEPT when the last nonblank-nontab charachter of the line is a pipe. 
		For the pipe case, replace \n with " \\\n" (space, backslash, newline)

This substitution algorithm should also be available in the confirmation dialogbox, in a button called like "replace newlines" or "sanify code" or similar.

> Alain, you are right about the pipe followed by (whitespaces and then) a
> newline

The pipe was only one example. Same thing would happen with && , with ||, with open parenthesis, and probably other cases...

>  (especially useful if it shows the FULL text and it is editable)

The reason why I proposed to only show the first few and the last few lines was to cover the case where pages and pages have been selected, which would not be easily showable in a dialog box. The main goal here would not be to allow detailed examination of the text to be pasted, but rather to spot gross confusions (such as, user selecting a small amount of text from a web page, but then slipping with the mouse and accidentally selecting something else)

> The old normal "paste" hotkey should still be accessible.

Indeed, this is very important for power users

Devs, please look at this: http://www.reddit.com/r/netsec/comments/1bv359/dont_copypaste_from_website_to_terminal_demo/

Scary indeed...

However, in many situations copy-pasting newlines is useful. Maybe instead just pop up a warning if a newline in comprised in the string, with a possibility to allow/refuse the paste? Or make it configurable (always refuse, warning/confirmation, always allow).

Also, please note that this article contains an even scarier prospect: copy-pasting escape characters, allowing the pasted text to break out of insert mode in vim. IMHO, copying escapes should never be allowed.

Also, tabs can cause problems, as they may exist on web pages or text files for formatting reasons, but when copied, they'll trigger tab completion, which is annoying, even if there is no ill intent. Optionally, konsole should be able to replace a pasted tab with 8 spaces to prevent this.

But back to the subject: really, the _browser_ should warn when making a selection containing invisible or off-screen text. And this warning should not be overridable by javascript. And in general, as of late, browsers (and other programs) have become very sloppy with selections (such as not showing when the selection has been lost), which could lead to similar problems.

@Alain: I think that cribbing from konversation's UX (and even UI code) for this would give us a good starting point. Take a look at their UI and tell me if you agree.

*** Bug 321196 has been marked as a duplicate of this bug. ***

The fish shell is immune to this!

Currently, it replaces newlines with \n, but proper multiline command editing seems not too far fetched:
https://github.com/fish-shell/fish-shell/issues/821

*** Bug 318524 has been marked as a duplicate of this bug. ***

(In reply to comment #47)
> @Alain: I think that cribbing from konversation's UX (and even UI code) for
> this would give us a good starting point. Take a look at their UI and tell
> me if you agree.

I was thinking about Konversation while reading this, and I would love to see this in Konsole!

Since this bug https://bugs.kde.org/show_bug.cgi?id=318524
is a duplicate of this one, I copy & paste the solution proposal

Recommended behaviour:

As the user uses "Paste", the clipboard is appended to an initially empty konsole-session owned buffer asserting that the last character is LF (append if none there). If the buffer was empty:
Scan the buffer till the first LF, send that part to shell (LF excluded) and delete from buffer (LF included). This step is called dequeue.

As the user sends Enter/Return to shell and the buffer is not empty: dequeue - this should execute the first line and at the same time have the next line sent to shell, but without the LF so it won't execute immediately.

On user request the buffer is cleared.

This improves security, because the user is able to review a command he copied from an online tutorial which (if malicious) might contain commands which were not visible as it was copied. (Secure)

If the command contains parts which should be modified to user needs, the user is now able to. (Flexible)

After execution of a command, the user is able to review its execution and to decide whether to proceed. (Reviewable)

I came to this bug because it closely matches my observation.

In Konsole 19.12.3 there was a popup filter when pasting text into Konsole, I'll attach an image of it to this bug report.

In Konsole 20.04.0 the filter popup quit working and would leave text I pasted into vim via Konsole double spaced, so two spaces would be come four leaving a bunch to time wasted to remove the extra spaces.

I'm usually copying from Zim Wiki to vim many times a day sometimes dozens and it gets old fast.

So please return the Konsole filter popup back to the Konsole 20.04.x and keep it working, that filter is fantastic.

Thank you for your time;

George

Created attachment 128263 [details]
Image shownig the Filter popup working in konsole 19.12.3

Apparently, some applications such as Firefox or Sublime Text tend to write to the clipboard using CRLF line endings. That wasn't really an issue when copy-pasting into Konsole since a popup would show up letting us to filter those extra CR characters if one wanted to.

Then, last year in November, a couple of patches changed the filter behavior and one of those added the CR character to a whitelist [1], thus disabling the popup notification for this scenario.

From a somewhat related bug report [2], a similar issue affected Firefox when running on Wayland, in which the root cause was Gtk because of the way it normalizes the clipboard content depending on the mime type [3]. However, I am not sure if the same applies here because I use X11 instead, so at least it is not the same situation.

Anyways, like George suggested, it would be nice to have the popup back, even if it is just a workaround for the time being.

Thanks,

Felipe

[1] https://cgit.kde.org/konsole.git/commit/?id=5e142c9dadc8a00d7017c6f60603798bcaa6ae85
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1547595
[3] https://gitlab.gnome.org/GNOME/gtk/issues/2307

Thank you Felipe.

With your link to the commit, I made a quick patch to fix my problem, it applies to konsole 20.04.1 and I'm able to paste into vim without double spaces.

I'll attach the patch to this bug if anyone wants it.

George

Created attachment 128848 [details]
Remove newline character from the whitelist.

Nobody mentioning bracketed paste?
https://web.archive.org/web/20190806043517/https://cirw.in/blog/bracketed-paste

That's the final solution to all world problems, and Konsole supports it. Just use a shell that also supports it, like fish. Then, you can paste multiline strings in complete safety and bliss, and they won't execute until you physically hit enter.

(In reply to Andreas Nordal from comment #58)
> Nobody mentioning bracketed paste?

I had never heard of it until you mentioned it.

I enabled it in ~/.inputrc and now bash indeed waits for an explicit Enter before executing anything. This is awesome!

Why isn't this enabled by default in shells and/or readline?

(In reply to Felipe Veas from comment #55)
> Apparently, some applications such as Firefox or Sublime Text tend to write
> to the clipboard using CRLF line endings. That wasn't really an issue when
> copy-pasting into Konsole since a popup would show up letting us to filter
> those extra CR characters if one wanted to.
> 
> Then, last year in November, a couple of patches changed the filter behavior
> and one of those added the CR character to a whitelist [1], thus disabling
> the popup notification for this scenario.
> 
> From a somewhat related bug report [2], a similar issue affected Firefox
> when running on Wayland, in which the root cause was Gtk because of the way
> it normalizes the clipboard content depending on the mime type [3]. However,
> I am not sure if the same applies here because I use X11 instead, so at
> least it is not the same situation.
> 
> Anyways, like George suggested, it would be nice to have the popup back,
> even if it is just a workaround for the time being.
> 
> Thanks,
> 
> Felipe
> 
> [1]
> https://cgit.kde.org/konsole.git/commit/
> ?id=5e142c9dadc8a00d7017c6f60603798bcaa6ae85
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1547595
> [3] https://gitlab.gnome.org/GNOME/gtk/issues/2307

Pasting from a GTK app (e.g. Firefox) resulting in double newlines between text blocks is bug 421480.

I found that if you clear konsole with (ctrl + shift + k) bracketed-paste doesn't work anymore in the now-cleared terminal. Unless you reset the terminal.

CCing Jonah, since he refactored the copy&paste code recently.

I've noticed and found quite annoying the new bracketed paste feature.

I'm not sure it's a proper fix either, since pasting malicious data into non-shells could still be a threat. Surely every single CLI application can't be expected to interpret bracketed paste control characters?

Konversation has, for a long time, had a nice behaviour where it displays the clipboard in a separate dialog for review prior to actually pasting. It only does this for multi-line pastes, since it can guarantee single-line pastes will be harmless (it remains in Konversation's own line entry box).

An ideal solution would probably involve untrusted sources marking the clipboard as such - but I'm not sure programs can reliably determine if they are trusted or not (it's entirely possible a README shown in Konsole might be considered untrusted, for example).

Bracketed-paste isn't a Konsole feature, it's a BASH feature (and has been available for a very long time, it's just that BASH enabled it by default in recent versions).

Created attachment 147151 [details]
xfce4-terminal confirm paste

The perfect solution is to trigger a pop-up when something is pasted on the terminal and has newlines, just like xfce4-terminal is doing.
To make up for the annoyance this might give some users that don't like this, just add a tick box to not show the pop-up again next time.
Also there's other terminal applications that are doing the same, like mobaxterm on Windows land.
See https://activereach.net/wp-content/uploads/2020/02/Annotation-2020-02-11-091401.png

Created attachment 147152 [details]
Konsole prevents pasting control characters

In fact, Konsole already prevents pasting of control characters. See the added attachment.
A similar pop-up could be used to prevent pasting of newlines.

(In reply to Gabriel Fernandes from comment #65)
> Created attachment 147151 [details]
> xfce4-terminal confirm paste
> 
> The perfect solution is to trigger a pop-up when something is pasted on the
> terminal and has newlines, just like xfce4-terminal is doing.
> To make up for the annoyance this might give some users that don't like
> this, just add a tick box to not show the pop-up again next time.
> Also there's other terminal applications that are doing the same, like
> mobaxterm on Windows land.
> See
> https://activereach.net/wp-content/uploads/2020/02/Annotation-2020-02-11-
> 091401.png

Not only that, but konsole already shows a popup if you try to paste a lot of content, so there is a precedent :)

> I've noticed and found the new bracketed paste feature quite annoying.

What's annoying about that? I would for sure not prefer a popup. That's making a problem out of a non-problem.

In fish, when you paste the wrong thing, irrespective of linecount, just press Ctrl+C to not execute. Alternatively, hold down Ctrl+U to erase every line of it. I don't know of a multiline erase, though.

Isn't the ideal solution rather that multiline strings just aren't any special, surprising, dangerous or annoying? That's status quo.

If the program running in the terminal doesn't support bracketed paste, though, that would be when a popup is warranted.

Created attachment 149615 [details]
attachment-11959-0.html

Do you know if there’s a way to ask the program if it supports bracketed
paste? If not, Konsole behavior is correct.


On Sat, 11 Jun 2022 at 13:14 Andreas Nordal <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=89299
>
> --- Comment #68 from Andreas Nordal <andreas_nordal_4@hotmail.com> ---
> > I've noticed and found the new bracketed paste feature quite annoying.
>
> What's annoying about that? I would for sure not prefer a popup. That's
> making
> a problem out of a non-problem.
>
> In fish, when you paste the wrong thing, irrespective of linecount, just
> press
> Ctrl+C to not execute. Alternatively, hold down Ctrl+U to erase every line
> of
> it. I don't know of a multiline erase, though.
>
> Isn't the ideal solution rather that multiline strings just aren't any
> special,
> surprising, dangerous or annoying? That's status quo.
>
> If the program running in the terminal doesn't support bracketed paste,
> though,
> that would be when a popup is warranted.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

> Do you know if there’s a way to ask the program if it supports bracketed paste?
The program tells the terminal:

    printf "\e[?2004h"  # Enable bracketed paste
    printf "\e[?2004l"  # Disable bracketed paste

It's initially off (because the terminal can't assume the program supports it).
Konsole apparently understands this (whereas weston-terminal does not).
I can verify this by running those commands in bash (which doesn't enable it after every command, at least by default).

Apropos terminal support:
> Bracketed-paste isn't a Konsole feature, it's a BASH feature
It's necessarily a protocol between the two: Something has to bracket the paste, and it's the terminal (that implements pasting) that has a chance to distinguish it from the enter key.

(In reply to Gabriel Fernandes from comment #61)
> I found that if you clear konsole with (ctrl + shift + k) bracketed-paste
> doesn't work anymore in the now-cleared terminal. Unless you reset the
> terminal.

I wondered why was this bug report still open, but ouch, could reproduce this problem.

For other complaints, I'm generally not sure there will be ever a perfect balance between convenient and secure text passing when the whole communication is in a stream of text including control data.
Regarding manual input sanitization, I'm not sure it's necessarily the terminal's responsibility to fight everything that may be misinterpreted. For example I'd deem it a quite important security improvement if programs would need a privilege to interact with the clipboard if they are not actively being interacted with, so if Klipper would be checked while Konsole is in the foreground, there would be an implicit guarantee of not having a TOCTOU race condition of the clipboard getting changed after check but before paste. Also if the input would be copied from a trusted program, and nothing else would be interacted with before switching to Konsole, then the clipboard content should be known good data this way. May not be feasible on X11, but I do hope that Wayland is headed this way.