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.
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.
"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."
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.
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.
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!
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 do something similar. Instead of passing the tmux attach command to ssh, I attach (or create) a tmux session if the shell is a) a login shell and b) started in a SSH session. [0]
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.
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.)
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:
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.
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.
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.)
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 :).
50 comments
[ 3.2 ms ] story [ 116 ms ] threadWe 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.
Congratulations on getting the *NIX philosophy right.
"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."
https://gist.github.com/christianbundy/8954786
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. :)
/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)
/sudo:localhost:/etc/hosts
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!
The benefit of tmux/screen is that you can run it remotely, and reconnect to your session-in-progress at any time.
[0] https://github.com/martinp/dotfiles/blob/master/dot.zlogin
http://byobu.co/about.html
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.
WARNING: SHAMELESS SELF-PROMOTION BELOW
Unless, you know, you used something like homes(h)ick...
https://github.com/technicalpickles/homesick
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.
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.
scp root@host:/long(tab)_file_name .
You can check out my dotfiles (https://github.com/christianbundy/dotfiles), but I'm pretty sure that the functionality came standard with one of my Zsh submodules, Prezto (https://github.com/sorin-ionescu/prezto).
Then you can put
in your .bashrc, and you won't have to distinguish between local and remote paths ever again.What do you think?
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.
t=${@[$#]}
c=("ssh" "-t" "${@:1:$(( $# -1 ))}" "${t%:}" "cd ${t##:}; \$SHELL -l")
"${c[@]}"