Re: New 'pg' consolidated metacommand patch

On Wed, 27 May 2020 at 16:49, Isaac Morland <isaac(dot)morland(at)gmail(dot)com> wrote:

> On Wed, 27 May 2020 at 16:00, Peter Eisentraut <
> peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>
>
>> Also consider some practical concerns with the command structure you
>> describe: Tab completion of commands wouldn't work anymore, unless you
>> supply custom tab completion setups. The direct association between a
>> command and its man page would be broken. Shell scripting becomes more
>> challenging: Instead of writing common things like "if which
>> pg_waldump; then" you'd need some custom code, to be determined. These
>> are all solvable, but just a sum of slight annoyances, for no real
>> benefit.
>>
>
> I don’t think the man page concern is justified. We could have a “help”
> subcommand, just like git; “git help add” is (to a casual observer;
> probably not precisely) the same as “man git-add”.
>

There's some very small gulf in between the concerns...

- On the one hand, git (and systems with similar "keyword" subsystems) have
arrived at reasonable solutions to cope with various of the systematic
issues, so that these shouldn't be considered to be gigantic insurmountable
barriers.

Indeed, some of these tools present systematic solutions to additional
matters. I was very pleased when I found that some of the Kubernetes tools
I was working with included subcommands to configure my shell to know how
to do command completion. Seems like a fine thing to me to have that
become systematically *easier*, and I think that would be a good new
subcommand... "pg completion bash" and "pg completion zsh" would be mighty
fine things.

- On the other hand, mapping old commands that are names of programs onto
"pg subcommands" is some additional effort, and we haven't yet started
bikeshedding on the favoured names :-)

I have lately noticed some interesting looking apps wandering about that
briefly attracted my attention, but, which, due to being painfully
different from the existing commands and tools that I have already learned,
and have "muscle memory" for, am loath to leave. I'll throw out 4
examples, 3 of them personal:
a) nnn is a terminal-based file manager. It has some nifty features
surrounding the concept that you can set up custom file filters to look for
sorts of files that you find interesting, and then offers customizable UI
for running favorite actions against them. I'm 25 years into using Emacs
Dired mode; as neat as nnn seems, it's not enough of an improvement to be
worth the pain in the neck of relearning stuff.
b) 3mux is a redo of tmux (which was a redo of GNU Screen), and has key
mappings that make it way easier for a new user to learn. I'm 20-ish years
into Screen/Tmux; I wasn't looking for it to be easier to learn, because I
did that quite a while ago.
c) Kakoune is a vi-like editor which rotates from vi's "verb/object"
approach to commands to a "object/verb" approach, for apparent more
efficiency. I think I already mentioned that my "muscle memory" is biased
by Emacs features... I'm not adding a "rotated-vi-like" thing into my mix
:-(
d) systemd is a Controversial System; the folk that seem particularly irate
about it seem to be "Old Bearded Sysadmins" that hate the idea of redoing
their understandings of how Unix systems initialize. Personally, my
feelings are ambivalent; I'm using it where I find some use, and have not
been displeased with my results. And since modern systems now have USB and
network devices added and dropped on a whim, there's a critical need for
something newer with more dynamic responses than old SysV Init. But I
certainly "get" that some aren't so happy with it, and I'm not thrilled at
the ongoing scope creep that never seems to end.

There is merit to having a new, harmonious set of "pg commands." But it's
eminently easy to get into trouble (and get people mad) by changing things
that have been working fine for many years. Half the battle (against the
"getting people mad" part) is making sure that it's clear that people were
listened to. Listening to the community is one of the important things to
do :-).
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"