Apple's A/UX had "commando" - but I think these were manually-defined instead of dynamically generated (whereas PowerShell cmds all export their own parameter definitions so PowerShell can dynamically generate UIs): http://toastytech.com/guis/aux3.html
I'd imagine power shell has some way to pull the available parameters out of cmdlets (they probably all inherit from some cmdlet class or something.) On bash you have to get this from somewhere else.
Maybe it's because I've discovered it recently enough and I'm quite amazed at the possibilities, but I really think this is a great project for (using) Nix (even NixOS itself in desktop mode).
Here's my rough intuition.
1. Nix brings immutable packages (static, read-only), versioned as you wish to target various dependencies. (the `/nix` folder)
2. This means the goal is to create once and for all a GUI for each command, a static view.
3. Meanwhile, the Nix ecosystem is heavily curated yet quite expansive (some 60k+ pkgs IIRC), and a decentralized part is evolving towards an AUR-like mindset (the NUR, Nix User Repository). These are the people you want to polish a good-enough-but-not-perfect GUI automation tool. Remember, it's a one-off, since each version is static, forever in Nix (thus presumably shared by all users).
4. An intuitively natural design to me seems to split the auto-GUI tool process in 3 steps:
- Parse and encode some `man` or `--help` output (probably needs a well-defined sub-spec to make perfect parsing predictable by devs targeting Nix). Generate some .gui_spec file.
- Read a .gui_conf file that overrides defaults (empty = defaults). This is where maintainers, designers and curators can rectify the auto-gui tool once and for all on a need-to basis. End-users may override this vendor-provided config in their home environment (notably to auto-apply DE theming parameters, etc).
- Generate final GUI executable for target env (should work in X/Wayland but also as a barebones terminal app with optional mouse support).
Basically, heavy lifting is done upstream by following a standardized auto-GUI specification (some DSL to call it bluntly, that happens to look like `man` + descriptors), and there is one layer of "good steward" curation before the recipe gets properly rendered by end-users' DE (+ optional local customization).
The point is to add as little extra work as possible every step of the way (if possible, none) by leveraging existing structures (man, nix, term/X/DE conventions, …) to apply "great defaults" automagically enough.
I'm pretty sure this is the next-level tldr and a killer feature at the tip of a shortcut for <insert cool shell>.
If I'm not mistaken, that's basically how shell completions work in Nix. At least for fish. Package derivations can include completion scripts at a special location. Users can override the provided completions either in their shell init file or using an overlay over the package. And in lieu of a manually written completion, at least fish can parse man pages and turn that into completions.
DaiPlusPlus|3 years ago
usrn|3 years ago
behnamoh|3 years ago
wheybags|3 years ago
jhgb|3 years ago
K0SM0S|3 years ago
Here's my rough intuition.
1. Nix brings immutable packages (static, read-only), versioned as you wish to target various dependencies. (the `/nix` folder)
2. This means the goal is to create once and for all a GUI for each command, a static view.
3. Meanwhile, the Nix ecosystem is heavily curated yet quite expansive (some 60k+ pkgs IIRC), and a decentralized part is evolving towards an AUR-like mindset (the NUR, Nix User Repository). These are the people you want to polish a good-enough-but-not-perfect GUI automation tool. Remember, it's a one-off, since each version is static, forever in Nix (thus presumably shared by all users).
4. An intuitively natural design to me seems to split the auto-GUI tool process in 3 steps:
- Parse and encode some `man` or `--help` output (probably needs a well-defined sub-spec to make perfect parsing predictable by devs targeting Nix). Generate some .gui_spec file.
- Read a .gui_conf file that overrides defaults (empty = defaults). This is where maintainers, designers and curators can rectify the auto-gui tool once and for all on a need-to basis. End-users may override this vendor-provided config in their home environment (notably to auto-apply DE theming parameters, etc).
- Generate final GUI executable for target env (should work in X/Wayland but also as a barebones terminal app with optional mouse support).
Basically, heavy lifting is done upstream by following a standardized auto-GUI specification (some DSL to call it bluntly, that happens to look like `man` + descriptors), and there is one layer of "good steward" curation before the recipe gets properly rendered by end-users' DE (+ optional local customization).
The point is to add as little extra work as possible every step of the way (if possible, none) by leveraging existing structures (man, nix, term/X/DE conventions, …) to apply "great defaults" automagically enough.
I'm pretty sure this is the next-level tldr and a killer feature at the tip of a shortcut for <insert cool shell>.
t0astbread|3 years ago