Why do I sometimes get 'sh: $'\302\211 ... ': command not found' in xterm/sh?

Question

Sometimes when I simply type a valid command like 'find ...', or anything really, I get back the following, which is completely unexpected and confusing (... is command name I type):

sh: $'\302\211...': command not found

There is some corruption going on I think. I don't use color in my prompt, I am using the Bash shell in POSIX mode as sh (chsh to /bin/sh and so on - $SHELL is sh).

What is going on and why does this keep happening? Anything I can debug? I think this is more of an xterm issue than sh, or at least a combination of the two.

Files, for context:

My /etc/profile, as distributed with 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

My /etc/shrc, which I created as a way to have sh parse some file on startup, when non-login shell. This is achieved using ENV variable set in /etc/environment with the line ENV=/etc/shrc:

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

My ~/.profile, I am launching X when logging in through first virtual tty:

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

My ~/.xinitc, as you can see I am using the system as a Virtual Box guest:

xrdb -merge ~/.Xresources

VBoxClient-all

awesome &

exec xterm

And finally, my ~/.Xresources, no fancy stuff here I guess:

*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

Since ~/.profile references among other things /etc/bash.bashrc, here is its content:

#
# /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 "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'

    ;;
  screen)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033_%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
    ;;
esac

[ -r /usr/share/bash-completion/bash_completion   ] && . /usr/share/bash-completion/bash_completion

I have no idea what that case statement does, by the way, it does look a bit suspicious though, but then again, who am I to know.

Answer 1

It happens when I first attempt to paste a command from the clipboard, Linux-style (Ctrl+Shift+V) and when that doesn't work, paste with the mouse. Apparently the keyboard combination inserts an invisible character before the command. The solution is simple, don't use the keyboard to paste, or if you have, press Backspace before pasting with the mouse.

Answer 2

The 0x89 provides a clue: with the default eightBitInput resource setting, xterm logically-ORs the input 8-bit codes to map them from 0-127 to 128-255:

• tab is ^I is 0x9, and
• ORed with 0x80 gives the odd 0x89.

You can fix the problem by not pressing your "meta" key at the same time you press tab.

The eightBitInput feature is old (dating from X11R4 in 1989), corresponding to the meta key feature. Much later, it was modified to work with UTF-8 in 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).

People using bash tend to assume that meta mode refers to prefixing things with an escape character, but have it backwards. See Alt-keys do not work in bash in the ncurses FAQ.

If you turn eightBitInput off, that would not solve this particular problem: xterm would send escapetab when you press metatab, which bash should object to...

Answer 3

This solve the problem:

setxkbmap -option "nbsp:none"

Answer 4

on my work machine I have a windows and use a git-bash CLI (mintty cygwin) to run commands I would normally run on linux

it happened to me that I got bash: $'\302\226curl': command not found after copying-pasting from a power shell window:

$ curl -v -F foobar
bash: $'\302\226curl': command not found

where was completely invisible to naked eye and looked like $ curl -v -F foobar

so I did remove every whitespace from before my command, like:

$curl -v -F foobar

note there are no more whitespaces between $

hope this helps someone, cheers

Answer 5

That's the UTF-8 encoding of the "CHARACTER TABULATION WITH JUSTIFICATION".

I guess you are using a specific keyboard or editor that uses this unusual character instead of the regular tab, which is normally ignored in shell command lines, or having a locale mismatch between the shell and the terminal emulator.

Answer 6

The shell is interpreting invisible characters and complaining about them, similar to what jlliagre was saying in his answer mentioning CHARACTER TABULATION WITH JUSTIFICATION.

If you have not typed any invisible characters, then the shell is getting some data elsewhere and misconstruing it as input. In other words, it's a bug. You should report it to the maintainers of the terminal emulator you are using.

(I realize this question is four years old now, but this may help someone else.)