Global Flag Namespace Collision & Syntax Strictness #5

New issue

Closed

opened 2026-03-17 23:12:27 -06:00 by jorge · 0 comments

jorge commented

2026-03-17 23:12:27 -06:00

Owner

ZerOS establishes --raw as a "global flag handled by the shell, not by individual programs". Furthermore, the current documentation uses GNU-style options (e.g., -l 10) without strictly defining how the parser distinguishes an option's value from the next positional argument.

For devs:
Collision: Reserving standard flag syntax like --raw at the OS level pollutes the namespace for user-space programs. If a developer writes a program that naturally needs a --raw flag (e.g., a low-level disk utility reading raw sectors or a camera utility fetching a RAW image), the shell will intercept the flag, and the application will never see it.
Syntax Strictness: The current examples show spaces separating flags and values (e.g., -l 10:20). If the shell parser relies on space-separated values, distinguishing between a flag's value and the next positional argument becomes incredibly complex, especially when mixed with the variadic arrays mentioned in Issue #3.

For users:
Users need a consistent mental model. If --raw does something completely different than --recursive (one modifies the shell's renderer, the other is passed to the program), but they look identical, it creates friction. Furthermore, ambiguous parsing of spaces means users might accidentally pass a value to a flag when they meant it to be a positional argument.

Test Examples

disk-util read /dev/sda --raw (Does the shell strip --raw or pass it to the app?)
open -l 10:20 server.log vs open -l=10:20 server.log (Strict assignment vs. space-separated ambiguity)
search --limit 10 . (Is 10 the limit and . the path, or is 10 . the path and we are missing the limit?)

OS-level shell directives might need a unique sigil to avoid collisions, such as ++raw. Alternatively, using a shell builtin wrapper or a prefix command (e.g., raw list /home/user) would completely eliminate flag collision. For the parser ambiguity, enforcing = for named flag assignment (e.g., --limit=10) would instantly resolve the parsing complexity, but may look / feel kludgy for users.

ZerOS establishes `--raw` as a "global flag handled by the shell, not by individual programs". Furthermore, the current documentation uses GNU-style options (e.g., `-l 10`) without strictly defining how the parser distinguishes an option's value from the next positional argument. **For devs:** *Collision:* Reserving standard flag syntax like `--raw` at the OS level pollutes the namespace for user-space programs. If a developer writes a program that naturally needs a `--raw` flag (e.g., a low-level disk utility reading raw sectors or a camera utility fetching a RAW image), the shell will intercept the flag, and the application will never see it. *Syntax Strictness:* The current examples show spaces separating flags and values (e.g., `-l 10:20`). If the shell parser relies on space-separated values, distinguishing between a flag's value and the next positional argument becomes incredibly complex, especially when mixed with the variadic arrays mentioned in Issue #3. **For users:** Users need a consistent mental model. If `--raw` does something completely different than `--recursive` (one modifies the shell's renderer, the other is passed to the program), but they look identical, it creates friction. Furthermore, ambiguous parsing of spaces means users might accidentally pass a value to a flag when they meant it to be a positional argument. ## Test Examples 1. `disk-util read /dev/sda --raw` (Does the shell strip `--raw` or pass it to the app?) 2. `open -l 10:20 server.log` vs `open -l=10:20 server.log` (Strict assignment vs. space-separated ambiguity) 3. `search --limit 10 .` (Is `10` the limit and `.` the path, or is `10 .` the path and we are missing the limit?) --- OS-level shell directives might need a unique sigil to avoid collisions, such as `++raw`. Alternatively, using a shell builtin wrapper or a prefix command (e.g., `raw list /home/user`) would completely eliminate flag collision. For the parser ambiguity, enforcing `=` for named flag assignment (e.g., `--limit=10`) would instantly resolve the parsing complexity, but may look / feel kludgy for users.