“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;









11


















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?










share|improve this question

































    11


















    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?










    share|improve this question





























      11













      11









      11


      2






      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?










      share|improve this 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)[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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      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























          2 Answers
          2






          active

          oldest

          votes


















          16



















          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.






          share|improve this answer























          • 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


















          20



















          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.






          share|improve this answer




























          • 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












          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
          );



          );














          draft saved

          draft discarded
















          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









          16



















          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.






          share|improve this answer























          • 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















          16



















          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.






          share|improve this answer























          • 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













          16















          16











          16









          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.






          share|improve this answer
















          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.







          share|improve this answer















          share|improve this answer




          share|improve this answer








          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












          • 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













          20



















          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.






          share|improve this answer




























          • 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















          20



















          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.






          share|improve this answer




























          • 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













          20















          20











          20









          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.






          share|improve this answer
















          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.







          share|improve this answer















          share|improve this answer




          share|improve this answer








          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

















          • 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


















          draft saved

          draft discarded















































          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.




          draft saved


          draft discarded














          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





















































          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









          Popular posts from this blog

          Tamil (spriik) Luke uk diar | Nawigatjuun

          Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

          Training a classifier when some of the features are unknownWhy does Gradient Boosting regression predict negative values when there are no negative y-values in my training set?How to improve an existing (trained) classifier?What is effect when I set up some self defined predisctor variables?Why Matlab neural network classification returns decimal values on prediction dataset?Fitting and transforming text data in training, testing, and validation setsHow to quantify the performance of the classifier (multi-class SVM) using the test data?How do I control for some patients providing multiple samples in my training data?Training and Test setTraining a convolutional neural network for image denoising in MatlabShouldn't an autoencoder with #(neurons in hidden layer) = #(neurons in input layer) be “perfect”?