10

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 follows below. It's something I created as a way to have sh parse some file on startup, for a non-login shell; it 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.

2
  • 1
    What is the output of ls -l /bin/sh? Also, please post your ~/.bashrc, the problem is probably there. What OS is this? Answers are often OS-dependent. Are you connecting to a remote machine via ssh or is this local? If remote, please post your ~/.profile and/or ~/.bash_profile if present.
    – terdon
    Nov 7, 2013 at 14:26
  • I have updated the question with all kinds of file content, I hope it suffices. Output of ls -l /bin/sh is lrwxrwxrwx 1 root root 4 Aug 25 12:06 /bin/sh -> bash*. I don't have a ~/.bashrc as I am running the Bash shell in so-called POSIX mode. No ~/.bash_profile either. Nov 8, 2013 at 8:29

9 Answers 9

15

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.

2
  • 2
    Perfect answer! helped me on git bash on windows
    – Moshe D
    Dec 5, 2018 at 21:10
  • Great.. :) It Working properly....
    – Ravi
    Jun 1, 2019 at 15:40
3

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

1
  • This helps. I changed the mitty terminal feture type from xterm to xterm-256 in the options settings of git-bash and the weird codes disappeared. Jul 2, 2019 at 14:06
3

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

2

This happened to me because I had a space in front of my actual command:

[admin@centos ~]$ ›  sudo systemctl status rsyslog
 -bash: $'\302\233': command not found
[admin@centos ~]$sudo systemctl status rsyslog
● rsyslog.service - System Logging Service

It must have been a tab character because when I copied and pasted it to this post, a strange character appeared

1

This solve the problem:

setxkbmap -option "nbsp:none"
1
  • 3
    It might be useful to say what this actually does, and how it fixes the issue.
    – Journeyman Geek
    Feb 21, 2017 at 14:33
1

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.

9
  • Sorry, I don't think I am following - am I using % somewhere? How? I am only using vim and locale reports all as en_US.UTF-8 except LC_ALL which is not set. Anything I can do to test your assumptions? Nov 8, 2013 at 10:11
  • @amn: I am almost sure it is not but the Unicode character "CHARACTER TABULATION WITH JUSTIFICATION". The code which bash shows is UTF-8 representation (C2 89) of the character (U+0089). I would check if you accidentally do not press some key (TAB?) or key combination before the problem occurs. If you have a suspicion, try the key combination here: od -ctx1. After typing the key sequence, press Enter and Ctrl+D. Nov 8, 2013 at 10:56
  • Indeed, it is not the common % but a control character that also have a graphic representation which is (per thousand vs percent). Is this happening during interactive shell sessions ? Are you using tab to autocomplete commands ? Is your keyboard providing a key ?
    – jlliagre
    Nov 8, 2013 at 11:12
  • No whatever it is, and the error I described happens seemingly at random. I am not using tab when that happens. No on the keybord, either. od -ctx1 tells me sh: $'\302\211\302\211\302\211od': command not found - I think we're getting somewhere! Nov 8, 2013 at 11:59
  • Is the issue still present when using a different terminal emulator ? When connecting remotely from another machine ?
    – jlliagre
    Nov 8, 2013 at 15:01
0

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

0

My problem was that I had strange characters in the command or the script.

What worked for me was to remove the extra lines at the end of my ~/.bash_profile file. There was also some white space and to be sure I executed unix2dos ~/.bash_profile.

I am using Git Bash with Mintty 3.4.3.

0

I have a solution that worked for me in Git Bash, probably works for more terminals if you find the corresponding settings.

You may need to enable usage of Ctrl Shift-shortcuts.

  1. Find your terminals Settings.

    In Git Bash, Right click the windows title bar and select Options...

  2. Go to Keys.

  3. Under Shortcuts, tick the checkbox for Ctrl+Shift+letter shortcuts.

  4. Click the Apply or Save button.

This is only a solution if you use Ctrl Shift C to copy terminal text, or any other Ctrl Shift combination.

It seems to insert, e.g. the \302\203, when using them. It was not the pasted value, or even the pasting shortcut itself that did this for me.

Your issue may be something else. Make sure your bash_profile PS1 configuration is well formatted, if you have any configuration there (e.g. to set custom/colored prompt, etc).

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.