[WIP] CLI: Add basic command alias mapping for grass run

[ArthPatel1502]

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

[wenzeslaus]

I don't know if this is a good direction, but you can explore a slight modification of your approach which I considered previously:

grass run r.slope.aspect -> grass raster slope.aspect
grass run g.list -> grass general list

This can be computed, as opposed to a hardcoded mapping (leaving the r.slope.aspect vs slope vs aspect issue aside). There might be a in-the-middle solution as well.

If you are asking what might a better area to focus on, evaluate the above against reading directly from a GeoTIFF and other files in the command line:

grass run r.slope.aspect elevation=/tmp/elevation.tif slope=/tmp/out_slope.tif aspect=/tmp/out_aspect.tif

Exploring both should give you a better picture. For PR, include tests of the new functionality even for experiments to clearly demonstrate the intended behavior.

[ArthPatel1502]

Hi, thank you — this is very helpful.

I understand the concern about hardcoded alias mapping becoming arbitrary. The structured form such as grass raster slope.aspect and grass general list makes sense because it is closer to the existing module naming scheme and could potentially be derived programmatically rather than maintained as a manual mapping table.

I’ll explore both directions:

1. a structured subcommand form based on module families (raster, general, etc.), and
2. direct file-based workflows such as running modules on GeoTIFF inputs and outputs in one command.

I’ll compare them from the perspective of usability, implementation complexity, and how well they align with the goals of the Subcommand CLI project.

I’ll also make sure the next PR includes tests to demonstrate the intended behavior clearly.

Thanks again — this gives me a much better direction for the next iteration.

[luisponti]

It could probably be computed also when used as suggested by @ArthPatel1502

For example, for g.list,

• if there is only one *.list command, then use it;
• else, ask the user how to resolve the conflict.

Apologies for the noise.

[ArthPatel1502]

Thanks for the detailed feedback — this clarifies the direction significantly.

I see the limitation of hardcoded alias mapping and agree that a structured approach like grass raster slope.aspect is more scalable and aligns better with the existing module naming scheme. I’ll explore how this can be derived programmatically rather than relying on manual mappings.

In parallel, I will also experiment with direct file-based workflows (e.g., running modules directly on GeoTIFF inputs/outputs) to evaluate how well they improve usability in practice.

For the next iteration, I’ll focus on comparing these approaches in terms of usability and implementation, and include tests to clearly demonstrate the behavior.

[wenzeslaus]

@luisponti Feel free to make suggestions here. The subcommand CLI is in design stage, although thinks can be committed and dome are already available.