[telemachos]

I'm not sure I follow. There's nothing dangerous about cd-ing to a directory, though of course it could be dangerous to start work in 'foo', thinking it was 'bar'. Most people use a prompt, or the title bar of their shell to protect against that. But either way, I'm not sure how CDPATH makes that danger greater than any other trick that allows you to jump quickly to a directory using a bookmark, popd or the like.

[moe]

  cd foo
  rm -f *

Removing predictability from the 'cd' command is not a good idea. If you want a smart 'cd' then just call it 'j' or something else. Easier to type, too.

[telemachos]

Certainly a possible scenario, but anyone who cds into any directory (by whatever means) and enters 'rm -f *' without first checking contents deserves what they get.

[moe]

Well, this was just the most graphic example, there are more subtle ways to create a mess. Directory names are far from unique, a misfiring 'cd tmp' or 'cd src' can easily lead to nasty surprises, even without 'rm' ever getting involved at all.

And you do know that CDPATH also affects shell scripts, right?

[telemachos]

> Directory names are far from unique, a misfiring 'cd tmp' or 'cd src' can easily lead to nasty surprises, even without 'rm' ever getting involved at all.

I hear what you're saying, though I'm not really persuaded by this argument. When you 'cd' into a directory along your CDPATH, Bash will print out where you end up when you arrive. Here's an example of what I mean (easier to see than explain):

    circe ~ ❯❯ cd bin
    circe bin ❯❯ cd ithaca
    /Users/circe/code/ithaca
    circe ithaca [master•] ❯❯ 

The regular cd simply takes me where I asked. When I cd and use CDPATH (in the second case), I get told where I end up. Sure, there might be four or five different 'ithaca' folders on various machines and even on one machine, but I think that extra print-out really makes it unlikely that I will get confused.

> And you do know that CDPATH also affects shell scripts, right?

No, I'm embarrassed to say, I never thought of this. And this part does sound like a potential problem. When I write Bash scripts, I always use full paths, but I see where my having CDPATH set puts me at danger from other people's scripts. Technomancy gives a concrete example above. Although I think this is bad practice on their part (not to use full paths), I appreciate the warning.

[pyre]

Does it implicitly export $CDPATH? Otherwise you would have to 'export CDPATH' to have that happen.

[moe]

No, it does not. But in today's world of layered environments (virtualenv, rvm) your bashrc may very well be sourced in places that you didn't anticipate. On top of that each linux distribution has its own way of screwing with the environment files in creative ways, as anyone can attest who has had to make a cronjob work across platforms...

However, your question suggests that you're probably one of the chosen few who could actually use this feature safely. My general advice against it was aimed at the 99% other people who think "Oh convenient!" without being fully aware of the implications.

[telemachos]

The link I posted to suggests exporting CDPATH. I've always copied that, without really thinking about the effect on scripts. If you set (but don't export) CDPATH, it does not get passed along to scripts, as far as I can tell here.

So, no, Bash doesn't implicitly export the variable. (Thanks to everyone for helping me improve my dotfiles a little bit.)