Re: Enable compgen even when programmable completions are not available?

[Eli Schwartz]

On 6/30/23 3:25 PM, Robert Elz wrote:
>     Date:        Fri, 30 Jun 2023 18:35:34 +0100
>     From:        Kerin Millar <kfm@plushkava.net>
>     Message-ID:  <20230630183534.85da7986a24855126bfeab27@plushkava.net>
> 
>   | This can be trivially foiled.
> 
> You mean it doesn't give you all the variable names?   Why not?
> Does bash have a bug in this area that I am unaware of?
> 
> Or do you mean that it will sometimes (due to newlines in the values)
> be able to be persuaded to give you more than just the var names?
> 
> If the latter, why do you care?  The processing can check for each variable
> name produced whether it is set or not, and simply skip anything that looks
> like it is a variable name, but actually isn't set in the shell.  If it is
> important that each var name be included just once, just run the output
> through sort -u so any duplicates (which will only be caused by that kind
> of newline in the value stuff) get removed.
> 
> You're going to need a more sophisticated sed script (but not all that
> much more) to remove any "obviously not a variable name followed by ="
> lines, but you should be getting all of the variable names, which is the
> part that really matters, I am guessing.  That is, making sure none are
> missing is the challenging part, weeding out fakes is simple.


You have very helpfully described how one can design a rube goldberg
machine in bash to achieve some important goal.

But it rather misses the point that this thread wasn't asking for an
answer. The topic is "should compgen be enabled when readline / progcomp
is not".

The initial premise of the thread described your solution except better
-- declare -p, as mentioned in passing by my thread starter and in more
depth at the linked gentoo bug. And declare -p is better because it
returns the same results as set, except you get even more detail because
you can also grep for a leading `^declare`.

It was deemed undesirable, nonetheless. Yet another non-compgen hack is
described in the gentoo bug. It's still a hack.

Brainstorming additional workarounds doesn't accomplish anything above
and beyond the first workaround -- which is another way of saying,
brainstorming additional workarounds doesn't accomplish anything at all,
at the moment. Especially when they are incomplete and come with the
caveat that you'll need to do additional sed postprocessing, "check for
this and that", and various forms of English prose description about how
to accomplish a task...

.. that was already worked around with a hack and has a fully
implemented patch to do so on the gentoo ticket.

Suggesting ways that future versions of bash 5.3 and above can do this
*without* hacks, would accomplish something. It would accomplish the
ability to migrate away from hacks and over to proper APIs.

Maybe we should focus on that.


-- 
Eli Schwartz