Live data from Hacker News

Don't waste your time by cd-ing in the terminal

huyng.com

61–70 of 124 posts

Re: Don't waste your time by cd-ing in the terminal

#61
post #49

Earlier quoted context omitted.

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.

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?

> 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.

Re: Don't waste your time by cd-ing in the terminal

#62
post #49

Earlier quoted context omitted.

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.

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?

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

Re: Don't waste your time by cd-ing in the terminal

#63
Interesting reading this because this is exactly why I love emacs, especially when I came across this tip a while ago: "Emacs: TRAMP + bookmarks = awesome", http://marc-abramowitz.com/archives/2006/03/12/emacs-tramp-b...

I'm always plugged in to my server with tramp and I've got multiple projects all bookmarked. It makes hopping around real easy, makes it feel like a browser more than an editor.

Re: Don't waste your time by cd-ing in the terminal

#64

Another time saver is to have a function that calls ls after cd'ing: c(){ cd "$@" && ls;} This has probably saved me days over the years, as I almost always want to list a directory after I change into.

Silly me. I almost always do the same, but never thought of creating a function. Thanks anyways. :D

Re: Don't waste your time by cd-ing in the terminal

#65
post #8

I use this function in my bash profile to navigate to my projects from anywhere on the file system. function to { cd ~/Sites/$1/ } eg. cd ~/Sites/coenhyde.com $ to coenhyde.com

I would suggest mapping an alias instead of creating a function so that you will still be able to take advantage of parameter completion: > alias to='cd ~/Sites/'

Ah, much nicer. Thankyou.

Edit: On testing it doesn't work. 'to sitename' just goes straight to ~/Sites/. I knew there must have been a reason i used a function instead of an alias.

Re: Don't waste your time by cd-ing in the terminal

#66
post #62
post #49

Earlier quoted context omitted.

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?

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

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.

Re: Don't waste your time by cd-ing in the terminal

#67
post #62
post #49

Earlier quoted context omitted.

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?

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

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.)

Re: Don't waste your time by cd-ing in the terminal

#68
post #56

Earlier quoted context omitted.

So browsing graphical tabs is quicker for you then using "Ctrl+RightArrow" or "Ctrl+n" or some variation of one of those? Traversing my screen or tmux sessions is usually much faster than using a mouse.

Traversing is not the issue here, it's more about having an ad-hoc way to watch things side-by-side by dragging a tab to a window and vice versa, and about having a proper scrollback. Yes, screen, tmux and vim have split window modes, but those are cumbersome to operate (and I'm saying that as a year-long ion3 user) and the scrollback issue has not been addressed by either up to this day. Or, to put it more generally…

>I want an "open" CLI-command that downloads the target-file from the remote server and displays it locally without me having to futz with scp. I want to drag & drop files onto the server that I'm currently ssh'd into.

You can get this by editing files over sshfs.

In general though, I find that sort of persistence to be somewhat unstable. I'd rather know that everything I have done is documented and backed up than just sitting in some sort of dump of memory.

Re: Don't waste your time by cd-ing in the terminal

#69
post #2

I've also wondered to myself why there isn't a terminal program with a directory tree by the side so you could just click on the directory that you want to be in, instead of ls -cd-tab-blah-^H-tab-^M. It would also a have a list of favorite and most-recently-used directories. A weekend project, perhaps...

http://en.wikipedia.org/wiki/Midnight_Commander

Also don't forget to turn on the "lynx like navigation" option. This lets you navigate all the way through arrow keys (no need to use Enter).

Re: Don't waste your time by cd-ing in the terminal

#70

No mention of ZSH directory stacks yet? http://www.acm.uiuc.edu/workshops/zsh/dir_stack.html Some helpful aliases to manage them: alias 1='cd -1' alias 2='cd -2' alias 3='cd -3' alias 4='cd -4' alias 5='cd -5' alias 6='cd -6' alias 7='cd -7' alias d='dirs -v' alias h='history' alias j='jobs' Just one of the many reasons to use ZSH.

I have bound 'pushd -1' to PgUp.

    function directory_up { 
      pushd -1
      zle reset-prompt 
    }
    zle -N directory-up directory_up
    bindkey "\e[5~" directory-up
Ditto for "pushd +0" and PgDn.
Post reply on HN