Mon 28 Aug 2017 07:13:11 PM UTC, comment #11:
The same thing happens on Haiku too: when pasting multiple lines, the paste contains ^Js.
|
Fri 05 May 2017 09:39:07 AM UTC, comment #10:
See also bug #49176, for a different wording of the same problem.
|
Sun 30 Apr 2017 11:09:21 AM UTC, comment #9:
Deleted. It's anyhow better to not upload binary files: they can't be trusted. So I don't look at them anyway. :)
|
Sat 29 Apr 2017 09:30:08 AM UTC, comment #8:
Benno, please delete my original attached images (I have uploaded censored versions) as the originals have some sensitive information. Sorry for asking this, I've learned my lesson for the next time.
(file #40531, file #40532)
|
Sat 29 Apr 2017 01:11:13 AM UTC, comment #7:
Sure, I was wrong when I said "if someone copied from windows", and can only justify what you said --- WSL is better to send CR chars that nano already strips. I have notified the WSL development team on everything: https://github.com/Microsoft/BashOnWindows/issues/2006
|
Fri 28 Apr 2017 07:22:16 PM UTC, comment #6:
How is nano to know where you paste from? Nano just sees keyboard input. It would be better to teach WSL not to paste LFs, but to send CRs instead, just like X does.
Yes, it would have been nice if Pico had made the choice to make ^J a synonym (or near-synonym) of ^M, just like vim and emacs do, but it didn't, and we are stuck with that inheritance. But... once you know what the problem is, you can easily make ^J a synonym of ^M yourself, so... problem solved, I would say.
But maybe one day, when we implement bracketed paste mode (see bug #40060), this problem will go away -- at least, if WSL sends such "brackets", that is.
|
Fri 28 Apr 2017 04:33:58 PM UTC, comment #5:
I SSH tunnel with OpenSSH from WSL. I usually don't use Putty and in the reported case I also didn't use Putty.
I do use tmux usually (for logistical reasons).
After I added "bind ^J enter main" as you said, it worked fine.
I would humbly suggest to add this naturally to Nano or at least, adding some kind of conditioning that if someone copies from Windows, this bahvior would run automatically.
|
Fri 28 Apr 2017 11:08:39 AM UTC, comment #4:
One long row? Interesting! :) So the paste doesn't contain any CR characters at all -- it only contains LFs.
Then, instead of "unbind ^J main", you could put "bind ^J enter main" (without the quotes, of course) into your nanorc.
You could also try setting a different TERM variable. See:
https://lists.gnu.org/archive/html/help-nano/2017-04/msg00008.html
which is an answer to:
https://lists.gnu.org/archive/html/help-nano/2017-04/msg00003.html
Are you using Putty? And are you using something like tmux or screen underneath?
|
Fri 28 Apr 2017 09:50:14 AM UTC, comment #3:
Hi Benno and thanks. I putted unbind ^J main but now when I paste something into nano, it is pasted in one long row (i.e, the script I pasted appears in one long row)...
|
Wed 26 Apr 2017 08:37:11 AM UTC, comment #2:
If you see "green boxes", you are looking at trailing whitespace.
What happens when you paste something from a Windows machine into nano is: that that paste will contain DOS line endings (CR LF), and a LF character is a ^J, and the ^J makes nano "justify" the paragraph, which means that it will hard-wrap the lines to fit within window width minus 8 (by default), and hard-wrapping means it will insert a LF after the last space that fits within the mentioned width, which results in each line ending with at least one space. When you copy-paste the result back to Windows, those LF characters will be converted to CR+LF combos, and that's why you think that those trailing spaces are CR characters. They are not. An actual CR character in nano would be shown as ^M. You can verify that by typing in nano: Alt+V Ctrl+M, or: Alt+V Enter. Two characters, ^M, will appear on the screen, but the cursor will never be on the M, it will always jump over the M and sit on the ^, because in fact ^M is a single character: CR, 0x0d.
So, to prevent these ^Js that Windows sends from messing up your paste, put in your /etc/nanorc on the server the following line:
unbind ^J main
Then your pastes from Notepad into nano should pass without trouble. Is that the case?
|
Tue 25 Apr 2017 07:59:52 PM UTC, comment #1:
The problem is that when saving script, Nano doesn't strip away these CR characters or whatever these characters are.
|
Tue 25 Apr 2017 07:57:35 PM UTC, original submission:
I pasted a certain script into nano in a remote Ubuntu 16.04 environment to which I SSH tunneled from Windows10. I created the script file inside my remote system via:
nano ~/ses.sh && chmod +x ~/ses.sh && sh ~/ses.sh && rm ~/ses.sh
The pasted content was corrupted with CR characters - The number of CR chars generally rise up in direct correlation with the TTY window size (see images in advance).
Tabulations contribute to having even more CR chars as they push text right towards the TTY's edge.
In nano, any Green box character is actually a CR char (thus I conclude from copying the file back to Notepad++ and doing View > Show symbol > Show all characters there they displayed as CR characters. Saving the file in Nano in Nix format (I.e, I made sure DOS format is toggled off), doesn't strip these.
dos2unix also doesn't strip these CR chars out of the saved Nano file. Might these be of some "special kind" of CR chars?...
|