1

I recently updated OSX to El Capitan, and in the process of running through the steps needed to update my development environment, I discovered something rather disturbing: bash is behaving as if . is in my PATH, even though it's not. This is a serious security issue, and I can't find any way to turn it off.

Here's the result of echo $PATH:

/Users/username/.rbenv/shims:/Users/username/.pyenv/plugins/pyenv-virtualenv/shims:/Users/username/.pyenv/shims:/opt/chefdk/bin:/Users/username/.chefdk/gem/ruby/2.1.0/bin:/opt/chefdk/embedded/bin:/Users/username/.pyenv/bin:/Users/username/.rbenv/bin:/Users/username/.rbenv/plugins/ruby-build/bin::/Users/username/bin:/src/workspace/s3-utils/bin:/opt/local/lib/oracle:::/Users/username/bin/IAMCli/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin

Notice how . is missing from that listing? With that in mind, why is this happening?

[10:26:57][username@flint:~/Downloads] :) $ ls script.sh ls: script.sh: No such file or directory [10:27:08][username@flint:~/Downloads] :( Exit code: 1 $ which script.sh [10:27:09][username@flint:~/Downloads] :( Exit code: 1 $ touch script.sh [10:27:15][username@flint:~/Downloads] :) $ chmod +x script.sh [10:27:19][username@flint:~/Downloads] :) $ which script.sh ./script.sh [10:27:23][username@flint:~/Downloads] :) $

Somehow, . is in my path, even though I did not configure it so, and $PATH doesn't include it. What do I do about this?

  • 1
    What happens if you replace the ::: after oracle and the :: after ruby-build/bin with plain :? – Law29 Mar 28 '16 at 17:54
  • is there a user name .rbenv created by Ruby installation, attach a screenshot of your Users and Groups – SeanClt Mar 28 '16 at 17:55
  • . never needs to be in path. if you call an executable without a path, and one exists in the current working directory, it will be executed. perhaps I'm misunderstanding your issue, because that behavior is not anything abnormal, and goes back to the 60's. literally Every OS I've ever used functioned this way. – Frank Thomas Mar 28 '16 at 18:28
  • 1
    @FrankThomas Your OSs have been dangerously misconfigured, then. Having . in your path leaves you open to malicious code running without your knowledge. Someone could stick a script into your working directory called sudo, and any time you used sudo, you'd unknowingly be giving your password to that script, instead of the real /usr/bin/sudo command. Not having . in your path means that when you want to execute something in your current directory, you have to acknowledge that by using ./command instead of command. Also, your second comment about $PATH evaluation is simply wrong. – CoreDumpError Mar 28 '16 at 20:08
  • @Law29 That was it! Bash was treating the duplicated colons as if they indicated that . should be in my PATH. I can't imagine why, though... – CoreDumpError Mar 28 '16 at 20:09
0

As Law29 pointed out in a comment, my problem was those instances of duplicated colons. For some reason, Bash appears to treat :: in your PATH as if it were :.:.

This seems like a bug, as I can't imagine why anyone would want that.

  • From the man page for bash under Shell Variables, PATH "The search path for commands. It is a colon-separated list of directories in which the shell looks for commands. ... A zero-length (null) directory name in the value of PATH indicates the current directory. ...". It's not a bug, does than leave a failure of imagination? – user187561 Mar 28 '16 at 21:31
  • While I agree that it's clearly not a bug, I'm not sure that just because it's the default makes it desirable. I don't want that to be the default, because having . in your path is potentially dangerous. A much more sensible default would be to simple ignore blank directory names. – CoreDumpError Mar 28 '16 at 23:20
  • For the record, this is true in zsh as well. I don’t know whether this behaviour is merely “traditional”, or whether there’s a good reason for it. At any rate, I define this shell function to clean out all non-existing or blank directories from a PATH-like variable, and then call it on such variables at the end of my shell initialisation: pathclean() {for p in $@; eval "$p=(\$^$p(-/N))"}. Not sure if that’d work verbatim in Bash, but you’re welcome to try… – wjv Apr 12 '16 at 7:11
  • In retrospect, that definitely won’t work in bash since it depends on the fact that zsh automatically ties the $PATH environment variable to the $path array. – wjv Apr 12 '16 at 7:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.