grass(1grass)

🦋 GRASS startup program 💅

okay so bestie, pull up a chair, because this is grass(1grass) — the GRASS User's Manual entry that literally launches GRASS itself. this is the vibe check before anything else in GRASS can even breathe. 🫶

---

✨ 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 — spits out a lil brief usage message and then dips. that's it, that's the whole job. 💖
• -v, --version — tells you which version of GRASS you're running, then exits. iconic behavior.
• -c XY — makes a brand new GRASS project (location) in the GISDBASE you specified, with no coordinate reference system at all.
• -c geofile — makes a new GRASS project in your specified GISDBASE, and pulls its coordinate reference system from a georeferenced file. slay, it reads.
• -c EPSG:code — new GRASS project in the specified GISDBASE, CRS defined by an EPSG code. periodt.
• -c EPSG:code:datum_trans — new GRASS project in the specified GISDBASE, CRS defined by an EPSG code plus datum transform parameters. highkey the most specific option here.
• -e — exit after the project or mapset gets created. only works with the -c flag, so don't get cute with it. 🌈
• -f — forces removal of .gislock if it exists. ⚠️ use with care, bestie!! only with the --text flag.
• --text — says "yeah we're using the Text-based User Interface" and skips the welcome screen. no fluff.
• --gtext — also Text-based User Interface, but this time you do want the welcome screen. it's giving nostalgic.
• --gui — says "we're doing 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 — runs a GRASS module or script. whatever executable you hand over gets run inside a GRASS non-interactive session. 🔥
• --tmp-project — runs using a temporary project that gets created based on the given coordinate reference system and then deleted at the end of the execution. use it with the --exec flag. also bestie, the active mapset will be the PERMANENT mapset. 💀
• --tmp-mapset — runs using a temporary mapset that gets created inside the specified project and deleted at the end of the execution. use it with the --exec flag.

🎀 Parameters:

• GISDBASE — the initial database directory, and it should be a fully qualified path, like /usr/local/share/grassdata. yes, the whole thing, not a lazy relative one. 💅
• PROJECT — the initial project directory, which is a subdirectory of GISDBASE. fun fact: project was previously called location. glow-up era. ✨
• MAPSET — the initial mapset directory, which is a subdirectory of PROJECT.

Note, bestie: these parameters must be specified in one of the following ways:

• MAPSET
• PROJECT/MAPSET
• GISDBASE/PROJECT/MAPSET

---

🌟 DESCRIPTION 🌟

so this command is the one that launches GRASS. it parses all your command line arguments and then gets GRASS all initialized for you. and here's the thing — because GRASS modules literally require a specific environment, this program has to be called before any other GRASS module can run. no skipping the line, babes.

the command line arguments are optional, and they're here to let you indicate the user interface you want plus the mapset you wanna work on. casual.

the startup program remembers both the user interface you wanted and the mapset. so next time you run GRASS and just type grass with zero options, it'll start right up with your previous user interface and mapset settings. it's giving muscle memory. 🦋

if you specify a graphical user interface (--gui), the grass program will try to verify that the system you specified actually exists and that you can access it successfully. and if any of those checks fail? it just automatically switches back to text user interface mode. self-care, honestly. 💜

🧚 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 get passed along to it. a script has to be specified by full or relative path, and on unix-likes systems the script file must have its executable bit set. (also you can call the interpreter — like python — and hand the script over as a parameter, that's valid too.) when it's finished, GRASS automatically exits using the return code given by the subprocess. and even though the execution itself is non-interactive (no GUI, no shell), the subprocess itself can totally be interactive if that's what the user requires. flexible queen. 👑

⭐ Config flag

the flag --config option prints GRASS configuration and version parameters, with these 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 project provides several free sample geospatial datasets as ready-to-use projects, and you can download them 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 all the examples throughout the user manual pages are based upon it. it's literally the blueprint. 🎀

---

🌈 ENVIRONMENT VARIABLES 🌈

a number of environment variables are available at GRASS startup to help with automation and customization. most users will not need to bother with these — and that's fine, no pressure, 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 just 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 that you will 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:

1. Command line argument
2. Environment variable GRASS_GUI
3. Value set in $HOME/.grass8/rc (GUI)
4. 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. yes, you get to pick your own python. icon behavior.

say 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 the 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. that's the whole thing — you pick the browser, help pages open there. 🙈

✨ EXAMPLES ✨

okay bestie here's the actual tea, some real ways you'd kick off GRASS 👇

• grass — Starts up GRASS with the default user interface. It's gonna ask you to pick your project and mapset, so get ready to point at stuff.
• grass --gui — Same squad, but with the graphical user interface. You'll still get asked for your project + mapset.
• grass --text — Starts GRASS with the text-based user interface. Bestie, you must set project and mapset through environment variables (examples further down, keep reading) — otherwise it'll just quietly swipe them from your last GRASS session.
• grass --gtext — Text-based UI again, but this time it asks you to pick the project and mapset. So polite of it.
• grass $HOME/grassdata/spearfish70/user1 — Default user interface, and it launches straight into the mapset you named. The selection menu? Skipped. Not even invited. 💅
• grass --gui - — Graphical UI, and it tries to pull the project + mapset from your environment variables.
• grass -c EPSG:4326 $HOME/grassdata/myproject — Cooks up a fresh GRASS project using EPSG code 4326 (that's latitude-longitude, WGS84) inside the GISDBASE you specified.
• grass -c EPSG:5514:3 $HOME/grassdata/myproject — New GRASS project with EPSG code 5514 (S-JTSK / Krovak East North - SJTSK), plus the datum transformation parameters used in the Czech Republic, in your given GISDBASE.
• grass -c XY $HOME/grassdata/gnomonic --exec g.proj -c proj4=’+proj=gnom +lat_0=90 +lon_0=-50’ — New GRASS project built from a PROJ definition string (here it's gnomonic) in the GISDBASE you picked.

grass -c XY $HOME/grassdata/gnomonic --exec g.proj -c proj4=’+proj=gnom +lat_0=90 +lon_0=-50’

• grass -c myvector.shp $HOME/grassdata/myproject — New GRASS project based on a georeferenced Shapefile 🦋
• grass -c myraster.tif $HOME/grassdata/myproject — New GRASS project based on a georeferenced GeoTIFF file 🎀

🔥 Batch jobs with the exec interface

Creating a new project from a geodata file's projection (-c) and then dipping out immediately (-e):

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

Linking external raster data to the 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

Getting stats for one raster map:

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

Comparing the rasters visually (so satisfying honestly):

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

🧚 Execution of shell and Python scripts instead of single commands

A whole sequence of commands can be bundled into a script and run through the exec interface. Iconic, lowkey efficient.

Shell script example: the command to run a shell script might look like:

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

And 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

And 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 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

Making a brand new temporary project based on a georeferenced file's coordinate reference system (CRS) and starting computation in a shell script at the same time:

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

Same energy, but with an EPSG code and a Python script:

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

And finally, for the special cases, we can create an XY project with no CRS whatsoever:

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

Heads up bestie: the temporary project gets automatically deleted after computation. So your script is expected to export, link, or otherwise preserve the output data before it ends. No save = no vibes. 😭

A single command can also be executed, like if you wanna peek at the properties of the temporary project:

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

And a temporary XY project with a single command is useful when you just wanna, say, show a module's help text:

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

Same trick works for computation inside a Python script:

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

Extra parameters just get passed along to the script, so you can run it with different sets of parameters (here 5, 8 and 3, 9) in different temporary mapsets — which is great for parallel processing, no cap:

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

Same deal applies to Bash scripts (and any other scripts your platform supports):

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

And again, the temporary mapset is automatically deleted after computation, so the script is expected to export, link, or otherwise preserve the output data before ending. Protect your work, queen. 👑

🩹 Troubleshooting

Super importantly, to dodge an "[Errno 8] Exec format error" there has to be a shebang line at the top of the script (like #!/bin/sh, #!/bin/bash, or #!/usr/bin/env python3) telling everyone which interpreter to use for the script. Also — the script file must have its executable bit set. That's the whole assignment. ⭐

---

💀 CAVEAT 💀

If you start GRASS using the wxGUI interface you must have a python command in your $PATH variable. Like, the command has to literally be named python and not something like python3.6. Rarely, some Python installations just don't create a python command at all (rude of them). In those cases you can override python using the GRASS_PYTHON environmental variable. 🫶

Plus, if you've got more than one version of Python installed, please make sure the version you want to use with GRASS is the one set by that GRASS_PYTHON environmental variable. Vibe check your Python, bestie.

---

👀 SEE ALSO 👀

• List of GRASS environment variables
• GRASS Web site
• GRASS User Wiki
• GRASS Bug Tracker
• GRASS 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: Tuesday Sep 08 11:53:42 2026

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

---

and that's the whole thing, bestie 🎀 this page was cooked up by the GRASS Development Team (© 2003-2026), it's part of the GRASS 8.5.0 Reference Manual, and our girl grass(1grass) was last accessed on Tuesday Sep 08 11:53:42 2026. now go start that project, you absolute main character 👑✨