[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enable compgen even when programmable completions are not available?
From: |
Kerin Millar |
Subject: |
Re: Enable compgen even when programmable completions are not available? |
Date: |
Mon, 26 Jun 2023 11:01:39 +0100 |
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.
--
Kerin Millar
- Enable compgen even when programmable completions are not available?, Eli Schwartz, 2023/06/25
- Re: Enable compgen even when programmable completions are not available?,
Kerin Millar <=
- Re: Enable compgen even when programmable completions are not available?, alex xmb ratchev, 2023/06/26
- Re: Enable compgen even when programmable completions are not available?, Kerin Millar, 2023/06/26
- Re: Enable compgen even when programmable completions are not available?, alex xmb ratchev, 2023/06/26
- Re: Enable compgen even when programmable completions are not available?, Martin D Kealey, 2023/06/26
- Re: Enable compgen even when programmable completions are not available?, alex xmb ratchev, 2023/06/26
- Re: Enable compgen even when programmable completions are not available?, Chet Ramey, 2023/06/29
- Re: Enable compgen even when programmable completions are not available?, Eli Schwartz, 2023/06/26
Re: Enable compgen even when programmable completions are not available?, Robert Elz, 2023/06/26
Re: Enable compgen even when programmable completions are not available?, alex xmb ratchev, 2023/06/26