I have a few Bash scripts on Windows and I sometimes copy them from Notepad++ into the WSL (CMD based) terminal emulator (TTY) to execute them.

The problem:

Trailing whitespaces (Green boxes in nano) are added to each script when I copy and paste it in WSL Nano via this command:

nano ~/script.sh

These trailing whitespaces chars aren't part of the script and are actually breaking its execution in Linux, hence shouldn't be in it.

The narrower the WSL TTY window is, the more carriage returns will be formed in pasting.

The script keeps containing these Green boxes when I open it with Nano, which seem not to strip away these characters when the file is saved (as should have been) so one could claim it's a bug in Nano, but in fact Executing dos2unix on the file also doesn't strip the trailing whitespaces.

enter image description here

enter image description here

The desired situation:

I desire that when copying and pasting Bash scripts (or any other data) from Windows into WSL Nano, no trailing whitespaces will formed in copying.

Further information:



If you try to reproduce in your WSL:

  1. Make sure to copy a script from Notepad++, which has Unix EOLs (LF), and includes only tabulation indents.
  2. Make sure your nano script file ends with .sh, so you will have Bash highlighting. If you still don't have it, try to SSH tunnel into a remote Ubuntu server if you have one and create a script file there the same way and then you should surly have this behavior.
  3. Either way make sure your Nano window is narrow (about 25-50 percent of the viewport) and that you paste a large portion of text).

As you stated, the issue arises from pasting text in a narrow window with Unix line-endings (LF).

Consider using the following AutoHotkey script to "type out" the clipboard text, letting Windows handle the newline characters.

SendMode Input  ; Recommended for superior speed and reliability.

; Upon pressing Ctrl+Alt+v
    ; SendRaw "types" the contents of the variable.  When it encounters either
    ; Cr (`r) or Lf (`n), it sends an "Enter", thus CrLf sends Enter twice.

    ; Replace any CrLf with Lf (ironic, I know), leaving the clipboard as is
    newClip := StrReplace(clipboard,"`r`n","`n")
    SendRaw %newClip%

As suggested to me by Benno Schulenberg of the Nano development team, adding the following code in the end of /etc/nanorc solved this problem:

bind ^J enter main

On the one hand, this will disable formation of Trailing whitespaces, and on the other hand, will add Line Feeds (LF chars) to the data copied from Windows, so it won't appear in one long row.

Read here for more data.


In the wide picture you show: ....

...cd maldetect-* &&␠|<-window boundary
bash ./install.sh

(the char before the vertical bar is HTML ␠ or unicode char U+2420(symbol for space).

That space SHOULD (HAS) to be there. If the window boundary wasn't there, then the line would be:

...cd maldetect-* && bash ./install.sh

If you didn't have the space, then && wouldn't have a space between it and the start of the 'bash' word -- which shouldn't hurt if you are running in bash, BUT that's just 1 example .. i.e. normally you would have a space between the double ampersand and the space.

If your spaces should be there, what might be causing your problems... hmmmm.... ARG! You are pasting this "into"... bash... Uh oh...

If you are pasting into bash, bash is 'buggy' (a matter of opinion) for pasting due to autocomplete changes made a few years ago. If you have any 'TAB's in your pasted text (yup, indenting), it will invoke bash's "autocomplete" function (I have complained about this but I was told that no one pastes text into bash... cough, cough) (complain on the 'bug-bash@gnu.org list' though I doubt it will be fixed anytime soon). When it invokes the autocomplete -- many time it will swallow the next character of your pasted text because it asks a question:

> ls <'complete-key' pressed>
Display all 199 possibilities? (y or n)

As a rule, this corrupts pasted text. This used to not be a problem for me, anyway, as my tabs are usually on blank-lines (because they are indenting code). It used to be the case there was an option to ignore code-completion presses on a blank line (@ start of line or when only blanks precede where it is pressed). This was changed to only ignore the completion char on empty command-lines (not an empty tty-line). Pasting multiple commmands into input usually are seen as bash as some sort of continued command -- NOT an empty command line. Needless to say, this causes alot of problems.

An imperfect solution for me was to remap the code-completion key from TAB to Backquote ("") (above tilde key). (same bug occurs if you have in your text, but for me, I use that alot less often than TAB). It's set in your home directory's '.inputrc' file which controls how 'readline' (used by bash to read lines, allow edit, etc), behaves. In particular, a section in my ".inputrc" has bash-specific config options:

$if bash
# use backquote as completion (yes, that's shift-'~')
# not ideal, but quickest "hack" to get mostly 
# transparent pasting (backquote isn't used nearly as often as TAB) 

Alternatives: 1) convert all your tabs to spaces before pasting, so TAB won't trigger command completion. 2) always write the text to a file and source (.) the file or make it executable and add '#!/bin/bash' on 1st line to make it a shell script.

Theoretically you should also be able to turn command completion off, but I use it too much, so have never bothered to try.

What I usually do now, is I edit the script in 1 window (usually gvim), and in the window where I started gvim, I run successive iterations of the script -- thus avoiding 'pasting'. Certainly wasn't my 1st choice, but bash's corrupting input by swallowing things after a complete-key have pushed me in that direction.

Note, if you report this as a bug, be prepared to offer a solution! ;-) This is the rub:

> ls \<carriage return>
>> [here people want to be able to hit 'TAB' and get an autocomplete of
    of the files in the current directory.  It looks like an empty line,
    but it is a really a continued command line from the previous line.

Same thing happens when you paste commands into bash... some will have tabs where you don't want them...

(P.s. Hope this helps and I didn't completely go off into left field, but when you mentioned 'pasting' and it looks like bash-script...and you mention using tabs (that get pasted in, as well), sounded like the exact same problem I ran into.

Using backquote as a complete key is a bit awkward at times, but, too often will have tabs in pasted text...oh well)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.