Variadic Positional Arguments Create Parsing Ambiguity #3

New issue

Closed

opened 2026-03-17 23:08:29 -06:00 by jorge · 0 comments

jorge commented

2026-03-17 23:08:29 -06:00

Owner

The manifest schema allows defining arrays for positional arguments (e.g., array[path]). However, when an array is followed by another positional argument, the shell's parser will fundamentally struggle to determine where the variadic array ends and the next discrete argument begins.

For devs:
The copy command specifies two positional arguments in its manifest: source of type array[path], followed immediately by destination of type path.

If a user types copy file1.txt file2.txt file3.txt, how does the shell's AST parser logically determine whether file3.txt is the third item in the source array, or if it represents the singular destination argument? In legacy Unix, cp handles this ambiguity internally at runtime by checking the filesystem to see if the last argument is an existing directory. But in ZerOS, the shell is explicitly responsible for validating types ahead of time using the manifest. If the shell's parser greedily consumes paths into the array[path], it will exhaust the input and never populate the required destination argument.

For users:
Users expect predictable parsing. If the shell tries to guess the boundary of the array based on runtime filesystem state, it breaks the promise of predictable, offline syntax validation.

Test Examples

copy a.txt b.txt c.txt (Parsing ambiguity: is c.txt part of the source array or the destination?)
move folder1/ folder2/ archive/ (Same variadic ambiguity)

Since ZerOS explicitly rejects legacy Unix conventions for the sake of usability and correctness, we have the freedom to propose a clean, non-ambiguous solution. This might involve explicit syntax for array termination, or simply reconsidering how variadic commands are structured so they don't clash with subsequent positional arguments.

The manifest schema allows defining arrays for positional arguments (e.g., `array[path]`). However, when an array is followed by another positional argument, the shell's parser will fundamentally struggle to determine where the variadic array ends and the next discrete argument begins. **For devs:** The `copy` command specifies two positional arguments in its manifest: `source` of type `array[path]`, followed immediately by `destination` of type `path`. If a user types `copy file1.txt file2.txt file3.txt`, how does the shell's AST parser logically determine whether `file3.txt` is the third item in the `source` array, or if it represents the singular `destination` argument? In legacy Unix, `cp` handles this ambiguity internally at runtime by checking the filesystem to see if the last argument is an existing directory. But in ZerOS, the *shell* is explicitly responsible for validating types ahead of time using the manifest. If the shell's parser greedily consumes paths into the `array[path]`, it will exhaust the input and never populate the required `destination` argument. **For users:** Users expect predictable parsing. If the shell tries to guess the boundary of the array based on runtime filesystem state, it breaks the promise of predictable, offline syntax validation. ## Test Examples 1. `copy a.txt b.txt c.txt` (Parsing ambiguity: is `c.txt` part of the source array or the destination?) 2. `move folder1/ folder2/ archive/` (Same variadic ambiguity) --- Since ZerOS explicitly rejects legacy Unix conventions for the sake of usability and correctness, we have the freedom to propose a clean, non-ambiguous solution. This might involve explicit syntax for array termination, or simply reconsidering how variadic commands are structured so they don't clash with subsequent positional arguments.