Parece que você atingiu este bug:

https://lkml.org/lkml/2013/7/25/205

readline() aciona inadvertidamente um caminho de recuperação de erro quando pastas maiores que 4k ultrapassam o buffer de disciplina de linha. O caminho de recuperação de erro descarta a entrada quando o buffer de disciplina de linha está cheio e operando no modo canônico e nenhuma nova linha foi recebida. Como readline() altera os termios para o modo não canônico para ler a linha caractere a caractere, o buffer de disciplina de linha pode ficar cheio e, quando readline() restaura os termios de volta ao modo canônico para o chamador, o agora cheio o buffer de disciplina de linha aciona a recuperação de erro.

Ao alterar termios do modo não canônico para o modo canon e o buffer de leitura contiver dados, simule um push EOF sem o DISABLED_CHAR no buffer de leitura.

Importante para o problema readline(), os termios podem ser alterados de volta para o modo não-canônico sem que ocorram alterações no buffer de leitura; ou seja, como se a mudança de termios anterior não tivesse ocorrido (desde que nenhuma leitura interveniente tenha ocorrido).

Foi aplicado ao kernel em 10 de dezembro de 2013, que era o kernel linux 3.14. Você está usando alguma distribuição Linux mais antiga que essa? Qual é a sua distro? Você provavelmente substituiu seu caminho real para o arquivo, então não consigo contar os caracteres. Você poderia fazer:

for ((a=1; a<20; a++)); do echo "mv /long/path/to/file$a /longer/path/to/file$a"; done|wc -c

com seus caminhos reais - seria algo bem próximo de 4k? Em caso afirmativo, o bug acima provavelmente é seu.

Se sim, responda às suas perguntas:

• é um problema relacionado ao terminal (Xterm no meu caso)?

não

• o copiar/colar ocorre por ssh: isso gera ou amplia o problema?

não

• é um problema relacionado ao bash no servidor?

Não e sim - isso não é um bug no bash ou em qualquer lib usada pelo bash. Bug está no kernel.

• Isso não aconteceria com outro shell?

Pode ser, se o shell não estiver usando readline. Como zsh.

Em relação às questões relacionadas 'como colar vários ...' não parece relacionado ao seu problema - a causa disso é que algum aplicativo pode ler os comandos que você colou. O exemplo mais conhecido disso é o ssh, se você executar o comando ssh no servidor remoto. Mas, como você perdeu apenas partes das linhas, é improvável no seu caso.

Segunda pergunta 'Comandos colados no terminal ...' feita em 25 de setembro de 2013, naquela época o patch não existia e isso definitivamente parece um bug que você tem e um bug que eu sou do kernel, eu suspeito.

Como verificar com certeza? cole a saída de uname -a aqui.

Problema em mãos

Você deseja saber por que suas linhas de código que são copiadas e coladas são truncadas.

Analisei seu problema e descobri que o Bash normalmente tem um limite de linha por padrão. Este é provavelmente o seu problema. No entanto, os exemplos que você fornece mostram linhas sendo truncadas em comprimentos diferentes. Vou tentar o meu melhor para quebrar isso.

Solução

1. É um problema relacionado ao terminal (Xterm no meu caso)?

É bem possível que seja, mas isso se deve às limitações de um ambiente Bash padrão, não xterm. (A menos que você tenha alterado muitos padrões de xterm)

Estou fazendo referência aos seguintes posts que oferecem soluções para aumentar o comprimento da linha para reduzir o truncamento. Esta resposta de troca de pilha U&L abrange a alteração do tamanho da janela para corresponder ao que seu emulador de terminal espera. O usuário saketrp oferece isso como uma solução para garantir que o tamanho da janela seja interpretado corretamente pelo seu terminal.

Se você estiver usando o bash, pode tentar isso.

$ shopt checkwinsize

Se você não conseguir

checkwinsize    on

Em seguida, ative-o com

$ shopt -s checkwinsize

Em seguida, tente executar outro comando (como ls) ou redimensionar a janela uma vez, o acima funciona para mim todas as vezes.

Para sistemas Redhat particularmente, o problema geralmente é causado pela configuração incorreta de ~/.bashrc para não chamar /etc/bashrc. Normalmente, o bash carrega ~/.bashrc que deve chamar /etc/bashrc, que por padrão contém shopt -s checkwinsize.

No entanto, isso afeta apenas as interpretações do tamanho da janela e não o comprimento real da linha. Usando as informações fornecidas nesta postagem do AskUbuntu, se você shoptconfigurou corretamente, pode adicionar a seguinte linha ao seu .bashrcpara aumentar o comprimento da linha.

COLUMNS=250

e corra source .bashrcpara atualizar seu perfil Bash.

2. o copiar/colar ocorre por ssh: isso gera ou amplia o problema?

Eu diria que isso é parte do problema, se não parte da causa raiz. As soluções alternativas que você vinculou são soluções sólidas para evitar que isso aconteça.

Sugiro que se você precisar copiar e colar um conjunto de comandos (precisa usá-los mais de uma vez?) Crie um script Bash do conjunto de comandos. Em seguida, use scp, sftp, curl, e-mail ou qualquer outro método para transferir arquivos remotamente que você deseja usar.

Isso evita totalmente o problema de truncamento, conforme descrito nas soluções alternativas vinculadas, e você pode até criar um script e/ou transferir os scripts para vários servidores de uma só vez.

3. É um problema relacionado ao bash no servidor? Isso não aconteceria com outro shell?

Como mencionado anteriormente, sim, isso pode ser um problema com os limites de linha definidos pelas configurações do perfil Bash. Outros shells podem não ter esse problema, mas eu só estou familiarizado com o Dash/Bash. No entanto, se forem servidores de produção ou sistemas legados, nem sempre funcionará bem se você começar a alterar as variáveis ​​de ambiente. Não quer dizer que não seja impossível, no entanto, há riscos se certos pacotes/software/scripts anteriores/cronjobs dependerem do Bash como shell padrão, alterar isso pode ter consequências.

Novamente, sugiro que você crie um script dos comandos que deseja executar e transfira-o para o servidor remoto para ser executado lá para solucionar esse problema.

Conclusão

O motivo pelo qual seus comandos estão sendo truncados depende do seu ambiente, das configurações do perfil Bash, das configurações do emulador de terminal e do método de copiar e colar comandos. Existem soluções alternativas como você apontou e sugiro que você as use em conjunto com o script para evitar o problema. Também estou incluindo um link para uma página de xtermmanual para que você possa ver se há configurações ou opções adicionais que você pode alterar.

Por favor, comente se você tiver alguma dúvida ou problema com esta resposta. Agradeço o feedback para corrigir quaisquer equívocos e melhorar minhas postagens. Posso atualizar minha resposta conforme necessário.

Boa sorte!

Sugiro usar gzip e base64 para copiar o comando de um terminal para outro. Se o problema vier do metacaractere ou da expansão da guia, você deve resolvê-lo dessa maneira.

Exemplo:

[root@server-one ~]# cat << __EOF__ | gzip | base64
mv /long/path/to/file23 /longer/p
mv /long/path/to/file24 /longer/path
mv /long/path/to/file25 /longer/p
<other commands>
__EOF__

Em seguida, copie o resultado codificado para

[root@server-two ~]$ base64 -di | gunzip | bash
<insert your base64-encoded and send with control-d>