Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Better disk usage information UNIX
The UNIX environment has two common commands for looking at disk usage - 'df' and 'du'. 'df' returns information about all mounted disks, and 'du' returns information about a given file or set of files. As installed in OS X, though, the 'df' and 'du' commands do not return easy to use information. For example, here's the 'df' output for one drive on my system:
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/disk0s9 3121344 1314624 1806720 42% /osxfiles
Wouldn't it be much nicer if you could have it output like this:
Filesystem            Size  Used Avail Use% Mounted on
/dev/disk0s9 3.0G 1.3G 1.7G 42% /osxfiles
Read the rest of this article if you'd like to learn how to create a more usable "df" (and other!) commands.

NOTE: I have packaged four of the more useful of these utilities (ls, dircolors (sets the colors for the new ls), df, and du) into one downloadable archive. These are pre-compiled, and you'll just need to expand the archive with OpenUp or the command line (or the new StuffIt Expander). Move the files into /usr/localbin, and they should be ready to go. I have NOT included the 'man' pages, since I wasn't sure how to do that - read the GNU online help for info on each command, or compile the whole package.

I'd seen references to a "human readable" version of 'df' in various places, but the command ('df -h') failed on OS X - the '-h' option is not known. So last night I went out to the GNU website, and took a look at their page of available software. One of the packages listed is 'fileutils,' which includes a number of file utilities, including versions of 'df', 'du', and 'ls' with the color option. GNU has a page that describes each program in the package, along with a full set of instructions in just about any format you might want. So I downloaded version 4.0 of the package (GNU's web site has a list of other mirrors) and set out to install it. This was my first-ever attempt at a compile and install under OS X, so I wasn't sure what was going to happen.

NOTE: The following instructions assume you have the developer's tools for the PB, which are available on Apple's Developer website (you have to register for a free online membership). I make no claim that the following steps are safe for your system; I am a complete novice at UNIX compilation, so I may have done some things incorrectly (please, osxhints UNIX experts, correct me if you see mistakes!). Use at your own risk...that said, my machine still seems stable and usable :-).

The basic installation was fairly straightforward. Download the package and expand it, and you'll wind up with a directory named fileutils-4.0. Here's what you do next.
  1. Start a terminal session, and become root ('su' and your root password).
  2. cd /path/to/fileutils-4.0
  3. ./configure
    This runs a script which attempts to set the proper variables for a proper compile on your system. It takes a while (five minutes?) to run.

  4. Compile the package by typing
    make
  5. Install the programs and documentation by typing
    make install
    End your root session by typing 'exit'
That's really all there is to the installation. You'll see quite a few messages go by during each of these steps, but there's no required interaction. The compiler will install the pacakges into /usr/local/bin, and the man pages into /usr/local/man.

In the tcsh shell path (you can view it by typing 'setenv'), the /usr/local/bin directory appears in front of the system-wide /bin directory. So the newly installed commands should work from any directory. Try df -h in some directory, and see if you get the sample output shown above. You can also try the color ls command, with ls --color.

In order to get the "man" pages working for these new commands, you need to modify the MANPATH variable. You can set this once, and it will remain in effect for future termina sessions. MANPATH tells 'man' where to look for manual pages. Type the following into your terminal:
setenv MANPATH /usr/local/man:/usr/share/man:$MANPATH
This inserts our new local man pages ahead of the existing path, so when you type 'man ls', you'll get the man pages for the new command instead of the old. To use any of the old commands, you'll need to put their path in front of them, like this: /bin/ls, /bin/df, etc.
    •    
  • Currently 3.00 / 5
  You rated: 4 / 5 (4 votes cast)
 
[9,344 views]  

Better disk usage information | 4 comments | Create New Account
Click here to return to the 'Better disk usage information' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
re: Better disk usage information
Authored by: Anonymous on Mar 09, '01 11:55:17AM

Hi -

I haven't had a chance to work with OS X yet, but have worked for several years with various flavors of Unix (AIX, HP-UX, Solaris I & II, DEC OSF). Unix being Unix, there are lots of ways to write/install custom commands without affecting the delivered versions. One way is with aliases, especially if you want to use a lot of switches and have trouble remembering them, or want to execute a common series of pipes with less effort (e.g. alias -x paths='echo $PATH | awk -F: '"'{for (i=1; i<=NF; i++)"' printf("%sn"),$i}'"'"). Another way is by manipulating the PATH environment variable. This is typcially done in your .login (for Bourne/Korn users) or .profile (for C shell users). You place the custom command somewhere (/usr/bin is common), then modify your PATH so that /usr/bin is referenced before /bin (or wherever the standard command is located). For example (assuming /bin is already in the PATH), PATH=/usr/bin:$PATH. Your customized command will then be located and executed before the standard command, but the standard command is still available for use by specifying the absolute path (e.g., /bin/ls instead of ls). As a security point, if you are running a multi-user environment, the PATH for root (or any user with root priv) should ALWAYS specify /bin before any other path (including '.'). This way, if you are in another users directory who happens to have written a command that uses the same name, but executes a different result, you don't accidentally run the customized command with root priv. To verify the specific executable image/script will be used when you invoke a command, use the "which" command (e.g. "which ls"). On some flavors of Unix, the "which" command will recognize and report that the command is actually an alias, and show you what it is aliased to. Unfortunately, some flavors won't do this (HP-UX 11.0 being one). If the command can't be found, or the alias expanded, "which" reports "no [command] found in [your expanded PATH variable]". Hope this help more than confuses.

I'm not familiar with manipulating the man pages.

Tim



[ Reply to This | # ]
Getting man pages to work
Authored by: _merlin on Mar 09, '01 08:45:06PM

The reason the man pages are unavailable is that Mac OS X expects to find them in share/man, not man (as many other UN*Xes do). To solve this problem, use the following commands to build and install the programs:

./configure --mandir=/usr/local/share/man
make
su root
#enter root password when prompted
make install
exit
rehash

What we've done different is to tell the configuration script which directory the manual pages should be placed in, and told the shell to "rehash". That is, to scan the implicit executable search paths for now programs.

Vasantha Crabb



[ Reply to This | # ]
Getting man pages to work
Authored by: sven on Mar 10, '01 08:16:40AM

I can't verify this right now (wish PB would run on Titaniums...) but I believe OSX also honors the MANPATH environment variable. So you could add additional directories to your MANPATH:

setenv MANPATH /usr/share/man:/usr/local/man:$MANPATH

-Sven



[ Reply to This | # ]
Getting man pages to work
Authored by: _merlin on Mar 11, '01 04:44:59AM

It only honours the environment variable if you delete your man.conf file. You can edit the file to make it search more directories (you can find it at /etc/man.conf). I think it's a better solution to just use the directories the OS likes.





Vasantha Crabb



[ Reply to This | # ]