bashcompinit: sourcing /etc/bash_completion

bashcompinit: sourcing /etc/bash_completion

[Daniel Hahler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've looked into loading /etc/bash_completion from the bash-completion
project, but it fails.

I am using the following function:

  # Load bash completion system
  # via http://zshwiki.org/home/convert/bash
  autoload -U bashcompinit
  bash_source() {
    alias shopt=':'
    alias _expand=_bash_expand
    alias _complete=_bash_comp
    emulate -L sh
    setopt kshglob noshglob braceexpand
  
    # setopt bashrematch dotglob hashall physical
    have() {
      unset have
      (( ${+commands[$1]} )) && have=yes
    }
  
    source "$@"
  }

It fails with the following line:

    local cword words=()

(/usr/share/bash-completion/bash_completion:305: parse error near `()')


Would it be possible to have a `emulate -L bash` to help with this?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iD8DBQFVeJlufAK/hT/mPgARAkL8AJ9wYN4ipiH1snLuPNVMW5yfCtxdqACgpMlZ
gckUAcsu74G9Y+Bk2MwobNw=
=xgZ6
-----END PGP SIGNATURE-----

Re: bashcompinit: sourcing /etc/bash_completion

[Bart Schaefer]

On Jun 10, 10:09pm, Daniel Hahler wrote:
}
} It fails with the following line:
} 
}     local cword words=()

Well, that's unfortunate.  In zsh "local" is not a special token, so the
arguments are parsed as normal shell words, so you cannot have an array
initialization as part of a "local" declaration.

There is no emulation mode or other workaround for this I can think of.

Re: bashcompinit: sourcing /etc/bash_completion

[Daniel Hahler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11.06.2015 04:14, Bart Schaefer wrote:
> On Jun 10, 10:09pm, Daniel Hahler wrote:

> } It fails with the following line:
> } 
> }     local cword words=()

> Well, that's unfortunate.  In zsh "local" is not a special token, so the
> arguments are parsed as normal shell words, so you cannot have an array
> initialization as part of a "local" declaration.

Could this be easily improved, without breaking backward-compatibility?

(I've found myself trying to use this pattern before.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iD8DBQFVecJHfAK/hT/mPgARAirWAKD8g3v6E4g8rNP8fof5u1rryrsnQwCdGzeg
qE5JNN2mMTuqSNigMcvYfsU=
=yzsZ
-----END PGP SIGNATURE-----

Re: bashcompinit: sourcing /etc/bash_completion

[Mikael Magnusson]

On Thu, Jun 11, 2015 at 7:15 PM, Daniel Hahler
<genml+zsh-workers@thequod.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11.06.2015 04:14, Bart Schaefer wrote:
>> On Jun 10, 10:09pm, Daniel Hahler wrote:
>
>> } It fails with the following line:
>> }
>> }     local cword words=()
>
>> Well, that's unfortunate.  In zsh "local" is not a special token, so the
>> arguments are parsed as normal shell words, so you cannot have an array
>> initialization as part of a "local" declaration.
>
> Could this be easily improved, without breaking backward-compatibility?
>
> (I've found myself trying to use this pattern before.)

It's probably much easier to ask the bash-completion maintainer to
initialize words on the next line.

-- 
Mikael Magnusson

Re: bashcompinit: sourcing /etc/bash_completion

[Bart Schaefer]

On Jun 11,  7:15pm, Daniel Hahler wrote:
}
} > } 
} > }     local cword words=()
} 
} > Well, that's unfortunate.  In zsh "local" is not a special token, so the
} > arguments are parsed as normal shell words, so you cannot have an array
} > initialization as part of a "local" declaration.
} 
} Could this be easily improved, without breaking backward-compatibility?

If it could be easily improved, it would have been changed years ago.

Re: bashcompinit: sourcing /etc/bash_completion

[Peter Stephenson]

On Thu, 11 Jun 2015 18:36:39 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jun 11,  7:15pm, Daniel Hahler wrote:
> }
> } > } 
> } > }     local cword words=()
> } 
> } > Well, that's unfortunate.  In zsh "local" is not a special token, so the
> } > arguments are parsed as normal shell words, so you cannot have an array
> } > initialization as part of a "local" declaration.
> } 
> } Could this be easily improved, without breaking backward-compatibility?
> 
> If it could be easily improved, it would have been changed years ago.

It could, in principle, be very difficultly and time-consumingly
improved.

We need in any case to keep the builtin interface to handle cases like

  local=local
  $local -i i

which are valid --- the case

  $local array=(one two)

is not valid as there's no keyword to signal special parsing.

The old interface could be supplemented with a reserved word interface
that institutes special parsing, a mix of assignment and command lines.
The reserved word could be disabled leaving the builtin (they're in
different hash tables), so it would be possible to work around any
breakages or even leave it off by default if that turned out to be
necessary.

The bin_typeset code would then need to accept both methods.  The way to
do this would probably be to post-process the builtin interface to
deliver the right combination of normal arguments and scalar
assignments.  This is fundamentally mechanical, so if done carefully it
wouldn't break anything.

There are lots of fiddly little details like ensuring consistent option
parsing with the new interface.

If anyone has an enforced month of idleness...

pws