This needs to be in a directory in your FPATH.

At the core, it uses _arguments to dissect the command line. This both suggests that "-t" exists, is called "tags" and later on sets a state variable to "tags" or "limits" if we're completing these arguments.

    #compdef corp-ansible-wrapper
    _arguments  '-t[tags]:tags:->tags' '-l[limit]:limit:->limits' '-D[diffmode]' '-C[checkmode]' '::optional arg:_files'
    detect_playbook
    case "$state" in
        tags)
        ...
        ;;
        limits)
        ...
        ;;

All of that is shoved into `_values`, and then the usual zsh completion works, so with something like `./wrapper mariadb.yml -l prj4<TAB>`, zsh tries to filter the values based on the word, so this finds stuff like `prj4`, `prj49`, `dc2_prj45`, and so on, but not `prj5`.

    detect_playbook

    # should be an array.
    case $PLAYBOOK in
        postgres.yml)
            FILTER="pg_\|postgres_\|pgbackrest_"
        ;;
        mariadb.yml)
            FILTER="db_\|mariadb_"
        ;;
        # quite a few more
        *)
            FILTER=""
        ;;
    esac

    # probably overly complex
    ANSIBLE_GROUPS_RAW=$( cat $ANSIBLE_INVENTORY/groups | grep -E "$FILTER" | sort | uniq | tr '\n' ',')
    IFS=',' read -r -A ANSIBLE_GROUPS <<< "$ANSIBLE_GROUPS_RAW"
    _values -s: 'groups' "${ANSIBLE_GROUPS[@]}"

- You can run `ansible-playbook "$WORD" --list-tags` to get all tags a playbook references in the current inventory.

- One can give `_values` descriptions. If `_values` sees 'foo[bar]' as an option, it will show the user something like: "foo: bar" and only auto-completes to foo.

- This means, we can give standard or well-established tags short descriptions in a directory or an array or whatever, and instead of offering just "postgres_client_tls_certs" as possible auto-completions for `-t`, we can give the user a prompt like "postgres_client_tls_certs: Ensures the postgres cluster has valid and up-to-date TLS certificates for mutual TLS with applications".

It took a bit of time to understand all of this. But now documenting a tag in a place that people actually look at is very easy and straightforward.

If you don’t like the Verb-Noun nonsense I’d encourage you to look at the default aliases as they make everything a lot less verbose. For example Where-Object is just “where” or getchild-item is default aliased to ls and gci.

Id encourage you to look at NuShell as well since it is mostly the same philosophy as PowerShell.

Bad for your reasons (slow etc), good for siblings (objects).

Also, understandable flags that auto-shorten. Eg:

Descriptive-Command-Name -DescriptiveOption 32

Can be typed as:

d-c-n <tab> -des 32

---

Interactively it's still far behind zsh sadly due to startup time but when I'm doing something thoughtful I prefer it. If you're not entering directories and doing small stuff, use pwsh. And for all shell scripting

If you are bothered by the verbose `Verb-Noun` structure of commands, those are mostly used in scripts (and you never type them fully, you use tab-completion of course). On the commandline you use aliases for many of them.

For example listing files and directories created in the last 10 days:

  ls | ? CreationTime -ge (Get-Date).AddDays(-10) | ft name, size

  Get-ChildItem | Where-Object CreationTime -ge (Get-Date).AddDays(-10) | Format-Table Name, Size

(Well that and all my machines come from the same NixOS configs.)

(Seriously, what am I missing here? Is `apt-brew pacman install fish` really that hard to type? If cross-platform portability is actually a concern, shouldn't you be using Python anyway?)

David Korn thanked the pdksh authors and maintainers for making it available in the years when true ksh was closed (ksh88) or open but licensed with awkward terms (ksh93 for several years).

David Korn interview (I asked one of the questions):

https://m.slashdot.org/story/16351

"First of all pdksh is a ksh88 clone; and I might add a better clone than the MKS Korn Shell...

"I don't know the pdksh development team but I would like to thank them for the service they have done in making a version of ksh available while ksh was proprietary. I have noticed remarkable improvements in pdksh in its ability to mimic ksh88 functionality. I don't know what plans the pdksh development team has now that ksh93 is available in open source form, but I certainly would help them try to maintain compatibility if they do continue pdksh distribution. Otherwise, I would hope that they would pick up the ksh93 source and help support and enhance it."