bugGNU nano - Bugs: bug #50879, when pasting from WSL, nano...

 
 

bug #50879: when pasting from WSL, nano interprets line-endings as justification commands

Submitted by:  None
Submitted on:  Tue 25 Apr 2017 07:57:35 PM UTC  
 
Severity:  3 - Normal Status:  Works For Me
Assigned to:  Benno Schulenberg <bens> Open/Closed:  Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

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.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 05 May 2017 09:39:07 AM UTC, comment #10:

See also bug #49176, for a different wording of the same problem.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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. :)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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)

Anonymous
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

Anonymous
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.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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.

Anonymous
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?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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)...

Anonymous
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?

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
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.

Anonymous
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?...

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #40531:  mdgql.png added by None (54KiB - image/png)
file #40532:  W5KYj.png added by None (33KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-08-28 bens Open/ClosedOpen => Closed
    2017-07-11 bens Summarywhen pasting from Windows, nano interprets line-endings as justification commands => when pasting from WSL, nano interprets line-endings as justification commands
    2017-04-30 bens Attached File#40509 => Removed
    2017-04-30 bens Attached File#40510 => Removed
    2017-04-30 bens Attached File#40508 => Removed
    2017-04-29 None Attached File- => Added mdgql.png, #40531
        Attached File- => Added W5KYj.png, #40532
    2017-04-28 bens StatusNeed Info => Works For Me
    2017-04-28 bens SummaryNano does not strip CR characters of some kind when the file is saved in Nix format => when pasting from Windows, nano interprets line-endings as justification commands
    2017-04-26 bens StatusNone => Need Info
        Assigned toNone => bens
    2017-04-25 None Attached File- => Added 1.PNG, #40508
        Attached File- => Added 3.PNG, #40509
        Attached File- => Added 2.PNG, #40510

    Back to the top


    Powered by Savane 3.3