# Dropbox/bin

It’s so easy to see the inefficiencies in someone else’s workflows, but so hard to see them in your own. When you do finally root out some clumsiness in your setup—no matter how small—and replace it with a more streamlined system, it’s a cause for celebration. This is a small celebratory post.

I’ve kept my scripts in a ~/bin directory pretty much since I started using Linux in ’97. I’m not sure if I learned to do that from someone’s explicit advice or if I just copied the idea from someone. Either way, it’s a pretty common setup in the Unix world: you create this ~/bin directory as a personal analog of /bin, /usr/bin/, and /usr/local/bin; you modify your $PATH environment variable in .profile, .bash_profile, or .bashrc1 to include that directory; and then any executable script saved in that directory can be run from the command line without specifying the full path to it. The advantages of saving to ~/bin instead of one of the system wide bins are 1. You don’t need superuser powers to save or modify files in ~/bin. 2. ~/bin won’t get overwritten when you do a system update. When I moved to the Mac in 2005, I kept this same setup and it’s served me well. But there’s always been one catch. If you have two computers, your ~/bin directories won’t stay in sync unless you create some clever piece of automation to keep each directory up to date with changes in the other. I never did that. I tended to move new scripts written on one computer to the other through CD-ROMs, then USB thumb drives, and then, finally, Dropbox. I often forgot to move scripts and didn’t realize it until I needed one that only on the other computer. If you look up at the title of this post, you know what comes next, but for some reason it took me a couple of years of using Dropbox to figure it out. While it’s conventional in the Linux/Unix world to have your ~/bin directory just below your home directory, there’s no requirement for it to be there. It can be in any subdirectory of ~. In particular, it can be in ~/Dropbox/bin, where it will automatically sync between however many machines you have attached to that account. Even after I finally realized this was the way to go, I didn’t pull the trigger. I don’t know why. Maybe it was because I’d lived so many years with out-of-sync ~/bin directories; maybe it was because the tradition of ~/bin was so strong I was afraid to change. Whatever, today I finally copied the contents of ~/bin at work into ~/Dropbox/bin and then did the same at home (skipping over duplicates), so ~/Dropbox/bin has all of my scripts. A quick edit of my .bashrc to change export PATH=$HOME/bin:…


to

export PATH=$HOME/Dropbox/bin:…  on both machines and the transformation was complete. I now have directories for my scripts on both computers that are automatically synced. Hooray! In case you’re wondering, I have not deleted either ~/bin directory. There is absolutely no reason in the world for the new system to fail, which is all the more reason to keep a backup for when it does. 1. Or whatever the equivalent is for zsh if you’re one of those weirdos. ## 5 Responses to “Dropbox/bin” 1. DropBox syncs symbolically linked directories, so my approach would be to leave bin in ~ but do ln -s ~/bin ~/Dropbox/bin to sync it to other machines. It is a bit sloppy though, so I can see why it’s cleaner to just move stuff over. 2. I do the same thing with a subset of my dot files. They live in ~/Dropbox/etc and are symlinked into place in ~/. It makes it really easy to deploy new shell aliases in .bash_profile, .vimrc changes, or whatever suits your fancy. After setting up a number of systems this way by hand, I threw a quick a script into ~/Dropbox/bin that creates the symlinks for me. 3. Daniel says: Off topic: I really like the new sidebar ads with the description. Says more than just an icon and I like to read your stuff, even when it’s about coffee tea mugs. 4. In addition to the general symlink idea, may i suggest Stow? Suppose you have your .zsh* dotfiles on your system somewhere (say, in Dropbox). Run stow -t$HOME zsh


(where zsh is the parent directory), and it takes care of the symlinking. This is my approach to managing dotfiles, my Emacs setup files, etc. (And yes, I am one of those weirdos.)

5. The problem with doing symlinks in this case was that I didn’t have a canonical version of ~/bin to work from. Each computer had scripts that were unique and valuable. Also, since I can put any directory I want into my \$PATH, there didn’t seem anything to gain from symlinking.

Dotfiles and ~/Library/Preferences are a different story. They have a set location that must be honored and symlinks are the only way to get them into Dropbox.