Changes in the PR

ArthPatel1502 · April 11, 2026, 4:37pm

Hi,

I updated this PR by adding a focused test for the current alias resolution behavior.

Changes:

Added a dedicated test file covering resolve_tool_name
Kept the change minimal and isolated so the current behavior is explicit and testable

This PR remains a small PoC to validate direction and gather feedback before moving toward a more scalable design.

Next directions I plan to explore:

Structured subcommands based on module families (e.g. grass raster slope.aspect)
Direct file-based workflows (GeoTIFF input/output)

Thanks,
Arth

github.com/OSGeo/grass

[WIP] CLI: Add basic command alias mapping for `grass run` (#7216)

main ← ArthPatel1502:cli-alias-poc

opened 11:26AM - 26 Mar 26 UTC

ArthPatel1502

+56 -89

Hi, This PR introduces a small proof-of-concept for command alias mapping in …the experimental CLI (`grass run`). Motivation: Currently, users need to know full GRASS module names such as `r.slope.aspect` or `g.list`. This can be unintuitive, especially for new users or quick workflows. This PR explores a simple alias layer that maps shorter commands to existing modules. Current implementation: - `slope` → `r.slope.aspect` - `list` → `g.list` Example usage: grass run slope elevation=elev_lid792_1m slope=out_slope aspect=out_aspect grass run list type=raster This is intentionally minimal and meant as a starting point for discussion. Before this PR, I built a local prototype which mapped simplified commands and verified an end-to-end workflow including region setup, raster analysis, and GeoTIFF output. Questions: 1. Does this approach align with the intended CLI design? 2. Should alias mapping be handled at this level or differently? 3. Is this a good direction to extend further for the Subcommand CLI project? Thanks, Arth

Here is the Link to the PR