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?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this communityTo 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.
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.
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/