grass(1)

📦

version 8.4.2 · 11 versions

💖 grass(1) — GRASS startup program 💖

okay bestie, listen up, because this is the entry point to literally everything in GRASS GIS. the page is grass(1), from the GRASS GIS User's Manual, and it's long, so we're doing this in parts. part 1 starts now, no skipping, i promised i'd keep every single detail 🫶

✨ SYNOPSIS ✨

grass [-h | -help | --help] [-v | --version] | [-c | -c geofile | -c
EPSG:code[:datum_trans]] | -e | -f | [--text | --gtext | --gui] |
--config | [--tmp-project | --tmp-mapset] [[[<GISDBASE>/]<PROJECT>/]
<MAPSET>] [--exec EXECUTABLE]

🎀 Flags

-h | -help | --help — prints a lil brief usage message and then dips. very "just the basics, bye".
-v | --version — prints the version of GRASS and exits. that's it, that's the whole job 💅
-c XY — creates a new GRASS project (location) without a coordinate reference system, in the specified GISDBASE.
-c geofile — creates a new GRASS project in the specified GISDBASE, with the coordinate reference system taken from a georeferenced file.
-c EPSG:code — creates a new GRASS project in the specified GISDBASE, with the coordinate reference system defined by an EPSG code.
-c EPSG:code:datum_trans — creates a new GRASS project in the specified GISDBASE, with the coordinate reference system defined by an EPSG code plus datum transform parameters.
-e — exit right after the project or mapset gets created. only works with the -c flag, bestie, it's a package deal.
-f — forces removal of .gislock if it exists. > use with care!! 😭 only works with the --text flag.
--text — says "we're doing the Text-based User Interface", and it skips the welcome screen.
--gtext — says "Text-based User Interface please", but this time it shows the welcome screen.
--gui — says "give me the Graphical User Interface (wxGUI)". main character energy 🦋
--config — prints GRASS configuration parameters. the options are: arch, build, compiler, date, path, python_path, revision, svn_revision, version.
--exec EXECUTABLE — executes a GRASS module or script. the executable you hand over runs inside a GRASS GIS non-interactive session.
--tmp-project — runs using a temporary project, which gets created based on the given coordinate reference system and deleted at the end of the execution (use it together with the --exec flag). the active mapset will be the PERMANENT mapset. so iconic of it.
--tmp-mapset — runs using a temporary mapset, which gets created inside the specified project and deleted at the end of the execution (again, use it with the --exec flag).

🌸 Parameters

GISDBASE — the initial database directory, and it should be a fully qualified path (like, e.g., /usr/local/share/grassdata).
PROJECT — the initial project directory, which is a subdirectory of GISDBASE (fun fact: project was previously called location).
MAPSET — the initial mapset directory, which is a subdirectory of PROJECT.

Note: these parameters must be specified in one of the following ways: - MAPSET - PROJECT/MAPSET - GISDBASE/PROJECT/MAPSET

💜 DESCRIPTION 💜

this command is what launches GRASS GIS. it parses the command line arguments and then initializes GRASS for you. and because GRASS modules require a specific environment, this program must be called before any other GRASS module can even run. no grass, no modules, periodt. the command line arguments are optional tho, and they give you a way to say which user interface you want and which mapset you wanna work on.

the startup program has memory, fr fr — it remembers both the user interface you wanted and the mapset. so next time you run GRASS and just type grass with no options at all, it'll start up with the previous settings for the user interface and the selected mapset. convenient ✨

if you specify a graphical user interface (--gui), the grass program will try to verify that the system you specified exists and that you can access it successfully. and if any of those checks fail? grass automatically switches back to text user interface mode. it's giving "okay we tried, we pivot" 😭

🧚 Running non-interactive jobs

the --exec flag can run an executable on path, a GRASS module, or a script. all of them get executed as a subprocess, and any additional arguments are passed to it. a script needs to be specified by full or relative path, and on unix-likes systems the script file must have its executable bit set. calling the interpreter (e.g., python) and providing the script as a parameter is possible too. when it's finished, GRASS will automatically exit using the return code given by the subprocess. and even though the execution itself is non-interactive (no GUI or shell), the subprocess itself can be interactive if that's what the user requires. flexible queen 🫶

👑 Config flag

the flag --config option prints GRASS GIS configuration and version parameters, with the options:

arch: system architecture (e.g., x86_64-pc-linux-gnu)
build: (e.g., ./configure --with-cxx --enable-largefile --with-proj [...])
compiler: (e.g., gcc)
date: (e.g., 2024-04-10T11:44:54+00:00)
path: (e.g., /usr/lib64/grass)
python_path: (e.g., /usr/lib64/grass/etc/python)
revision: (e.g., 745ee7ec9)
svn_revision: (e.g., 062bffc8)
version: (e.g., 8.4.0)

🍓 SAMPLE DATA 🍓

the GRASS GIS project provides several free sample geospatial datasets as ready-to-use projects. they're available to download at https://grass.osgeo.org/download/sample-data/. the "North Carolina data set" is a modern package of geospatial data from North Carolina (USA), and it includes raster, vector, LiDAR and satellite data. this is the most extensively used data set in the documentation, and the examples throughout the user manual pages are based upon it. so yeah, if you're following along with docs, it's probably this one 💅

🌈 ENVIRONMENT VARIABLES 🌈

a number of environment variables are available at GRASS startup to assist with automation and customization. most users will not need to bother with these. (but i know you're not "most users", bestie 🎀)

in addition to these shell environment variables, GRASS maintains a number of GIS environment variables in the $HOME/.grass8/rc file. user changes to this file will be read during the next startup of GRASS. if this file becomes corrupted, the user may edit it by hand or remove it to start afresh. see the list of implemented GRASS variables for more information. the rest of this help page will only consider shell environment variables.

Note: you'll need to set these variables using the appropriate method required for the UNIX shell that you use (e.g. in a Bash shell you must export the variables for them to propagate). don't forget the export, i'm begging 😭

🦋 User Interface Environment Variable

the grass program will check for the existence of an environment variable called GRASS_GUI which indicates the type of user interface for GRASS to use. if this variable is not set when grass is run, then it will be created and then saved in the $HOME/.grass8/rc file for the next time GRASS is run. it can be set to text, gtext or gui.

there is an order of precedence in the way grass determines the user interface to use. here's the hierarchy, from highest precedence to lowest:

Command line argument
Environment variable GRASS_GUI
Value set in $HOME/.grass8/rc (GUI)
Default value - gui

🐍 Python Environment Variables

if you choose to use the wxGUI interface, then the GRASS_PYTHON environment variable can be used to override your system default python command.

suppose for example your system has Python 3.6 installed and you install a personal version of the Python 3.8 binaries under $HOME/bin. you can use the above variables to have GRASS use the Python 3.8 binaries instead.

GRASS_PYTHON=python3.8

⭐ Addon Path to Extra User Scripts

this environment variable lets the user extend the GRASS program search paths to include locally developed/installed GRASS modules or user scripts.

GRASS_ADDON_PATH=/usr/mytools
GRASS_ADDON_PATH=/usr/mytools:/usr/local/othertools

in this example above, the path(s) would be added to the standard GRASS path environment.

🧁 Addon Base for Extra Local GRASS Addon Modules

this environment variable lets the user extend the GRASS program search paths to include locally installed (see g.extension for details) GRASS Addon modules which are not distributed with the standard GRASS release.

GRASS_ADDON_BASE=/usr/grass-addons

in this example above, the path would be added to the standard GRASS path environment.

if not defined by the user, this variable is set by the GRASS startup program to $HOME/.grass8/addons on GNU/Linux and %APPDATA%\Roaming\GRASS8\addons on MS Windows.

🌸 HTML Browser Variable

the GRASS_HTML_BROWSER environment variable lets the user set the HTML web browser to use for displaying help pages.

✨ EXAMPLES ✨

okay bestie, gather round, because this is the part where we actually drive the thing 🚗💨. Here are some ways you could start GRASS:

grass — starts GRASS with the default user interface. You'll get prompted to pick your project and mapset, no stress 💅
grass --gui — starts GRASS with the graphical user interface. Still prompts you to choose the right project and mapset 🖥️✨
grass --text — starts GRASS with the text-based user interface. Here the appropriate project and mapset must be set by environmental variables (peep the examples below) otherwise they're taken from the last GRASS session 👀
grass --gtext — starts GRASS with the text-based user interface, and this time you get prompted to choose the appropriate project and mapset 🎀
grass $HOME/grassdata/spearfish70/user1 — starts GRASS with the default user interface and launches you straight into the given mapset, completely bypassing the mapset selection menu. icon behaviour fr 🏃‍♀️💨
grass --gui - — starts GRASS with the graphical user interface and tries to obtain the project and mapset from environment variables 🧚
grass -c EPSG:4326 $HOME/grassdata/myproject — creates a new GRASS project with EPSG code 4326 (latitude-longitude, WGS84) in the specified GISDBASE 🌍
grass -c EPSG:5514:3 $HOME/grassdata/myproject — creates a new GRASS project with EPSG code 5514 (S-JTSK / Krovak East North - SJTSK) with datum transformation parameters used in Czech Republic in the specified GISDBASE 🇨🇿
grass -c XY $HOME/grassdata/gnomonic --exec g.proj -c proj4=’+proj=gnom +lat_0=90 +lon_0=-50’ — creates a new GRASS project from a PROJ definition string (here: gnomonic) in the specified GISDBASE 🗺️
grass -c myvector.shp $HOME/grassdata/myproject — creates a new GRASS project based on a georeferenced Shapefile 📐
grass -c myraster.tif $HOME/grassdata/myproject — creates a new GRASS project based on a georeferenced GeoTIFF file 🖼️

🍓 Batch jobs with the exec interface 🍓

Creating a new project based on a geodata file's projection (-c) and exit (-e) immediately:

grass -c elevation.tiff -e /path/to/grassdata/test1/

Linking external raster data to PERMANENT Mapset:

grass /path/to/grassdata/test1/PERMANENT/ --exec r.external input=basins.tiff output=basins
grass /path/to/grassdata/test1/PERMANENT/ --exec r.external input=elevation.tiff output=elevation

Get statistics for one raster map:

grass /path/to/grassdata/test1/PERMANENT/ --exec r.univar map=elevation

Compare the rasters visually:

grass /path/to/grassdata/test1/PERMANENT/ --exec g.gui.mapswipe first=elevation second=basins

🐍 Execution of shell and Python scripts instead of single commands 🐍

You can bundle a whole sequence of commands into a script and run the whole thing through the exec interface. Obsessed with the efficiency honestly 😌

Shell script example: the command to execute a shell script might be:

grass /path/to/grassdata/test1/PERMANENT/ --exec sh test.sh

A very simple bash script (test.sh) may look like this:

#!/bin/bash
g.region -p
g.list type=raster
r.info elevation

Python script example: the command to execute a Python script might be:

grass /path/to/grassdata/test1/PERMANENT/ --exec python test.py

A very simple Python script (test.py) may look like this:

#!/usr/bin/env python3
# import GRASS Python bindings (see also pygrass)
import grass.script as gs
gs.message(’Current GRASS GIS environment:’)
print(gs.gisenv())
gs.message(’Available raster maps:’)
for raster in gs.list_strings(type=’raster’):
    print(raster)
gs.message(’Available vector maps:’)
for vector in gs.list_strings(type=’vector’):
    print(vector)

🌈 Using temporary project 🌈

Creating a new temporary project based on a georeferenced file's coordinate reference system (CRS) and simultaneously starting computation in a shell script:

grass --tmp-project elevation.tiff --exec test.sh

The same, but using an EPSG code and a Python script:

grass --tmp-project EPSG:3358 --exec test.py

Finally, for special cases, we can create an XY project without any CRS:

grass --tmp-project XY --exec test.py

Heads up bestie 💀: the temporary project is automatically deleted after computation, so the script is expected to export, link or otherwise preserve the output data before ending. Do not forget this part, fr fr.

A single command can be also executed, e.g. to examine properties of the temporary project:

grass --tmp-project EPSG:3358 --exec g.proj -p

A temporary XY project with a single command is useful, e.g. to show help text of a module:

grass --tmp-project XY --exec r.neighbors --help

🦋 Using temporary mapset 🦋

A single command can be executed, e.g., to examine properties of a project (here using the NC SPM sample dataset):

grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec g.proj -p

Computation in a Python script can be executed in the same way:

grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec processing.py

Additional parameters are just passed to the script, so we can run the script with different sets of parameters (here 5, 8 and 3, 9) in different temporary mapsets which is good for parallel processing. go off, multitasking queen 👑

grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec processing.py 5 8
grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec processing.py 3 9

The same applies to Bash scripts (and other scripts supported on your platform):

grass --tmp-mapset /path/to/grassdata/nc_spm_08/ --exec processing.sh 5 8

Same warning as before, no cap 💀: the temporary mapset is automatically deleted after computation, so the script is expected to export, link or otherwise preserve the output data before ending.

🔧 Troubleshooting 🔧

Importantly, to avoid an "[Errno 8] Exec format error" there must be a shebang line at the top of the script (like #!/bin/sh, #!/bin/bash, or #!/usr/bin/env python3) indicating which interpreter to be used for the script. The script file must have its executable bit set. Periodt 🔥

💀 CAVEAT 💀

If you start GRASS using the wxGUI interface you must have a python command in your $PATH variable. That is, the command must be named python and not something like python3.6. Rarely some Python installations do not create a python command. In these cases you can override python by the GRASS_PYTHON environmental variable 🙈

Furthermore, if you have more than one version of Python installed, make sure that the version you want to use with GRASS is set by the GRASS_PYTHON environmental variable. Like, actually check it, bestie, don't just assume 😭

👀 SEE ALSO 👀

List of GRASS environment variables
GRASS GIS Web site
GRASS GIS User Wiki
GRASS GIS Bug Tracker
GRASS GIS 8 Programmer's Manual

💖 AUTHORS (of this page) 💖

Justin Hickey
Markus Neteler
Hamish Bowman
Martin Landa, Czech Technical University in Prague, Czech Republic

🌟 SOURCE CODE 🌟

Available at: GRASS startup program source code (history)

Accessed: Saturday Jan 17 05:40:17 2026

Main index | Topics index | Keywords index | Graphical index | Full index

and that's a wrap on grass(1) bestie!! 🎀 this gorgeous little page is from GRASS 8.4.2, and yeah, it lives in section 1 of the manual (you know, the grass(1) corner) 💅 go forth and launch things, you absolute icon 👑✨🦋

📦 where this page comes from

fedora 44: grass 8.4.2-4.fc44 · GPL-2.0-or-later
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-13: a language model's rewrite of the original, under its terms