“syntax error near unexpected token” after editing .bashrcDifferentiate Interactive login and non-interactive non-login shellCommand Line Clipboard Accessscp 33H messageSyntax error near unexpected token `('Bash : Syntax error near unexpected token '('bash: syntax error near unexpected token '<'bash: syntax error near unexpected token `do'
Should I tell an editor that I believe an article I'm reviewing is not good enough for the journal?
Are we sinners because we sin or do we sin because we are sinners?
Insets around a clock
What is the difference between 词 and 汉字?
Days in indexed month
Is there any way to get an instant or sorcery on the field as a permanent? What would happen if this occurred?
When/where was <FH> used for /f/?
Unique magic triplets
UK visitors visa needed fast for badly injured family member
Was it possible for a message from Paris to reach London within 48 hours in 1782?
How do put overbrace across an (aligned) equals sign?
How to break a equation with a single "summation symbol (sum) " common?
What should I tell a customer when my co-worker fails to show up to a meeting?
Which of these will work? HDMI to VGA or HDMI to USB?
N-Dimensional Cartesian Product
What is :>filename.txt Doing?
Did Ohio pass a law granting students the right to give scientifically wrong answers consistent with their religious beliefs?
ASCII texturing
Why are rain clouds darker?
Does "solicit" mean the solicitor must receive what is being solicited in context of 52 U.S. Code Section 30121?
Idiomatic way to distinguish two zero-arg constructors
Does toddler keep hands around private parts?
Beautiful planar geometry theorems not encountered in high school
Bash script that shows changing real time values from commands
“syntax error near unexpected token” after editing .bashrc
Differentiate Interactive login and non-interactive non-login shellCommand Line Clipboard Accessscp 33H messageSyntax error near unexpected token `('Bash : Syntax error near unexpected token '('bash: syntax error near unexpected token '<'bash: syntax error near unexpected token `do'
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;
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)[33[01;32m]u@h[33[00m]:[33[01;34m]w[33[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: wa]$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?
command-line bash bashrc alias
add a comment
|
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)[33[01;32m]u@h[33[00m]:[33[01;34m]w[33[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: wa]$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?
command-line bash bashrc alias
add a comment
|
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)[33[01;32m]u@h[33[00m]:[33[01;34m]w[33[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: wa]$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?
command-line bash bashrc alias
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)[33[01;32m]u@h[33[00m]:[33[01;34m]w[33[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: wa]$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?
command-line bash bashrc alias
command-line bash bashrc alias
edited Sep 5 at 2:27
Eliah Kagan
95.2k25 gold badges256 silver badges409 bronze badges
95.2k25 gold badges256 silver badges409 bronze badges
asked Sep 5 at 0:10
tarantaran
1135 bronze badges
1135 bronze badges
add a comment
|
add a comment
|
2 Answers
2
active
oldest
votes
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.
6
This answer would be a lot better if you explained why the fix works
– Andy
Sep 5 at 10:09
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
Sep 5 at 16:25
'preseed' -- did you mean 'precede'?
– Michael Harvey
Sep 7 at 10:38
add a comment
|
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
1 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.
That answer covered all questions I had, great (maybe should mention that .bash_aliases is expected to be sourced from .bashrc
– eckes
Sep 5 at 9:44
@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. ;)
– ilkkachu
Sep 5 at 15:14
@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
Sep 5 at 15:23
2
@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.)
– Eliah Kagan
Sep 5 at 17:42
add a comment
|
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1170928%2fsyntax-error-near-unexpected-token-after-editing-bashrc%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
6
This answer would be a lot better if you explained why the fix works
– Andy
Sep 5 at 10:09
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
Sep 5 at 16:25
'preseed' -- did you mean 'precede'?
– Michael Harvey
Sep 7 at 10:38
add a comment
|
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.
6
This answer would be a lot better if you explained why the fix works
– Andy
Sep 5 at 10:09
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
Sep 5 at 16:25
'preseed' -- did you mean 'precede'?
– Michael Harvey
Sep 7 at 10:38
add a comment
|
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.
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.
edited Sep 5 at 16:52
answered Sep 5 at 1:56
mook765mook765
6,9683 gold badges18 silver badges39 bronze badges
6,9683 gold badges18 silver badges39 bronze badges
6
This answer would be a lot better if you explained why the fix works
– Andy
Sep 5 at 10:09
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
Sep 5 at 16:25
'preseed' -- did you mean 'precede'?
– Michael Harvey
Sep 7 at 10:38
add a comment
|
6
This answer would be a lot better if you explained why the fix works
– Andy
Sep 5 at 10:09
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
Sep 5 at 16:25
'preseed' -- did you mean 'precede'?
– Michael Harvey
Sep 7 at 10:38
6
6
This answer would be a lot better if you explained why the fix works
– Andy
Sep 5 at 10:09
This answer would be a lot better if you explained why the fix works
– Andy
Sep 5 at 10:09
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
Sep 5 at 16:25
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
Sep 5 at 16:25
'preseed' -- did you mean 'precede'?
– Michael Harvey
Sep 7 at 10:38
'preseed' -- did you mean 'precede'?
– Michael Harvey
Sep 7 at 10:38
add a comment
|
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
1 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.
That answer covered all questions I had, great (maybe should mention that .bash_aliases is expected to be sourced from .bashrc
– eckes
Sep 5 at 9:44
@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. ;)
– ilkkachu
Sep 5 at 15:14
@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
Sep 5 at 15:23
2
@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.)
– Eliah Kagan
Sep 5 at 17:42
add a comment
|
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
1 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.
That answer covered all questions I had, great (maybe should mention that .bash_aliases is expected to be sourced from .bashrc
– eckes
Sep 5 at 9:44
@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. ;)
– ilkkachu
Sep 5 at 15:14
@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
Sep 5 at 15:23
2
@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.)
– Eliah Kagan
Sep 5 at 17:42
add a comment
|
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
1 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.
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
1 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.
edited Sep 5 at 17:39
answered Sep 5 at 2:10
Eliah KaganEliah Kagan
95.2k25 gold badges256 silver badges409 bronze badges
95.2k25 gold badges256 silver badges409 bronze badges
That answer covered all questions I had, great (maybe should mention that .bash_aliases is expected to be sourced from .bashrc
– eckes
Sep 5 at 9:44
@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. ;)
– ilkkachu
Sep 5 at 15:14
@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
Sep 5 at 15:23
2
@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.)
– Eliah Kagan
Sep 5 at 17:42
add a comment
|
That answer covered all questions I had, great (maybe should mention that .bash_aliases is expected to be sourced from .bashrc
– eckes
Sep 5 at 9:44
@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. ;)
– ilkkachu
Sep 5 at 15:14
@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
Sep 5 at 15:23
2
@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.)
– Eliah Kagan
Sep 5 at 17:42
That answer covered all questions I had, great (maybe should mention that .bash_aliases is expected to be sourced from .bashrc
– eckes
Sep 5 at 9:44
That answer covered all questions I had, great (maybe should mention that .bash_aliases is expected to be sourced from .bashrc
– eckes
Sep 5 at 9:44
@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. ;)
– ilkkachu
Sep 5 at 15:14
@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. ;)
– ilkkachu
Sep 5 at 15:14
@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
Sep 5 at 15:23
@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
Sep 5 at 15:23
2
2
@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.)– Eliah Kagan
Sep 5 at 17:42
@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.)– Eliah Kagan
Sep 5 at 17:42
add a comment
|
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1170928%2fsyntax-error-near-unexpected-token-after-editing-bashrc%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown