Are you trying to use something like a “sub command” feature? > On Jul 3, 2025, at 10:44 PM, toastal <toas...@posteo.net> wrote: > > I have been trying to hack on command-line.parser to add the ability to > call it with commands. I am too far out of my depth in both > understanding how to debug the situation, but also it’s difficult to > work with since all of the vocabs are used for the listener already it > seems? > > Ideally the API goal would be like OCaml’s Cmdliner Cmd > <https://ocaml.github.io/odoc/cmdliner/cmdliner/Cmdliner/Cmd/index.html> > which is for CLIs that aren’t prompt-based, command-driven such as with > Git, Pijul, & so on. Currently there is no ordering of arguments as you > are either an option or positional, but command styles have recursive > units that can nest other options / commands which could have their own > help texts — where once a cmd type is found on in the set of commands > from the argument sequence, the rest of the arg sequence should run > (parse-arguments) on a new options for the command. > > Some tools like Git & Pijul can dispatch out from a primary program to > subprograms based on the name, but if start times are slow or executable > sizes are big, this isn’t as preferred by users, which is probably the > case for Factor — especially if using the interpreter as factor -run=foo > bar baz --qux "quux" (would this then call factor -run=foo.bar baz --qux > "quux" which then calls factor -run=foo.bar.baz --qux "quux"?). > > What I intially tried was using -- to get the rest of the arguments, but > aesthetically this isn’t ideal, but more importantly you would lose the > ability to get help text for the subcommands. --help currently can > *only* show the top-level help & it can’t be surpressed while all much > of the API is hidden behind <PRIVATE> to try to assemble the pieces > yourself. -- could also be assed to a prompt-based setup as input, like > fdisk. > > Is this a feature request, a call for help? I’m not entirely sure… 😅 > but it does seem the like a missing feature that could be tackled for > UX as prompt-style CLIs have gone out of fashion & folks — my Fish > session included — want shell completions without wrangling the state of > a prompt (I have failed to set up a disk with fdisk on more than one > occassion). > > … Or should I just be doing my own argument parsing & avoid > command-line.parser (recently moved from /extra to /basis) if it can’t > fit my needs? > > --- > > I had written a single test as a goal: > > CONSTANT: COMMANDS H{ > { "add" H{ > T{ option > { name "a" } > { #args 1 } > { type integer } > } > } } > { "subtract" H{ > T{ option > { name "s" } > { #args 1 } > { type integer } > } > } } > } > > { > { > H{ { "cmd" { "add" H{ { "a" 1 } } } } } > H{ { "cmd" { "subtract" H{ { "s" 1 } } } } > } > } [ > { > T{ option { name "cmd" } { cmd COMMANDS } } > } { > { "add" "1" } > { "subtract" "2" } > } [ (parse-options) ] with map > ] unit-test > > As well the type I would assume… > > TUPLE: option name type help variable cmd default convert > validate const required? meta #args ; > > TUPLE: command name help options ; > > But got stuck trying to figure out where / how get this in > parse-arguments. > > > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk
_______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
