The title of your post is less catchy and less clear, which for good or for bad likely had an effect on the outcomes of these two submissions (and frankly I bet had much more to do with anything than the actual technical details: frankly, your assh looks much more powerful in valuable ways, and doesn't seem overly complex to use either).
This has some nice side effects in that you can then just host your vimrc the same way. I think you can get vim to load plugins from a http runtime path too, but I have never looked into it.
Something similar, which allows you want to extend shell scripts to a remote system transparently is "rpcsh" -- take a look at:
https://gist.github.com/derekp7/9978986
This function allows you to push out local functions, variables, and arrays to a remote system. There is an updated version in the client script for my backup utility (snebu), which also includes getting remote variables returned to the local shell script, and also bouncing through sudo.
Should I move this to a regular project on Github, or keep it in the gist?
Well, this post read my mind. Literally my first thought waking up this morning was "why don't I have some way to use my .vimrc over ssh?" I open up Hacker News and voila!
I was thinking of putting together a crude hack to implement just a subset of what this offers. I cannot thank the authors enough. I'm trying this out the moment I get home.
I feel as though we should have had first-class support for portable environments all along, and it shocks me that we haven't considered building this kind of facility before. This could be a game changer. Like vim package managers and other sensibly modern things, I totally expect to see this evolve to become the new norm.
I see this kind of configuration:
* global personal configs (lightweight, truly global settings for work and home)
* local overrides (work, home, per machine, non-SSH)
* remote overrides (SSH machines)
Global configs should be portable everywhere. For everything else, I see a system capable of merging several such configs and matching the current environmental and capability context.
I find it interesting that you say that, because my first thought was that this would be a step down from git pulling my dotfiles. All you need is to have a simple script that goes ln -s .zshrc ../.zshrc in your .dotfiles repo and getting a new shell up and running is as simple as running git pull && .dotfiles/setup.sh.
I like the idea of this in theory if you have machines that are frequently touched/overwritten, though, if you just want to have a baseline of sanity on them automatically when you log in.
Yeah I do this as well. But since I sometimes have to share remote accounts, customizing the environment often devolves into dotfile edit wars over stuff like "set -o emacs".
Love the elegant simplicity. Should we add something like this to Userify (https://userify.com) or perhaps offer to pull your dotfiles (.bashrc, .vimrc, etc) from Github?
I use vcsh [1] for all my config files on multiple servers, but normally for just my own account.
In the exact use case here, I would likely just store a bash script named .bash_ansible or similar on the target server and just source that manually at login, but the sshrc system looks like an easier way to maintain a config without leaving a footprint.
np. The funny thing is that sshrc is just a bash script, so it really could have come about 10 years ago. All it took was a few weeks of unemployment and refusal to believe that it couldn't be done. For those of you that opt out of reading the source but are curious as to how it works internally: the tool zips all your files, dumps them as hex code, and stuffs them into an argument string for the little known ssh -t option, which carries instructions to undo the whole process on the server side. As a side note, stuffing a linux filesystem into an argument string is the reason why your ~/.sshrc.d can be much bigger than a megabyte - bash doesn't like processing commands that are that long.
yes, but using a separate scp command requires a second round trip and second password/key authentication, which would double the wait time of the already slow ssh login process.
It's constructed entirely from builtin unix commands, so it's solid. The biggest risk is that someone could put malicious code into your ~/.sshrc, which would be run on the server. However, if they have write access to your $HOME directory, you're already in big trouble, as they could just as easily add something like `alias ssh='ssh "rm -rf $HOME"' to your ~/.bashrc.
I've seen tool after tool that tries to make SSH'ing into a remote machine more "comfortable", but I honestly don't do enough remote work over SSH to make it worth the time required to set it up. I probably spend an hour or two over SSH per week, and Ubuntu's minimalist shell defaults are perfectly fine for the little work I do.
[1] https://news.ycombinator.com/item?id=8324538