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:10:04 +0100

On Mon, 26 Jun 2023 12:03:47 +0200
alex xmb ratchev <fxmbsw7@gmail.com> wrote:

> 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 ..

With all due respect, you are taking this thread way out into the weeds. The 
given solution doesn't work, and may have inadvertently revealed a bug in bash. 
I have absolutely nothing more to add that hasn't already been stated in my 
reply to Martin. Everything you need to know is in that post.

If you are interested in a solution that is clumsy - but that actually works - 
see https://bugs.gentoo.org/909148#c10.

-- 
Kerin Millar



reply via email to

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