Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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.

share|improve this answer
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 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.

share|improve this answer

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/

share|improve this answer
"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 '12 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. – Nikhil Mulley Jan 12 '12 at 9:00

Your Answer


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.