> I think the directory structure is a little odd at first, but once you > learn it it makes more sense (to me anyways). The one thing that still > bugs me though is all the variations of bin laying around.. /bin, > /usr/bin, /sbin, /usr/sbin, /usr/local/bin. Why is there a /bin and a > /usr/bin? and although I can see the logic of keeping root-only utils in > /sbin, if you have to be root to run them anyway, why not dump it all in > /bin? I'm planning to start doing this on some of my boxen, dump all the > files from /usr/bin, /sbin, /usr/sbin into /bin and then symlink the old > bin directories, since I assume stuff is compiled to look for /usr/sbin > and whatnot. Any reason why I couldn't do this? There's a /bin and a /usr/bin because, historically, /bin is on your partition/slice/volume containing / and /usr/bin is on your parition/slice/volume containing /usr. /bin conatins statically-linked file (files which _contain_ the libs the need to run, rather than "pointing" to the libs). If your drive/partition/slice/volume containing /usr craps out on your or the filesystem is corrupt, or you mount it via NFS and you're in single-user mode, then if you had all your binaries in there, you couldn't do _anything_ on the system, not even use ed or ex to edit your files, if need be. /sbin is for statically linked system binaries (stuff that only root generally runs). /usr/sbin is for mom-mission-critical binaries that only root generally runs. And the whole concept of /usr/local is appaling :) It was historically called /opt (optional stuff). Gabe -- ------------------------------------------------------------------------ Gabe Turner gabe at msi.umn.edu SGI Origin Systems Administrator, University of Minnesota Supercomputing Institute for Digital Simulation and Advanced Computation www.msi.umn.edu ------------------------------------------------------------------------