bug-bash
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]