Not a valid identifier upon terminal startup I am getting this line each time I open my terminal. Everything else seems to be working ok but I would like to get this fixed since I don't think it is a good sign.

Last login: Mon Feb 19 09:21:05 on ttys000
-bash: export: `Workbooks.app/Contents/SharedSupport/path-bin': not a 
valid identifier
Rachels-MacBook-Pro:~ rachelromine$


I have checked out my bash_profile and this is what it looks like

eval export PATH="/Users/rachelromine/.rbenv/shims:${PATH}"
export RBENV_SHELL=bash
source 
'/usr/local/Cellar/rbenv/1.0.0/libexec/../completions/rbenv.bash'
command rbenv rehash 2&gt;/dev/null
rbenv() {
  local command
  command="$1"
  if [ "$#" -gt 0 ]; then
    shift
  fi

  case "$command" in
  rehash|shell)
    eval "$(rbenv "sh-$command" "$@")";;
  *)
    command rbenv "$command" "$@";;
  esac
}

# Setting PATH for Python 3.6
# The original version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.6/bin:${PATH}"
export PATH

test -e "${HOME}/.iterm2_shell_integration.bash" &amp;&amp; source 
"${HOME}/.iterm2_shell_integration.bash"


I think I must have installed something that when awry. If you have any idea of what I installed that could have caused it that would be extremely helpful but mostly I want to correct the valid identifier issue that appears each time I open my terminal.
Solution (original in comments): remove eval from the first line. The problem could also have been in either of the scripts that're sourced (in the third and last lines), but that turned out not to be the case.

Explanation: eval makes the shell parse that command twice. Technically, it goes through all the usual steps when the shell parses a command line -- interpreting and removing quotes and escape characters, expanding variables, etc -- then passes the result to the eval command as arguments. The eval command (which is built into bash, not a separate executable) sticks those arguments back together as though that was a command, runs through all that parsing stuff again, and executes the result.

This is almost always a bad idea. Shell parsing is complicated and messy, and doing more of it just makes for more complication and mess. Unfortunately, people sometimes use it as a sort of "hit it with a bigger hammer" solution, and it works about as well as you'd expect beating things with a bigger hammer to work.

In this particular case, I think what's happening is that before this script runs, PATH is set to something like "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/Applications/Something Workbooks.app/Contents/SharedSupport/path-bin" (where "Something" is a different word, but I don't know the specific app name). The shell takes this:

eval export PATH="/Users/rachelromine/.rbenv/shims:${PATH}"


Removes the quotes and expands ${PATH}, passes the result to eval, which executes:

export PATH=/Users/rachelromine/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/Applications/Something Workbooks.app/Contents/SharedSupport/path-bin


Since the quotes got removed in the first parsing pass, that space in the middle of the app name is treated as a separator between arguments (rather than as part of a filename), so the export command sets PATH to "/Users/rachelromine/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/Applications/Something", then in a totally unrelated operation tries to export a variable named "Workbooks.app/Contents/SharedSupport/path-bin"... which is not a valid variable name ("identifier").

Now, as for what that eval is doing there in the first place: I don't know. I can't see how it could possibly do any good here (though if it weren't for the space, it wouldn't have done any harm). I assume it was in some instructions you followed (or a prototype .bash_profile) for installing rbenv. What it was doing there, I have no idea.