spir posted on Wed, 09 Dec 2009 11:51:11 +0100 as excerpted:
> Great explaination of one thing I guess unix/linux/bsd/etc... have
> wrong! To even a power user, linux filesystem is just a huge chaotic
> mess, unexplicable, unmanageable, random-like organisation. It's simply
> impossible to guess or remember where things are supposed to live. Two
> seemingly identical install cases will actually not produce same install
> locations, and locations even change with versions.
I'd disagree. Maybe it's because I had a /proper/ explanation of where
stuff goes and why, from reading the books I mentioned in another post,
but I have a reliable enough understanding of the filesystem that I, for
instance, don't use the locate service at all, having turned it off and
uninstalled it years ago. There's places where stuff /goes/, and I get
very peeved as a user AND my own sysadmin, if something breaks those
rules, and puts stuff in unexpected locations (and data or config in a
bindir would be entirely unexpected).
Core-system config goes under /etc. That's where boot-time services,
etc, normally have their config. Early boot binaries go in /bin for
executables and /lib (/lib64 in many 64-bit installation, that's the
standard FHS, file hierarchy standard, location for amd64 aka x86_64, but
ia64 uses /lib for 64-bit and puts 32-bit elsewhere) for libraries.
/root is the root user's homedir. All those are normally on the rootfs,
because in many cases they're used early enough in the boot that other
filesystems aren't yet mounted, with /root there so a root login works as
expected in single-user-mode, again when other filesystems are
traditionally not mounted. The rootfs is often mounted read-only in
normal operation, particularly on more secure installations like public
internet facing servers (ideally), etc.
System stuff that's not core enough to be needed before filesystems other
than rootfs come online, lives under /usr. /usr therefore has its own
bin and lib dirs, with /usr/share corresponding to /etc, and including a
documentation subdir /usr/share/doc . Often, /usr does not live on the
rootfs and must be mounted during the boot process. This is the reason
binaries and config used for early system boot cannot be in /usr.
There's also a /usr/local, generally used for stuff the sysadmin installs
from source, or that the system's normal package manager doesn't know
about or manage. Package managers are supposed to leave this alone,
unless specifically told otherwise by the sysadmin. Again, this is often
a separate partition, for ease of administration.
/mnt is the traditional location for temporary mountpoints, and remains
the usual location for manually mounted filesystems. /media is the newer
location for temporary mountpoints. It's normally used by/for hal
assisted auto-mounting, etc. These will of course exist on the rootfs,
tho their subdir's contents of course is assumed NOT to be, because
that's the point, these are the locations for temporarily mounted
filesystems.
/var (various or variable data) is the system's data dir. This is where
print-spools, system mail spools if the system's running its own mail
system (not just a mail client for each user), the distribution's package
database, and other similar services, normally keep their data and
caches. Again, /var is often on its own filesystem.
/var/log is of course under /var, for logging, but is often kept as its
own separate filesystem in ordered to contain the damage should something
go wrong and the logs start to fill with errors, perhaps many a second.
A full rootfs or /var can be a bit difficult to recover from and may
involve other more important data being lost, while a full /var/log is
much easier to recover from and generally the only thing lost is the logs
from the point at which it filled up to the point at which a sysadmin
noticed and corrected the problem. Of course, professionally managed
systems normally have a cron job checking the status of the filesystems
and mailing warnings to the sysadmin well before they entirely fill up,
but /var/log is still a useful precaution, even more so on systems
without this level of monitoring and notification.
/dev was traditionally a static dir existing on the rootfs, its contents
a bunch of special files, device nodes, one for every conceivable device
a normal system might have, whether they did or not. These days, on
Linux, it's generally a tmpfs or similar RAM based filesystem, managed by
udev in cooperation with the Linux kernel, such that only devices that
actually exist on the system appear here.
/sys and /proc are similar "virtual" filesystems, at least on Linux,
setup and managed by the kernel, tho a sysadmin doesn't /have/ to
actually mount them (but a lot of functionality will be missing if he
doesn't). Linux kernel developers may also have a /debug virtual
filesystem, similarly kernel related, tho that's relatively uncommon and
of little use for those not doing kernel debugging.
/tmp is where temporary files go. On today's multi-gig-memory systems,
/tmp is often not even on-disk, but a tmpfs or other RAM based filesystem.
/dev/shm is the standard location for a normally much smaller tmpfs
(shmfs being the former name for tmpfs), designed to be used for lock-
files and other very tiny, often very temporary (seconds to minutes),
files. A 20 MB max size should be plenty, if you are configuring it in
your /etc/fstab. However, while standard, this one's obscure enough not
all distributions have it, so few apps actually use it, preferring
something in /tmp or the user's ~/tmp, which are far more certain to
exist.
/home is of course the standard location for user's homedirs, and
probably the most common separately mounted system filesystem, as having
it on its own filesystem makes keeping the user data during system
upgrades very simple -- just don't mkfs the existing filesystem used for
/home.
Let's bring up "hidden" files and the parent and current directory
entries, here. On *ix, a filename beginning with a dot (.) indicates a
hidden file that will not normally be listed or displayed in a
filemanager, unless the option to view hidden files is enabled. The two
most common directory entries of that type are "." and "..", the single
dot referring to "me", that is, the current directory, with the double
dot referring to the parent dir. Thus, all directories have a "." (that
is "me") entry, and with the sole exception of / itself, all directories
have a ".." entry referring to their parent. Other .* entries may exist
as well, but they're deliberately created, either by the user/sysadmin,
or by a program such as the system package manager while installing a
package, or the like. Thus is born the possibility of trying to
"rm .test", for instance, and accidentally getting an extra space in
there, so it becomes "rm . test". By itself that's not too bad, but add
the recursive switch so it recurses into subdirs, and if you're operating
on a file in /, **BAD** things can happen! A variant on the theme is
"rm .*", forgetting that ".*" includes ".."! I once did something close
to that in a script, as a result of a typo in a variable name, such that
the variable was empty and the script started at / instead of in the
directory it was supposed to start in, as stored in the (non-typoed)
variable! This is one reason you're not supposed to run as root by
default -- or test your scripts as root!! Tho a user testing a similar
script could as easily lose everything in his homedir, which could be
worse, if it's not backed up as it should be.
That covers the main standard "system" dirs. The layout of /home/$USER
(commonly seen as ~/ or $HOME, $ of course referring to an environmental
variable with $HOME and $USER being standardized) is, unfortunately, not
as standardized. However, a user who cares can quickly grasp the general
layout used by the applications they normally use, and manage them
appropriately.
As with the system, there's normally a ~/bin for the user's own
executable scripts and misc. binary executables they may run, having
built or at least installed them, themselves. This and a ~/tmp, which
may simply be a symlink to a user subdir of the system /tmp (especially
if the system /tmp is tmpfs, thus ensuring that it's wiped clean at every
boot), are relatively standard.
Depending on the desktop environment, a ~/Desktop is also fairly
standard. It contains the files traditionally shown as icons on the
desktop.
Beyond that, nearly all non-user-created files and subdirs of ~/ are
hidden. ~/.config is a standard hidden dir, tho unfortunately a late
enough standard that far too many applications store their user data in
hidden files or directories directly under ~/. .bashrc is probably the
most common individual config file under ~/, as it's where one sets up
their own shell environment and does various other user initialization
tasks, but there's typically dozens of hidden files and dirs in $HOME.
As this is a kde list, it's worth noting that kde's user homedir is
normally either ~/.kde or ~/.kde<ver>, where <ver> may be 3 or 4
depending on what you are running. Under that, there's a few socket
files that kde uses to communicate between programs, a share directory
containing most user kde config, and a couple other misc. dirs.
The ~/$KDEDIR/share directory further contains various subdirs, mirroring
those in /usr/share that store the system config. The two most
interesting subdirs in terms of config are apps and config. If your kde
app uses only a single config file (typically suffixed with rc) or two,
these files should be named according to the app, and placed in config.
If your kde app uses more than a couple config files, they should be
placed in a subdir named after your app, and placed in apps.
Really, there's nothing confusing at all about any of that, once you
understand why it's done that way, altho that may indeed require being
actually motivated enough to look and find a proper explanation such as
this. It may take some learning initially, and some getting used to
thinking that way for a few weeks after that, but it quickly becomes
second nature, and it's relatively easy to find any particular file
because knowing its purpose, it's almost certainly in one of only a
couple standard locations, with a quick browse (for the gui folks) or ls
(for the cli folks) of the filesystem in those locations quickly
revealing the file of interest. Autocompletion, using tab at the CLI (at
least in bash) or assuming your GUI filebrowser is sophisticated enough
to support such functionality, makes it even easier.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
