"syntax error near unexpected token" after editing .bashrc

Question

I'm trying to access the clipboard but when I input source ~/.bashrc in the terminal I get this error:

bash: /home/taran/.bashrc: line 2: syntax error near unexpected token ('
bash: /home/taran/.bashrc: line 2:alias pbpaste='xclip -selection 
clipboard -o'# ~/.bashrc: executed by bash(1) for non-login shells

I tried to do the tutorial in Gary Woodfine's answer to Command Line Clipboard Access.

The output of cat ~/.bashrc is:

alias pbcopy='xclip -selection clipboard'
alias pbpaste='xclip -selection clipboard -o'# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color|*-256color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
    # We have color support; assume it's compliant with Ecma-48
    # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
    # a case would tend to support setf rather than setaf.)
    color_prompt=yes
    else
    color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

# Add an "alert" alias for long running commands.  Use like so:
#   sleep 10; alert
alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi

This is on Ubuntu 19.04. Can anyone help me figure out how to fix this?

Solution 1

The caveat is in the second line:

alias pbcopy='xclip -selection clipboard'
alias pbpaste='xclip -selection clipboard -o'# ~/.bashrc: executed by bash(1) for non-login shells.

That should be:

alias pbcopy='xclip -selection clipboard'
alias pbpaste='xclip -selection clipboard -o'
# ~/.bashrc: executed by bash(1) for non-login shells.

It looks like you forgot to hit Enter after entering the second alias which resulted in # ~/.bash... directly following your alias definition in the same line. Without a preceding space # ~/.bash... could not be interpreted as a comment by the shell but as a part of the argument of the alias command.

I'd also recommend to place aliases in the file ~/.bash_aliases which will be sourced when ~/.bashrc is executed, so you don't need to edit ~/.bashrc and eventually mess it up.

If you insist on placing aliases in ~/.bashrc, add them at the end of the file.

For deeper insight into this topic, please refer to Eliah's excellent answer to your question.

Solution 2

mook765 is entirely correct about the cause of the problem, and the solution proposed in that answer fixes the syntax error, but I recommend you solve it in a different way.

It's fine to put alias definitions in .bashrc, but it is best not to put them--or anything--at the very top of that file.

We tend to think of .bashrc as being sourced only by interactive shells, but this is actually not the case. Non-interactive remote shells (if bash identifies them as such) also source .bashrc. That is why Ubuntu's default .bashrc¹ contains this code:²

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Basically everything you put in .bashrc, including but not limited to alias definitions, should go somewhere below that. You should only ever put your own code above that code if you have a clear reason to do so, which is rare.

You can put your alias definitions anywhere below that code, though I suggest putting them at the very end of the file. Or you might prefer to put them near some of the existing alias definitions in the file. Or you might prefer to put them in the separate file ~/.bash_aliases, which you can create if it does not exist.³ Any of these choices is fine.

Here's one of the more common examples of the bizarre and unexpected effects putting one's own code above the interactivity check can have. That particular problem occurs when the code produces output, which should not happen from an alias definition. (The alias, when used, may of course expand to a command that produces output, but a syntactically correct alias definition should not produce output unless the -p option is passed to alias.) I don't expect alias definitions to usually cause problems even if they run in non-interactive shells. Non-interactive shells don't perform alias expansion by default anyway (though this is merely a default). However, if they do end up producing unexpected effects, it's likely no one will think to check that.

This is admittedly only a weak reason to avoid putting alias definitions above the interactivity check in .bashrc. However, since there is absolutely no benefit of doing so compared to putting them anywhere else in the file, I recommend following the general approach of only putting code above that check that you deliberately intend to run in non-interactive remote shells.

---

The other interesting aspect of this is why this was a syntax error:

alias pbpaste='xclip -selection clipboard -o'# ~/.bashrc: executed by bash(1) for non-login shells.

# starts comments, which are permitted to follow commands. However, the # character does not have the effect of starting a comment when it appears in a larger word, except as the first character of that word. (In this sense, "word" includes things like pbpaste='xclip -selection clipboard -o'#, due to quoting.) The following text, which was intended as a comment, is taken as additional arguments to the alias builtin. But an error occurs while parsing them, due to the unexpected presence of (, which has special meaning to the shell, but which does not make sense in that context. The effect is that the alias builtin actually never runs, and you get a syntax error instead.

Therefore, it would actually be possible to fix the syntax error with a one-character edit, by putting a space between the ' and # characters on that line. But as detailed above, I recommend going further and moving the alias definitions much lower in the file.

---

_{¹The default .bashrc in Ubuntu can be viewed at /etc/skel/.bashrc, so long as you have not modified that file. This is copied into a user's home directory when the user is created. Like many files in Ubuntu, this file is minimally changed from Debian, the distribution from which Ubuntu is derived. The advice in this post applies to Bash in Debian as well as Ubuntu, but it does not necessarily apply without modification to Bash in all GNU/Linux systems.}

_{²It is also possible, though rare, to start bash as a non-interactive login shell. Like interactive login shells, such a shell sources ~/.profile automatically, and the default ~./profile in Ubuntu explicitly sources ~/.bashrc. Besides preventing unintentional execution in non-interactive remote shells, putting your additions to ~/.bashrc below the interactivity check also prevents it from being unintentionally executed in the strange case of a non-interactive login shell.}

_{³Ubuntu's default .bashrc checks if ~/.bash_aliases exists ([ -f ~/.bash_aliases ]) and sources it (. ~/.bash_aliases) if it does. The code you posted verifies that your modified .bashrc file does perform those actions--it looks like the only change to it was the code you added at the top.}

Comments

[eckes]

That answer covered all questions I had, great (maybe should mention that .bash_aliases is expected to be sourced from .bashrc

[Andy]

This answer would be a lot better if you explained why the fix works

[ilkkachu]

@EliahKagan, actually, I didn't notice that sentence in the middle, whoops. The emphasis this answer puts on the location of the aliases made it read as if it would be a bigger issue than it really is. As it would be if, e.g. the aliases were applied in noninteractive shells too... I do see your point about keeping the guard condition first, but we seem to disagree on the order these different issues should be prioritized. ;)

[Eliah Kagan]

@ilkkachu Yes, it's possible we disagree about that. On the other hand, I started writing this answer after mook765's was already posted and the OP had already marked it as accepted. So I decided to start this answer by referring to that answer ("mook765 is entirely correct about the cause of the problem, and the solution proposed in that answer fixes the syntax error") before then making most of the rest of my answer about the alternative solution of putting them somewhere else than the very top of the file.

[Eliah Kagan]

Thanks! Btw even if one chooses not to follow my advice of putting the aliases somewhere after the interactivity check, I recommend # ~/.bashrc: executed by bash(1) for non-login shells. be kept as the first line. There's no technical reason forcing it to appear first (or at all). But it's a comment documenting the whole file. So it's fairly confusing to human readers for it to appear after other code. I understand if you don't want to change that, especially as the OP accepted this answer as it was. (I think editing for that or just leaving it are both reasonable under the circumstances.)

[Eliah Kagan]

@eckes Thanks for the advice--I've added a few endnotes to cover that and some related issues, for those readers who are interested. (The reason I don't consider ~/.bashrc sourcing ~/.bash_aliases to be an especially important point in this context is that inspection of the OP's ~/.bashrc file reveals that the code that does so has remained intact. It is, however, both relevant and interesting, and you're right to suggest it be mentioned.)

[Michael Harvey]

'preseed' -- did you mean 'precede'?