[marisn]

check_gui can return None and there is no guard before call gui_process.wait().

As this state can be reached only on a broken setup, it makes sense to just warn user and exit.
Discovered by a wrong Docker usage – not common, but also possible to reach.

Co-authored with Claude Opus 5

Test: env -u DISPLAY grass /path/to/mapset < /dev/null

[echoix]

I don't see nothing wrong with this

[wenzeslaus]

Needless to say, this code would need much more work to make it smoother, but this is good for what it does. Definitively a case we want to handle (we already handle the no TTY/no interactive IO case for both GUI and --exec, so this fits right in).

Besides going back to the simple check, possibly also update lib/init/grass.md (around line 118?), which describes the text-mode as unconditional fallback. So perhaps add a condition ("...if [interactive] term... is available...") or describe when GRASS exits with an error.

[wenzeslaus]

Thanks! It took me some time to circle back to this.

Tests generated by AI

Tested with the PR's grass.py against an existing build (before = base, after = PR head):

• env -u DISPLAY grass MAPSET < /dev/null (the PR's own test):
  before: AttributeError: 'NoneType' object has no attribute 'wait';
  after: clean ERROR message, exit 1.
• env DISPLAY=:0 GRASS_PYTHON=/bin/false grass MAPSET < /dev/null
  (GUI unusable for a non-DISPLAY reason): before: same traceback;
  after: same ERROR message, exit 1.
• env -u DISPLAY grass --text MAPSET < /dev/null and
  env -u DISPLAY grass --text MAPSET <<<'g.gisenv get=MAPSET':
  text mode unchanged; piped stdin still runs the command.
• env -u DISPLAY GRASS_DEBUG=1 grass --text MAPSET < /dev/null:
  DEBUG: GRASS GUI should be <text> still present (briefly lost with the
  earlier call-site condition, restored by its removal).