Appendices A, B, and C describe how to acquire and install GRASS. Before actually installing GRASS, you will have to decide where to put three parts of the system:
The GRASS binaries, source code (if you install this), man pages, documentation, and the like. Many folks put this stuff off /usr/local (e.g. /usr/local/grass/bin, /usr/local/grass/src).
The GRASS executable and gmake utilities. Some folks put this stuff off /usr/local (e.g. /usr/local/grass/grass4.1 and gmake4.1 or /usr/local/bin/grass4.1 and gmake4.1).
The GRASS data directories. These can go anywhere, as they are specified in configuration files.
I have used a different scheme for a decade. As GRASS code, binaries, and the like (except data owned by users) are all owned by the special user "grass" I don't want this stuff to get spread around my system. I create a new directory (usually on a separate file system) called /user, and put all my GRASS stuff below this. For example:
/user/grass4.1/bin (I usually put grass4.1 and gmake4.1 here...)
/data
/dev
/etc
/man
/src
/src.alpha
/src.contrib
|
I'm currently building a GRASS5.0 site, which then goes under:
/user/grass5/bin
/data (some GRASS5 data formats have changed...)
/dev
/etc
|
The GRASS Installation Guide (described in Section 10 and in Appendix C) is useful for getting GRASS running, even if you merely install the binaries as described in Appendices A and B. Please don't overlook one important detail: Most GRASS installations separate user from software manager accounts and UNIX permissions. You should create a "grass" (the quotes here are for emphasis, and should not be part of the actual user userid) user account on your workstation. All installation and configuration of grass should be done by user "grass". Untar (or un"cpio" files, run setup configuration utilities, run Gmakefiles (GRASS versions of makefiles), and edit configuration files as user "grass." Then only RARELY run GRASS as user "grass." (I only run GRASS as user "grass" when I am making archival data files in the PERMANENT mapset.) This is done for much the same reason as not running user software as user "root". YOU CAN DO TOO MUCH DAMAGE AS USER "grass"!
Beyond the instructions in these appendices, and information in the GRASS Installation Guide, you have some additional housekeeping to do, such as developing a data base. You can acquire sample data bases from USA/CERL (directory pub/grass/grass4.1/data at anonymous "ftp moon.cecer.army.mil"), start from scratch following instructions in the GRASS Programmer's Manual (and, to a lesser degree, buried in the functional descriptions of the GRASS User's Reference Manual).
I personally recommend that you start with the Spearfish and Global databases available from USA/CERL:
The Spearfish data base covers two 7.5 minute topographic sheets in the northern Black Hills of South Dakota, USA. It is in the Universal Transverse Mercator Projection. It was originally created by Larry Batten (now of the Environmental Systems Research Institute's office in Boulder, Colorado) while he was with the U. S. Geological Survey's EROS Data Center in South Dakota. The data base was enhanced by USA/CERL and cooperators. It is an excellent, and well-used (there are many training materials available for GRASS with this data base) example of a county-scale GIS project in the UTM projection.
The Global data base was developed by Bob Lozar of USA/CERL to prototype a latitude-longitude "projection" data base in GRASS for global environmental study and decision support.
Starting with these two examples, you can build your own data bases in UTM and latitude-longitude projections. (Note, many people don't call latitude-longitude a projection. Others disagree, saying that anything that transfers the Earth's surface to two dimensions is a projection.. We'll stay away from that debate here. Needless to say, lat-lon is treated as other projections are by the computer program.)