50 comments

[ 3.2 ms ] story [ 116 ms ] thread
TL;DR: a 3 line exercise in bash argument munging.

  t="${!#}"
  c=("ssh" "-t" "${@:1:$(($#-1))}" "${t%:*}" "cd ${t##*:}; \$SHELL -l")
  "${c[@]}"
That's literally the whole repo.
Literally.

We both know that it would've been easier to write this in Python, Ruby, Javascript, etc., but at the cost of using an "uncool" language I was able to solve the problem in three lines with only bash as a dependency. Pull requests welcome.

I am thankful you didn't.

Congratulations on getting the *NIX philosophy right.

If that's the ★nix philosophy I don't want to be a ★nix person any more. Seriously, even my VMS machines have python installed, and a script I can read is a lot better than one I can't, even if the one I can read has an extra dependency.
Python isn't too bad (unless you're calling the script in a lot of separate instances), but python is fairly neat compared to ruby/javascript/whatever trendy language of the week as it doesn't need a huge pile of worthless dependencies itself.
http://en.wikipedia.org/wiki/Unix_philosophy

"The Unix philosophy emphasizes building short, simple, clear, modular, and extendable code that can be easily maintained and repurposed by developers other than its creators. The philosophy is based on composable (rather than contextual) design."

echo "cd /your/favorite/folder" >> ~/.bashrc
This is by far is the best option, its still user based so it will take me where I want.
Absolutely – I'd definitely recommend that this is used in favor of my utility if you're always going to the same directory.

I originally wrote a util that outputs your current username, hostname, and path (https://github.com/christianbundy/whereami) so that you can either share or save it somewhere, but since SSH doesn't handle file paths by default I made a utility that does. :)

I think you've done an excellent job of pointing out that ssh should just be capable of doing this by default. Like many such things, it's obvious with hindsight. But somehow I never thought of it before.
If you are an Emacs user, Tramp does this, e.g. you can open a file like:

/user@example.com:/some/remote/path/file.dat

Directory navigation (dired) works too, you can also open a shell in the remote directory (M-x shell)

Enabling ido-mode makes it a lot more easier to use. Also, you can open local files as sudo in a similar way.

/sudo:localhost:/etc/hosts

+1 also from within eshell cd proto:user@location:/filepath where proto can be ftp, ssh , and some others
Alternatively, you could keep a tmux session open on the server and just attach it on connect. That way you can have everything arranged just the way you left it on disconnect. Same applications running, multiple windows, splits, etc. And you don't even need to start a new shell on connect.

    ssh user@host -t tmux attach 
You can add an alias for it.

    alias backtowork='ssh -t user@host tmux attach -t worksession'
The last argument allows you to attach a chosen session if you have more than one running.
Awesome, I hadn't though of that.

My terminal automatically logs into my server via SSH and I just use my tmux aliases from there (minus the SSH, of course), but that would be a great way to do it if I developed locally. Thanks for the tip!

Hm, why only for developing locally?

The benefit of tmux/screen is that you can run it remotely, and reconnect to your session-in-progress at any time.

I use screen and it works well. The first thought when I saw this post was of screen and tmux. Anyone spending any kind of serious time in remote server through ssh should use screen/tmux.
I totally agree, a lot more of my work life is spent on our Linux platform. tmux is a godsend due to my sometimes flaky VPN connection.
I use Byobu on top of that for some extra useful features.

http://byobu.co/about.html

I've looked through the docs and a video on YouTube and I still can't figure it out – what features does this offer that can't already be done with tmux?
There are two major things for me: The first is the easy attachment to existing tmux sessions, ie. I just ssh to a server and it'll re-attach to my last tmux session automatically - F6 then detaches cleanly and logs out.

The next is all the handy notifications in the bottom bar; a bit like conky, if you use that. So it lists the server mem/cpu/network load, number of packages that need updating, RAID status, AWS estimated cost (if relevant), no. logged in users, etc...

It originally started out with a Screen backend, then switched over to Tmux which has a lot of the same multiplexing functionality. So that's probably why you're not seeing a huge added benefit. But the added extras are enough to make me always want Byobu installed - particularly the easy session attachment.

Using tmux on the server and attaching sessions on the client is a better option.
plus if you're going for bash instead of python to avoid dependencies, just go for sh. It's not like it would be hard to code or anything in sh.
I hate little extensions like this because if I make them part of my workflow, I am completely hindered when I find myself on a machine that doesn't have this. (Every other machine in the world.)
In this particular instance, the command is saving you a total of two keystrokes. "You could probably get by in a pinch."
I like to take advantage of temporal locality. My zshrc is configured to take me to the most recent place that I have been whenever I open a new shell:

  autoload -U add-zsh-hook
  record_pwd() { pwd > ~/.cwd }
  add-zsh-hook chpwd record_pwd
  touch ~/.cwd
  cd `cat ~/.cwd`
I'm trying really hard to see the utility in this, as somebody who almost obsessively aliases commands to save keystrokes. But it's almost the same number of keys, at the expense of having to mix them together.

This feels less like a marriage and more like trying to tie two very different animals together.

I'd much prefer if this was some kind of host-alias based magic, where "ssh my_server_web" took my to "my_server:/srv/http/my_site", "ssh my_server_db" took me to my_server and opened mysql, etc.

There are two things I find odd about this solution.

You still have to type the path you want to cd to. See previous discussion at https://news.ycombinator.com/item?id=6229001 for possible solutions.

The github example specifies the username to ssh to. Assuming you ssh to the host more than once see man ssh_config and the User parameter.

And screen/tmux, obviously.

It would be much more useful if you can make an scp with autocomplete by pressing tab in the terminal.

scp root@host:/long(tab)_file_name .

That's always worked by default for me on Ubuntu (assuming ssh keys etc)
I think it's a cool exploration. Thanks for sharing.
Thanks for the sincere comment! I hope you have a kickass Wednesday.
Even better: make the script work with local paths as well.

Then you can put

    alias cd='sshcd'
in your .bashrc, and you won't have to distinguish between local and remote paths ever again.
I was thinking about aliasing cd like that and instead having psuedo-directories that you can cd into to SSH into another box. The biggest problem though would be moving around in the box, as `cd ..` wouldn't take you back to your local machine.

What do you think?

Take a look at https://github.com/spencertipping/cd. It will let you cd to local or remote machines the same way, and will take you back to your local machine on "cd ..". (It mounts the remote fs instead of SSHing there.)
Any benefits with this over running something like this? Other than it being shorter and easier for someone not familiar with console commands?

  ssh -t yourserver.com 'cd /some/dir/;exec /bin/sh'
Nope, that's actually very close to what it does.

I didn't develop this because the keystrokes were difficult, I just know that both git and SCP support this syntax and couldn't think of any good reason why SSH shouldn't.

A pretty cool improvement. And you can easily add remote directory autocompletion if you simply steal the autocompletion function of `scp`: complete|sed -n 's/ scp$/ sshcd/p'
For what it's worth, this is broken when the target directory contains spaces/wildcard characters, etc. I would suggest you consider using something like the following to generate the command line you pass to ssh:

  printf -v cmd 'cd %q && $SHELL -l' "$target_dir"
Also, dropping the ':' and just having an additional argument would make your life a bit simpler. What's with the array assignment just to invoke the command? Seems a bit unnecessary. The microoptimizer in me tells me you should use 'exec' as well :).
a version that works inside your zsh scripts. there may be a better way to do it

t=${@[$#]}

c=("ssh" "-t" "${@:1:$(( $# -1 ))}" "${t%:}" "cd ${t##:}; \$SHELL -l")

"${c[@]}"