3 ms·
Another built-in worth knowing about is CDPATH.[1] I find that setting a sane CDPATH and bash-completion makes cd-ing anywhere I go regularly pretty trivial - j
by telemachos 16y ago
Another built-in worth knowing about is CDPATH.[1] I find that setting a sane CDPATH and bash-completion makes cd-ing anywhere I go regularly pretty trivial - just a few letters and a few TABs and I'm good to go.
[1] http://caliban.org/bash/#bashtips http://caliban.org/bash/#bashtips
- moe 16y agoI'd be extremely careful with CDPATH, never use this on an important host. Having "cd foo" potentially take you to an entirely different location can be dangerous, to say the least.
- telemachos 16y agoI'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 16y agocd 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 16y agoCertainly 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 16y agoWell, 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 16y ago> 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 16y agoDoes it implicitly export $CDPATH? Otherwise you would have to 'export CDPATH' to have that happen.
- moe 16y agoNo, 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.
- technomancy 16y agoThere are also a lot of scripts that assume CDPATH isn't being used; for instance any hadoop-based project will break if it's set.