3

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
   /usr/local/texlive/2015/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

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?

Improve this question
10
  • 2
    The only way i could think youd get that error is if there was an escaped # somewhere. Commented Feb 4, 2016 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. Commented Feb 4, 2016 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. Commented Feb 4, 2016 at 12:06
  • 1
    @Otheus Thank you for pointing out my typos, the package is ibus-qt, not ibus-qt4. Commented Feb 4, 2016 at 13:44
  • 3
    Try running as env SHELLOPTS=xtrace PS4='${BASH_SOURCE[*]}:$LINENO: ' konsole to see where that error occurs. Commented Feb 4, 2016 at 14:07

4 Answers 4

Reset to default
3

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
9
  • 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. Commented Feb 4, 2016 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. Commented Feb 4, 2016 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... Commented Feb 4, 2016 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. Commented Feb 4, 2016 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 Commented Feb 4, 2016 at 12:09
2

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
26
  • When I run shopt interactive_comments, the result is interactive_comments on. Commented Feb 4, 2016 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:]]' Commented Feb 4, 2016 at 14:57
  • @mikeserv I recieve nothing. Could you explain what it's mean? Commented Feb 4, 2016 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. Commented Feb 5, 2016 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? Commented Feb 6, 2016 at 15:06
1

The problem I had is that before the # in the .bashrc file there seem to have been some invisible characters, or the # character looked like # but wasn't #. When executing source .bashrc I got the error. When I copied the content of the file using an editor (I used Emacs) to a new file tmp and executed source tmp there was no error. So I replaced the file .bashrc by tmp (mv tmp .bashrc) and the problem was solved.

What seems to have happened is that on the system I was using the only editor apart from vi was LibreOffice, and I had no permission to install software on it. So I used LibreOffice to adapt the .bashrc file. That seems to have added some special characters to the file or modified the character #.

Improve this answer
-1

Bit late to the party but for me solution was downloading the sample bashrc from the web and then pasting my bashrc's contains to the downloaded one because I used a text editing program(Libre Office Writer) that changed the formatting.

Improve this answer
2
  • Welcome to the site, and thank you for your contribution. Would you consider adding some more explanation - e.g. what text editing program you used, and how that changed the formatting. Commented Sep 21, 2021 at 10:25
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. Commented Sep 22, 2021 at 15:33

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.