Por que às vezes recebo 'sh: $' \ 302 \ 211… ': comando não encontrado' no xterm / sh?

3

Às vezes, quando eu simplesmente digito um comando válido como 'find ...', ou qualquer coisa realmente, eu recebo o seguinte, que é completamente inesperado e confuso ( ... é o nome do comando que eu digito):

sh: $'21...': command not found

Há alguma corrupção acontecendo, eu acho. Eu não uso cores no meu prompt, estou usando o shell Bash no modo POSIX como sh ( chsh to /bin/sh e assim por diante - $SHELL is sh ).

O que está acontecendo e por que isso continua acontecendo? Qualquer coisa que eu possa depurar? Acho que isso é mais um problema xterm do que sh , ou pelo menos uma combinação dos dois.

Arquivos, para contexto:

Meu /etc/profile , conforme distribuído com o Arch Linux x86-64:

# /etc/profile

#Set our umask
umask 022

# Set our default path
PATH="/usr/local/sbin:/usr/local/bin:/usr/bin"
export PATH

# Load profiles from /etc/profile.d
if test -d /etc/profile.d/; then
        for profile in /etc/profile.d/*.sh; do
                test -r "$profile" && . "$profile"
        done
        unset profile
fi

# Source global bash config
if test "$PS1" && test "$BASH" && test -r /etc/bash.bashrc; then
        . /etc/bash.bashrc
fi

# Termcap is outdated, old, and crusty, kill it.
unset TERMCAP

# Man is much better than us at figuring this out
unset MANPATH

Meu /etc/shrc , que eu criei como uma forma de ter sh parse algum arquivo na inicialização, quando não fosse o shell de login. Isso é obtido usando a variável ENV definida em /etc/environment com a linha ENV=/etc/shrc :

PS1='\u@\H \w \$ '
alias ls='ls -F --color'
alias grep='grep -i --color'
[ -f ~/.shrc ] && . ~/.shrc

Meu ~/.profile , estou iniciando o X ao fazer login através do primeiro virtual tty:

[[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && exec xinit -- -dpi 111

Meu ~/.xinitc , como você pode ver, estou usando o sistema como um convidado da Virtual Box:

xrdb -merge ~/.Xresources

VBoxClient-all

awesome &

exec xterm

E, finalmente, meu ~/.Xresources , nada de fantasia aqui, eu acho:

*faceName: Inconsolata
*faceSize: 10
xterm*VT100*translations: #override <Btn1Up>: select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)

xterm*colorBDMode: true
xterm*colorBD: #ff8000
xterm*cursorColor: S_red

Como ~/.profile faz referência entre outras coisas /etc/bash.bashrc , aqui está seu conteúdo:

#
# /etc/bash.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

PS1='[\u@\h \W]\$ '
PS2='> '
PS3='> '
PS4='+ '

case ${TERM} in
  xterm*|rxvt*|Eterm|aterm|kterm|gnome*)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "3]0;%s@%s:%s
sh: $'21...': command not found
7" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"' ;; screen) PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "3_%s@%s:%s3\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"' ;; esac [ -r /usr/share/bash-completion/bash_completion ] && . /usr/share/bash-completion/bash_completion

Eu não tenho ideia do que essa declaração case faz, a propósito, parece um pouco suspeita, mas, novamente, quem sou eu para saber.

    
por amn 07.11.2013 / 13:54

6 respostas

2

O 0x89 fornece uma pista: com a configuração de recurso padrão eightBitInput , xterm logicamente-ORs os códigos de entrada de 8 bits para mapeá-los de 0-127 a 128-255:

  • A aba é ^I é 0x9 e
  • ORed com 0x80 fornece o 0x89 estranho.

Você pode corrigir o problema não pressionando a tecla "meta" ao mesmo tempo que pressiona a aba .

O recurso eightBitInput é antigo (datado do X11R4 em 1989), correspondendo ao recurso-chave meta . Muito mais tarde, ele foi modificado para funcionar com o UTF-8 no Patch # 183 - 2003/12/26 - XFree86 4.3.99.903 :

  • modify handling of eightBitInput resource in UTF-8 mode to translate the value into UTF-8. Otherwise an illegal UTF-8 code is sent to the application (report by Bram Moolenaar).

As pessoas que usam bash tendem a assumir que o meta-modo se refere ao prefixo de itens com um caractere de escape, mas o faz de trás para frente. Veja Alt-keys não funcionam no bash nas ncurses FAQ .

Se você desativar eightBitInput , isso não resolveria este problema em particular: xterm enviaria escape guia ao pressionar meta guia , que bash deve se opor a ...

    
por 12.09.2016 / 02:25
1

Isso resolve o problema:

setxkbmap -option "nbsp:none"
    
por 21.02.2017 / 09:01
1

Essa é a codificação UTF-8 da " TABELA DE CARACTERES COM JUSTIFICAÇÃO ".

Acho que você está usando um teclado ou editor específico que usa esse caractere incomum em vez da guia normal, que normalmente é ignorada nas linhas de comando do shell ou que possui uma incompatibilidade de localidade entre o shell e o emulador de terminal.

    
por 08.11.2013 / 10:44
0

Acontece quando eu primeiro tento colar um comando da área de transferência, no estilo Linux ( Ctrl + Shift + V ) e quando isso não funciona, cole com o mouse. Aparentemente, a combinação de teclado insere um caractere invisível antes do comando. A solução é simples, não use o teclado para colar ou, se tiver, pressione Backspace antes de colar com o mouse.

    
por 25.02.2018 / 10:48
0

na minha máquina de trabalho Eu tenho uma janela e uso uma CLI git-bash (mintty cygwin) para executar comandos que normalmente executaria no linux

aconteceu comigo que eu obtive bash: $'26curl': command not found depois de copiar e colar de uma janela do power shell:

$ curl -v -F foobar
bash: $'26curl': command not found

em que era completamente invisível a olho nu e parecia com $ curl -v -F foobar

então removi todos os espaços em branco de antes do meu comando, como:

$curl -v -F foobar

observe que não há mais espaços entre $

espero que isso ajude alguém, felicidades

    
por 24.04.2018 / 12:57
0

O shell está interpretando personagens invisíveis e reclamando sobre eles, semelhante ao que jlliagre estava dizendo em sua resposta mencionando TABELA DE CARACTERÍSTICAS COM JUSTIFICAÇÃO .

Se você não digitou nenhum caractere invisível, o shell está obtendo alguns dados em outro lugar e interpretando-o incorretamente como entrada. Em outras palavras, é um bug. Você deve denunciá-lo aos mantenedores do emulador de terminal que você está usando.

(Eu percebo que esta pergunta tem quatro anos agora, mas isso pode ajudar alguém.)

    
por 23.05.2018 / 21:54