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

Click here to return to the 're: 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.


[ 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
su root
#enter root password when prompted
make install

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


[ 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 | # ]