Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

When I download command line applications they are located in my ~/Downloads/ directory. But I feel this is wrong place to have a command line application located. Where in the Mac OS X filesystem should I store command line applications?

/Applications/ also feels wrong, it´s more for desktop applications. And /bin/ sounds more for applications that belongs to OS X.

share|improve this question
    
I agree with your sentiment that putting things directly in /bin or /Applications is generally poor form. Patrix's answer is the most canonical location I've seen for general command line storage of programs and scripts. –  bmike Aug 11 '13 at 17:49
    
Duplicate: apple.stackexchange.com/q/80902/20459 –  rm -rf Aug 11 '13 at 20:47
2  
I don't see these as duplicate since the linked question seems more about juggling several third party choices and this is more a pure - where do my manually downloaded apps go. –  bmike Aug 11 '13 at 22:30

2 Answers 2

up vote 33 down vote accepted

Since OS X comes from a unix heritage, you will want to store system files in /usr/local/bin for command line applications and scripts that belong to the system locally and not to a specific user. You may need to create this directory first by running:

sudo mkdir -p /usr/local/bin

You can move any command line application to that folder by running:

sudo mv my-binary /usr/local/bin/

To make sure that /usr/local/bin is part of your standard search path in Terminal, check the content of /etc/paths and add it if necessary:

grep -w /usr/local/bin /etc/paths || sudo sh -c 'echo /usr/local/bin >> /etc/paths'

Some users make a second directory for user level scripts, but this is even more subject to personal preference.

I typically make a bin directory in each user folder and then hide it from Finder - but you can make that decision yourself whether you want it hidden:

 mkdir ~/bin
 chflags hidden ~/bin

In this case, you'll want to have each user's path include this location by modifying the shell startup scripts (~/.bash_profile for bash which is the standard shell)

 export PATH=$PATH:~/bin

or by hard coding the path to each app when you run it.

share|improve this answer
3  
This is absolutely the best suggestion, and the one that I would give to anyone who asked. I'll add only 2 things: 1) /etc/launchd.conf might also be a place where the path needs to be added, 2) although I use /usr/local/ for Unix utils installed via homebrew for my own shell scripts I have a ~/Dropbox/bin/ which I also added to my $PATH so I have all my custom shell scripts on all of my Macs. But I do that in addition to /usr/local/bin/ not instead of it. –  TJ Luoma Aug 14 '13 at 1:41
    
/usr/local/bin is the traditional UNIX spot for a user's scripts, which gives access to any other user on the system. Placing scripts there will put the scripts in all users' $PATH effortlessly. But I believe the Mac way, since most Macs have a single user, is to create a ~/bin directory, make it invisible with chflags uchg ~/bin, and add it to the users ~/.bash_profile to make it part of the users $PATH. ~/bin is a superior location for security and migration. Otherwise, you have to remember about the stuff you left in /usr/local/bin. And ln -s ~/bin ~/Dropbox/ is also nice. –  chillin May 13 at 9:05

Consider creating an /opt directory, which is another location that custom Unix software would appear by convention.

share|improve this answer
4  
/opt/ is very useful for complete applications whereas /usr/local/bin/ is more appropriate for standalone command line scripts. It is often preferable to use /opt/ in instances where a collection of related scripts act as a library (e.g., /opt/myscriptslib/bin/). –  plasmid87 Aug 12 '13 at 10:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.