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
command rbenv rehash 2>/dev/null
rbenv() {
  local command
  if [ "$#" -gt 0 ]; then

  case "$command" in
    eval "$(rbenv "sh-$command" "$@")";;
    command rbenv "$command" "$@";;

# Setting PATH for Python 3.6
# The original version is saved in .bash_profile.pysave
export PATH

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

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.

  • 1
    It looks like the root problem is that something's doing an export command without properly quoting the value being exported. This might be due to the first line -- the eval prefix is useless and dangerous and should be removed. If that doesn't fix it, it's probably in one of the files being sourced in the third or last lines; you can add echo commands (e.g. echo "about to source rbenv.bash") before & after those to find out where the error is coming from. – Gordon Davisson Feb 19 '18 at 19:18
  • 1
    You should post this as the answer. removing the eval prefix totally got rid of the not a valid identifier message. Thank you Gordon!!! Do you have any idea on what might have added an eval prefix in there? Or how I might find out? – Rachel Riley Feb 19 '18 at 19:30
  • 1
    klanomath you are right. Here is the actual end "${HOME}/.iterm2_shell_integration.bash" I'm going to correct my original post for completeness – Rachel Riley Feb 19 '18 at 19:33
  • Upps, sorry, ignore the double rollback, please. – nohillside Feb 19 '18 at 19:38
  • ??? I'm newish to posting on here can you explain double rollback? Did I do something wrong? Thanks – Rachel Riley Feb 19 '18 at 19:42

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .