I thought the bin directory is the place for binary files. If so, what about script files? Should they be placed somewhere else?

What's the history of bin directory and where should I put script files if the bin means binary?


4 Answers 4


To my mind, bin means something more along the lines of "executable" than strictly "binary". (In the end, all files are binary.) There are quite a few script files even in /bin; on my Debian system, file /bin/* | grep -c 'shell script' says there are 19 shell scripts right there. Sitting in /usr/bin I have another 325 shell scripts.

If your script is usable as if it was a compiled application, just drop it in an appropriate bin directory, as that's where people would expect to find it. If it is a simple helper script, it may be better to put it in a separate directory, just to emphasize that it isn't really an application of its own.

  • One might also consider the fact that bash scripts do indeed call executable files, so even though they themselves aren't binary (in the contextual sense of the word) they operate using binary/executable files.
    – jbowman
    May 13, 2016 at 21:23

In the earlier times of Unix, the /bin directory was only containing compiled binary files. Scripts came there later. At least from version 7 which introduced the #! interpreter convention but probably later.


With regard to the meaning of the /bin directory, to quote the intro(0) manual page source from the Unix Research V3 snapshot now available on github and elsewhere:

Commands generally reside in directory /bin____ (for
bin___ary programs).

This same text appears in The Unix Programmer's Manual (implicitly the first edition), in the Introduction, from 1971.

As far as I can tell there were no user commands supplied as scripts in early Unix and it was not until V6 that two scripts first appear in /usr/bin by which time the convention of searching /bin and /usr/bin for commands was very well established and so that would be the natural place to put them -- there was never any need to segregate them from "binaries", and there still isn't.

  • Generally resides... which means it's doesn't have to be!
    – Eonil
    Jun 14, 2017 at 4:07

Regarding the reason, why it is named that way, and why not, /exec or some other name, it all goes way back to the old and early Unix days where people had a choice to pick very lame names, as was used only in development stages and did not put much thought that in near future Unix will be ubiquitous choice for computing then. Linux which took on the bandwagon and carried the legacy of Unix style like OSs(read POSIX style implementations), had also somewhat got influenced in the areas of filesystem specifications and standards. However, soon at evolving times of Linux, as it was getting wide acceptance, standards specific to Linux started emerging into the picture. Among the standards, Linux Filesystem Hieararchy standards(LFHS), describes the need to organize the system filesystem hierarchy and the naming locations in the filesystem tree hierarchy.

As far as Linux filesystem hierarchy goes, and FHS project spec documentation is at http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/

/bin directory contains several useful commands that are of use to both the system administrator as well as non-privileged users. It usually contains the shells like bash, csh, etc.... and commonly used commands like cp, mv, rm, cat, ls. For this reason and in contrast to /usr/bin, the binaries in this directory are considered to be essential. The reason for this is that it contains essential system programs that must be available even if only the partition containing / is mounted. This situation may arise should you need to repair other partitions but have no access to shared directories (ie. you are in single user mode and hence have no network access). It also contains programs which boot scripts may depend on.

So, it is not necessary they have to be binary executable files (ELF files) but also scripts which are executable and are essential for system functioning, that can go into /bin directory.

Also, I want to note here that these standards have been in place, I guess, almost for more than 30 years. In rapidly changing times, people may come with new standards which might completely remove the current notations used in the hierarchy. One of the recent such animal online is objectRoot, which is a recently published proposal to redesign and remove the hierarchy inconveniences. For more details: http://objectroot.org/root/

  • "early Unix days where people had a choice to pick very lame names, as was used only in development stages and did not put much thought that in near future Unix will be ubiquitous choice for computing then..." That is incorrect. See this answer for the correct reason...
    – jasonwryan
    Jan 11, 2012 at 21:22
  • hmmm..yes, another factor to choose the names as they are today. Thanks @jasonwryan for the link. In modern systems, we do not have issues or concerns for speed, bandwidth, performance, atleast for input devices, but still we are living the old days. Not necessarily an inconvenience but still we need to modernise the hierarchy for today's needs. Objectroot attempts to redesign it, but truth to be told, I have no idea, whether it will be a success. Jan 12, 2012 at 9:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .