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

[alex xmb ratchev]

On Mon, Jun 26, 2023, 12:01 Kerin Millar <kfm@plushkava.net> wrote:

> On Mon, 26 Jun 2023 11:51:58 +0200
> alex xmb ratchev <fxmbsw7@gmail.com> wrote:
>
> > On Mon, Jun 26, 2023, 11:33 Kerin Millar <kfm@plushkava.net> wrote:
> >
> > > On Mon, 26 Jun 2023 17:09:47 +1000
> > > Martin D Kealey <martin@kurahaupo.gen.nz> wrote:
> > >
> > > > Hi Eli
> > > >
> > > > How about using the shell itself to parse the output of "typeset" (an
> > > alias
> > > > for "declare"), but redefining "declare" to do something different.
> This
> > > is
> > > > a bit verbose but it works cleanly:
> > > >
> > > > ```
> > > > (
> > > >   function declare {
> > > >     while [[ $1 = -* ]] ; do shift ; done
> > > >     printf %s\\n "${@%%=*}"
> > > >   }
> > > >   eval "$( typeset -p )"
> > > > )
> > > > ```
> > >
> > > Unfortunately, this is defective.
> > >
> > > $ bash -c 'declare() { shift; printf %s\\n "${1%%=*}"; }; eval
> "declare -a
> > > BASH_ARGC=()"'; echo $?
> > > 1
> > >
> > > In fact, bash cannot successfully execute the output of declare -p in
> full.
> > >
> > > $ declare -p | grep BASH_ARGC
> > > declare -a BASH_ARGC=([0]="0")
> > > $ declare -a BASH_ARGC=([0]="0"); echo $? # echo is never reached
> > >
> > > While it is understandable that an attempt to assign to certain shell
> > > variables would be treated as an error, the combination of not
> printing a
> > > diganostic message and inducing a non-interactive shell to exit is
> rather
> > > confusing. Further, declare is granted special treatment, even after
> having
> > > been defined as a function (which might be a bug).
> > >
> > > $ bash -c 'declare() { shift; printf %s\\n "${1%%=*}"; }; eval
> "declare -a
> > > BASH_ARGC=()"'; echo $?
> > > 1
> > >
> > > $ bash -c 'declare() { shift; printf %s\\n "${1%%=*}"; }; eval
> "declare -a
> > > BASH_ARG=()"'; echo $?
> > > BASH_ARG
> > > 0
> > >
> > > $ bash -c 'f() { shift; printf %s\\n "${1%%=*}"; }; eval "f -a
> > > BASH_ARGC=()"'; echo $?
> > > bash: eval: line 1: syntax error near unexpected token `('
> > > bash: eval: line 1: `f -a BASH_ARGC=()'
> > > 2
> > >
> > > $ bash -c 'f() { shift; printf %s\\n "${1%%=*}"; }; eval "f -a
> > > BASH_ARG=()"'; echo $?
> > > bash: eval: line 1: syntax error near unexpected token `('
> > > bash: eval: line 1: `f -a BASH_ARG=()'
> > > 2
> > >
> >
> > you forgot
> > see u cmd foo bar=()
> > u still need as always escape ( and )
>
> I didn't forget anything. Martin's proposal was intended to work by
> evaluating the unmodified output of typeset -p. That ( and ) normally need
> to be escaped simply demonstrates further that it is untenable as a
> solution.


1. making bash eat func foo=() never worked without escaping ( ) .. same
err msg
2. cab u paste me the specific msg / url to that declare -p .. im parser
pro ..

> --
> Kerin Millar
>