"syntax error near unexpected token" after editing .bashrc
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?
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 .bashrc1 contains this code:2
# 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.3 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.
1The 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.
2It 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.
3Ubuntu'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.
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.