WSL - Espaços em branco que estão sendo adicionados ao código Bash colado no CMD WSD TTY por tamanho de janela

5

Eu tenho alguns scripts Bash no Windows e às vezes eu os copio do Notepad ++ para o emulador de terminal (TTY) da WSL (baseado em CMD) para executá-los.

O problema:

Arrastar espaços em branco (caixas verdes no nano) são adicionados a cada script quando copio e colo no WSL Nano por meio deste comando:

nano ~/script.sh

Esses caracteres charmosos e em branco não fazem parte do script e estão, na verdade, quebrando sua execução no Linux, portanto, não deveriam estar nele.

Quanto mais estreita for a janela WSD TTY, mais retornos serão formados ao colar.

O script continua contendo estas Caixas verdes quando eu abro com o Nano, que parece não remover esses caracteres quando o arquivo é salvo (como deveria ter sido) para que alguém possa afirmar que é um bug em Nano, mas na verdade A execução de dos2unix no arquivo também não tira os espaços em branco finais.

Asituaçãodesejada:

EudesejoqueaocopiarecolarscriptsBash(ouquaisqueroutrosdados)doWindowsparaoWSLNano,nenhumespaçoembrancosejaformadonacópia.

Maisinformações:

link

link

Se você tentar reproduzir no seu WSL:

  1. Certifique-se de copiar um script do Notepad ++, que possui Unix EOLs (LF) e inclui apenas recuos de tabulação.
  2. Verifique se o seu arquivo de script nano termina com .sh , então você terá destaque em Bash. Se você ainda não tem, tente o túnel SSH em um servidor Ubuntu remoto se você tiver um e crie um arquivo de script da mesma maneira e então você deve ter esse comportamento.
  3. De qualquer maneira, certifique-se de que sua janela do Nano seja estreita (cerca de 25 a 50% da janela de visualização) e que você cole uma grande parte do texto).
por JohnDoea 25.04.2017 / 10:50

3 respostas

2

Como sugerido por Benno Schulenberg, da equipe de desenvolvimento da Nano, adicionar o seguinte código no final de / etc / nanorc resolveu este problema:

bind ^J enter main

Por um lado, isso desabilitará a formação de espaços em branco do Trailing e, por outro lado, adicionará Line Feeds (LF chars) aos dados copiados do Windows, para que ele não apareça em uma linha longa.

Leia aqui para mais dados .

    
por 04.05.2017 / 21:05
5

Como você afirmou, o problema surge de colar texto em uma janela estreita com finais de linha (LF) do Unix.

Considere o uso do seguinte script AutoHotkey para "digitar" o texto da área de transferência, permitindo que o Windows manipule os caracteres de nova linha.

SendMode Input  ; Recommended for superior speed and reliability.

; Upon pressing Ctrl+Alt+v
^!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%
return
    
por 28.04.2017 / 20:11
0

Na imagem ampla você mostra: ....

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

(o caractere antes da barra vertical é HTML) ou unicode char U + 2420 (símbolo do espaço).

Esse espaço deveria estar lá. Se o limite da janela não estivesse lá, então a linha seria:

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

Se você não tem espaço, então & & não teria espaço entre ele e o início da palavra 'bash' - o que não deve atrapalhar se você estiver executando no bash, MAS isso é apenas um exemplo .. ie normalmente você teria um espaço entre o double e comercial e o espaço.

Se os seus espaços devem estar lá, o que pode estar causando seus problemas ... hmmmm .... ARG! Você está colando isso "em" ... bash ... Uh oh ...

Se você está colando no bash, o bash é 'bugado' (uma questão de opinião) para colar devido a alterações no preenchimento automático feitas há alguns anos. Se você tem alguma 'TAB's em seu texto colado (yup, indenting), ele invocará a função autocomplete do bash (eu reclamei disso, mas me disseram que ninguém cola texto no bash ... cough , tosse ) (reclame na lista'[email protected] ', embora eu duvido que seja corrigido em breve). Quando invoca o preenchimento automático - muitas vezes ele engole o próximo caractere do texto colado porque ele faz uma pergunta:

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

Como regra, isso corrompe o texto colado. Isso costumava não ser um problema para mim, de qualquer forma, como minhas guias são geralmente em linhas em branco (porque eles estão recuando código). Costumava ser o caso de haver uma opção para ignorar pressionamentos de conclusão de código em uma linha em branco (@ início da linha ou quando apenas os espaços em branco precedem o local onde ela é pressionada). Isso foi alterado para ignorar apenas o caractere de conclusão em linhas de comando vazias (não uma linha tty vazia). Colocar múltiplos comandos na entrada geralmente é visto como um tipo de comando continuado - NÃO é uma linha de comando vazia. Escusado será dizer que isso causa muitos problemas.

Uma solução imperfeita para mim foi remapear a chave de conclusão de código do TAB para Backquote (" ") (above tilde key). (same bug occurs if you have em seu texto, mas para mim, eu uso muito menos do que TAB). É definido no arquivo '.inputrc' do seu diretório home que controla como 'readline' (usado pelo bash para ler linhas, permitir editar, etc), em particular, uma seção em meu ".inputrc" tem opções de configuração específicas do bash:

$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) 
TAB:tab-insert
"'":complete
$endif

Alternativas: 1) converta todas as suas abas em espaços antes de colar, então TAB não acionará a conclusão do comando. 2) sempre escreva o texto em um arquivo e fonte (.) o arquivo ou torná-lo executável e adicione '#! / bin / bash' na primeira linha para torná-lo um script de shell.

Teoricamente, você também deve ser capaz de desligar o comando, mas eu o uso demais, por isso nunca me preocupei em tentar.

O que eu costumo fazer agora, é editar o script em uma janela (geralmente gvim), e na janela onde eu iniciei o gvim, eu corri sucessivamente iterações do script - evitando assim 'colar'. Certamente não foi a minha primeira escolha, mas a entrada corrompida de bash engolindo coisas depois de uma chave completa me empurrou nessa direção.

Observe que, se você denunciar isso como um bug, esteja preparado para oferecer uma solução! ;-) Este é o problema:

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

A mesma coisa acontece quando você cola comandos no bash ... alguns terão abas onde você não os quer ...

(Ps Espero que isso ajude e eu não fui completamente para o campo da esquerda, mas quando você mencionou 'colando' e parece com o script bash ... e você mencionou o uso de abas (que também são coladas) ), soou exatamente como o mesmo problema que eu encontrei.

Usar o backquote como uma chave completa é um pouco complicado às vezes, mas, muitas vezes, haverá abas no texto colado ... ah, bem)

    
por 01.05.2017 / 06:19