linux directory tree

[Adam Hardy]

Hi All,
I'm installing stuff on a new computer, partly with RPMs (mysql-max, real-player, mozilla etc) and partly without (weblogic, jakarta stuff, etc).
I can't see the bigger picture with all the directories such as:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/var/lib
/usr/share
Is there any kind of guiding principle here?
The rpm's put executables into /usr/sbin, and mysql has its user databases in /var/lib/mysql, and weblogic has its user files in /usr/share/weblogic/...

[Michael Ernest]

To borrow a mild joke from Peter van der Linden: there's good news and there's bad news. The bad news is the good news isn't that good.
The good news is that a guiding principle does exist. However, it exists in the minds of several people who don't necessarily talk to each other, much less agree.
Some of the directory names are informed by a vendor's traditional usage along with a documented standard. The dominant forms of Unix these days follow a spec known as SVID, or System V Interface Definition. This document helps to ensure portability for systems and application programmers, and to a lesser degree systems administrators. /usr, /etc, and /var, among others, all have expected uses -- user-accessible resources, system configuration files and logging, respectively.
Then there are installation tool providers: RPM is exactly like a set of packaging tools in SVID, pkgadd(1M) and pkgrm(1M) among them. They don't necessarily implement or follow standards for pathing, but when used they help maintain the list of files added to a system to some common database. On Solaris, a SVID-conforming Unix, for example, this file is named /usr/sadm/install/contents.
Finally. you have what are sometimes called "tarballs," a tarred, zipped or perhaps jarred collection of files that expand into any directory specfied by a user with the proper permissions. They're delivered this way so users don't have to have root access to install them. Sometimes the vendor/distributor doesn't use a package manager out of ignorance or fear that it may limit portability.
Sometimes the default choices for bundled or packaged applications are strange anyway. For example, the default document location for Solaris' bundled Apache server is /var. With log files, mail files, printing spools...hunh? Then again, they don't really belong in /export (Solaris' intended default NFS target), where user files go. /usr/local seems like the right place, which is where we'd normally put it anyway if we were getting Apache from a freeware source.
So no, there's no one principle at work. Too bad for us.

[Adam Hardy]

Aha. So basically the best approach is to assume nothing and just try to remember where each file or directory for each application is?
When I last set up a windows system, I divided up my partitions into 4: one for windows, one for virtual memory, one for program files, and one for user data. It meant installing all software so that it kept its user data on the user drive, but it cut down fragmentation on all but one drive.
Linux doesn't suffer from file fragmentation on its file system, does it?

[Michael Ernest]

Aha. So basically the best approach is to assume nothing and just try to remember where each file or directory for each application is?

There are ways to manage, thankfully. A frequent user gets used to the conventions quickly. For people like me with a short memory for stuff that doesn't make me laugh, I write short "environment files" to track every one-off I have to deal with:
APACHE=/usr/local/apache
ACROBAT=/opt/Acrobat4
CDE=/usr/dt
and "source" them into my current shell. I don't know if bash has an environment variable like CDPATH, but I use it in my Korn environment with great vim and vigor (ok, mostly vim). CDPATH is a collection of absolute paths to directories you use often. Works like this:
CDPATH=$APACHE:$ACROBAT:$CDE
So that if you want to put in an apache subdirectory like htdocs, you can just type
$ cd htdocs
and CDPATH will search the string and fill in the blank for you in the same manner that PATH, MANPATH and FPATH (if you're a Korn shell programmer) all work. Sadly, to cd to a bin/ subdirectory in any one of these, you get the first thing CDPATH lists.

When I last set up a windows system, I divided up my partitions into 4: one for windows, one for virtual memory, one for program files, and one for user data. It meant installing all software so that it kept its user data on the user drive, but it cut down fragmentation on all but one drive.

Smart; also keeps data backup to a minimum. Naturally you're backing up your user data every night.

Linux doesn't suffer from file fragmentation on its file system, does it?

'Course it does, but of a far different sort that became the bugbear of the FAT32 world. If you ever had to defragment a unix fast-file based system, it's because your file system metrics are dead wrong for the kinds of files you're storing, and you'd be better off re-making the file system with the right constraints. Fortunately, that's never the case for general purpose use.

[Adam Hardy]

Korn shell's CDPATH sounds fantastically useful crossed with hideously annoying. You then have to remember the exceptions like you mention.
I see you're using /usr/local - on my last install with redhat 7, mozilla put itself in there. But on my new redhat 8 install, /usr/local is practically unused.
In fact it's got bin, doc, etc, lib, share directories, all empty. Any idea what's going on there? Seems to be mimicing the /

[Michael Ernest]

Korn shell's CDPATH sounds fantastically useful crossed with hideously annoying. You then have to remember the exceptions like you mention.

Just today I screwed myself for a minute or so by omitting '.' in my CDPATH. Couldn't go down one directory level before I fixed that. You cannot forget you're using it for too long.
However, today I am playing with Sun ONE Identity Server in a training class, which puts crap everywhere. Lucky for me, the files are mostly organized in three separate major directory points, and their subdirs mostly have different names -- CDPATH is really, really useful today. Tomorrow, who knows?

I see you're using /usr/local - on my last install with redhat 7, mozilla put itself in there. But on my new redhat 8 install, /usr/local is practically unused.
In fact it's got bin, doc, etc, lib, share directories, all empty. Any idea what's going on there? Seems to be mimicing the /

A couple theories. A bud in my office is big on Linux and big on installing whatever is new. If I get a chance to look at it I'll scan around and venture an opinion.

[Tim Holloway]

There IS supposed to be an ongoing process on standardizing where things go. It even has a name, which I forget
When you install a package via a tarball or similar system (e.g. ZIP), unless it has some sort of setup script the convention is that the files are laid out in the same general relationship that the overall OS directories have, but underneath the root of the unpacked tar. The big downside to this is that if you installed everything this way, you'd have a PATH that's unmanagebly long.
This is what RPMs and similar distribution mechanisms are good for - they register everything in the RPM database so that it's easier to update and remove files while keeping them in the OS paths rather than in application-specific paths. You can use the "rpm -ql" option to see the majority of them (script-generated files excepted).
The conventions for the standard system paths are:
"bin" for "general" programs,
"sbin" for "systems" programs (e.g. admin programs).
Then you have "/bin" vs "/usr/bin" and their sbin equivalents, which further distinguish between core apps and add-on apps. Some configs also do things like "/usr/local/bin", but fortunately that's much rarer (at least on modern-day Red Hat).
Not only Apache, but also Tomcat have shown a preference for appearing in "/var", alas. The place for major vendor-supplied apps is conventionally "/opt", which is a fair approximation of Windows "Program Files" directory. I keep Star Office and IBM program products there.
There now, that makes sense, doesn't it?

[Adam Hardy]

Do you mean the Filesystem Heirarchy Standard? I was looking at RedHat docs and saw it mentioned. Apparently RedHat conforms to it closely. Doesn't seem like it.
See it here pathname.com/fhs