I just moved to Arch Linux with KDE a week ago. Everything worked well until I installed ibus-unikey and ibus-qt, after that, whenever I open konsole, this error appears:

bash: #: command not found

I doubt that # is a usual command because when I type it in konsole, nothing happens. But when I run pacman -Ss #, a ton of things appear.

My question: what is the # command and what should I do to fix this error?

Here are my .bashrc, .bash_profile and PATH

$ cat .bashrc
   # ~/.bashrc

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

   [[ -f ~/.bashrc ]] && . ~/.bashrc

   alias ls='ls --color=auto'
   PS1='[\u@\h \W]\$ '

$ echo $PATH

Addition 1: As @terdon suggest, I run

$ grep -FH '\#' ~/.bashrc ~/.profile ~/.bash_profile ~/bash.login ~/.bash_aliases /etc/bash.bashrc /etc/profile /etc/profile.d/* /etc/environment 2>/dev/null

and receive nothing. But the later command give me

$ grep -P '(^|\s+)(\.|source) .' ~/.bashrc ~/.profile ~/.bash_profile ~/bash.login ~/.bash_aliases /etc/bash.bashrc /etc/profile /etc/profile.d/* /etc/environment 2>/dev/null
   /home/thuyenarc/.bash_profile:[[ -f ~/.bashrc ]] && . ~/.bashrc
   /etc/bash.bashrc:[ -r /usr/share/bash-completion/bash_completion   ] && . /usr/share/bash-completion/bash_completion
   /etc/profile:           test -r "$profile" && . "$profile"
   /etc/profile:   . /etc/bash.bashrc
   /etc/profile.d/locale.sh:    . "$XDG_CONFIG_HOME/locale.conf"
   /etc/profile.d/locale.sh:    . "$HOME/.config/locale.conf"
   /etc/profile.d/locale.sh:    . /etc/locale.conf

Addition 2: I tried renaming the .bashrc file, then opened konsole, the error had gone. I suspect that the errors must come from .bashrc. Any ideas?

  • 2
    The only way i could think youd get that error is if there was an escaped # somewhere. – 123 Feb 4 '16 at 11:20
  • In most shells, an unescaped #, at the start of a new token (ie, after whitespace), starts a comment until the end of the line. So this is definitely odd. The only thing I can think of is that paman -Ss # is trying to execute a command #; but that would be done outside of the shell. The other possibility is that something tampered with IFS. – Otheus Feb 4 '16 at 11:34
  • 1
    @terdon maybe as an argument to Konsole. Gnome's terminal passes arguments from -e parameter directly to exec rather than via the shell. – Otheus Feb 4 '16 at 12:06
  • 1
    @Otheus Thank you for pointing out my typos, the package is ibus-qt, not ibus-qt4. – macnguyen Feb 4 '16 at 13:44
  • 3
    Try running as env SHELLOPTS=xtrace PS4='${BASH_SOURCE[*]}:$LINENO: ' konsole to see where that error occurs. – Stéphane Chazelas Feb 4 '16 at 14:07

That error means that you have an escaped # (this means \#) in one of bash's initialization files. Since it doesn't seem to be in ~/.bashrc or ~/.bash_profile, it has to be in one of the other files bash reads when it is loaded. To be sure, just search through all of them1:

grep -FH '\#' ~/.bashrc ~/.profile ~/.bash_profile ~/bash.login \
              ~/.bash_aliases /etc/bash.bashrc /etc/profile \
              /etc/profile.d/* /etc/environment 2>/dev/null

That should show you that one of the files listed above contains a \#. Edit the file, remove it and everything should work.

If the command doesn't return any output, that means that one of those files is sourcing another—non-standard—file, and that's the file that has the error. If this is the case, please edit your question and add the output of this command:

grep -P '(^|\s+)(\.|source) .' ~/.bashrc ~/.profile ~/.bash_profile ~/bash.login \
                              ~/.bash_aliases  /etc/bash.bashrc /etc/profile \
                              /etc/profile.d/* /etc/environment 2>/dev/null

That should print all instances of sourcing another file and should point us in the right direction.

More generally, # is not a command, it is a comment. Anything after it is simply ignored by bash. So, when you run pacman -Ss #, you are actually running pacman -Ss alone which is why you get so many results.

1Some of those files are irrelevant here. For example, ~/.profile is ignored if ~/.bash_profile exists and /etc/profile won't be read when you open a new terminal, but you may as well search through all of them just in case.

| improve this answer | |
  • It's a good list, but setting PS4='$0 : ' at the top of .profile or ...rc and starting up w/ -x might be more direct. Interactive shells, though, dont interpret inline comments by default, I think, and so if some input comes via stdin it could happen without being escaped if it wasnt the first on a line. whats that file that readline looks at for key programming? returns in some files rather than newlines might make something like that happen, maybe. – mikeserv Feb 4 '16 at 11:44
  • @mikeserv yes, setting PS4 that way is a good trick (and probably deserves its own answer) but that produces (or can produce) a lot of output. I think it's far more likely that one of the startup files has a malformed line. If the OP tries this and it turns out not to be the case, we can investigate further. As for interactive shells, bash at least, does interpret comments. Try echo foo #bar. Same for non-interactive, try printf 'echo foo # bar' | bash. The file you're thinking of is probably ~/.inputrc but adding a \# (or #) there doesn't produce the error. – terdon Feb 4 '16 at 11:53
  • i only piped up at all because of the mention of that ibus thing - its some kind of language/keyboard switcher or whatever. i can imagine a hasty edit somewhere could lodge a few weird, unprintable (or even incomplete) characters in and among the more standard kinds, and those things can screw with a shells idea of an input line. is it a configurable thing then? the inline comment deal? i know read about it once in man bash... – mikeserv Feb 4 '16 at 12:01
  • 1
    my bad: interactive comments: In a non-interactive shell, or an interactive shell in which the interactive_comments option to the shopt builtin is enabled (see SHELL BUILTIN COMMANDS below), a word beginning with # causes that word and all remaining characters on that line to be ignored. An interactive shell without the interactive_comments option enabled does not allow comments. The interactive_comments option is on by default in interactive shells. – mikeserv Feb 4 '16 at 12:04
  • Indeed. @mikeserv I dont want to steal your answer. If one does shopt -u interactive_comments, Then entering # may result in # command not found – Otheus Feb 4 '16 at 12:09

It may be that somehow the BASH-shell-option interactive_comments was disabled. You can replicate the behavior with:

~ $ shopt -u interactive_comments
~ $ # 
# command not found
~ $

You can determine if it's on or off :

$ shopt interactive_comments

If the output is "on", then this is not the source of your problem. If it is "off", then you should grep your files (/u/tedron's answer) to look for where this is being set.

| improve this answer | |
  • When I run shopt interactive_comments, the result is interactive_comments on. – macnguyen Feb 4 '16 at 14:47
  • ^bummer. i thought it was right. @MặcNguyênĐặng - do you get anything out of echo exit | bash -ix 2>&1 | grep comment? Another test I'd be curious to know the results of is: echo exit | PS4='$0 : $LINENO : ' bash -ix 2>&1 | grep '[^[:print:]]' – mikeserv Feb 4 '16 at 14:57
  • @mikeserv I recieve nothing. Could you explain what it's mean? – macnguyen Feb 4 '16 at 14:59
  • 1
    Try this: cd $HOME; touch empty.sh; export ENV=$HOME/empty.sh; konsole This should force the shell to be run without any initialization scripts. – Otheus Feb 5 '16 at 11:17
  • 1
    @MặcNguyênĐặng (and Otheus) if renaming .bashrc fixes it and there is i) no \# in .bashrc and ii) the only file it sources is /usr/share/bash-completion/bash_completion, it seems likely that the error is in the bash_completion file. Could be that a bad update modified it and inserted an \#. I might have missed something in the comments, but have you tried grep -F '\#' /usr/share/bash-completion/bash_completion? – terdon Feb 6 '16 at 15:06

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.