Are all files created equal?

[chzlchp]

Somebody please pull back the haze covering this concept in my mind. I read (e.g.) where this or that particular application, when downloaded, should be put in the (for instance) /bin directory, or some other. Why? Is there something unique about the files/file structure (??) in /bin as opposed to, say, /etc, or any other directory? Or is the advice being offered only an attempt to maintain the symmetry (POSIX standard) of the directory system? Would the app. work differently if I put it in any random directory?

An example--I have downloaded, and maintain, an F@H instance, that I secreted into a subdirectory of my /home. To my [mild] surprise, it works perfectly. I [think] I understand that its' existence is only known to my ~/, as opposed to the entire system. That's fine. I'm the only user, so it's a moot point.

[ph34r]

You can put anything anywhere, but you can expect troubles at times... sometimes things look for other things in specific places only, your $PATH looks in specific places for binaries only, etc.

[Hayl]

we have a document that explains the standard *nix filesystem structure in our help file library.

[chzlchp]

My question was not hierarchal in nature, but more of an 'inter-dependence' nature. i.e., did the files ensconced in, say, /bin have some unique structure to them that required their being gathered together under that discrete umbrella in order to work correctly? or is this a hierarchy designed for its' logical structure?

To wit, my question was...if an applications' author recommended his tar file be downloaded to, say, /bin to be worked upon, and I instead (quite arbitrarily) put it in, for instance, the /etc directory, would I [probably] get the same intended results once I scrunched the new app. according to its' dictates? Would it live, work, and make new friends in either of those two directories just as seamlessly?

[hard candy]

/bin in Unix machines was usually reserved for system wide apps/executables, /sbin was more for specialized apps, and then you have /usr/sbin, /usr/local/sbin, etc. If a program is coded to look for libraries in certain places or is to make a link to other files depending on its location, it may fail unless you point it to look in the correct directory.
You could compile/recode a program to work from numerous places.
As an example let's look at Mozilla. It can be placed in several different places depending on your preferences. And if you "tell" it where to look for java, plugins, scripts, fonts, etc it will run from any location as long as it can find what it needs to start up.
Convenience and compatability are the main considerations when developers decide where to place a app/file/etc. If most every developer uses the same location for certain files, everyone (user,admin, developer) has a little easier time.

[sharth]

I always remembered the main idea behind it was just a logical sorting of all the files.

In specifc, the /usr/bin vs /bin was the idea behind what happens if /usr is on a mountable nfs drive or something like that, and then what files are needed on the root filesystem to mount that drive.

[chzlchp]

Whew! Well, there you are! Thanks for the time and answers. Much was illuminated for me. This was one of those little things that I was 'hung up' on, and I needed to clarify it in my mind to move on. Ya'll have very generously done so. The answers here sorta square with (but are a greate amplication on) what I had kinda surmised from my 'manning' and 'googling'. Thanks again, all.

[bwkaz]

Read the FHS:

http://www.pathname.com/fhs/pub/fhs-2.3.html

Specifically:

/bin
/lib
/sbin
/usr/bin
/usr/lib
/usr/sbin
/usr/local