bug: _store_cache and ksh arrays

bug: _store_cache and ksh arrays

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Hello,

I think I found a bug.  _store_cache produces wrong output when
both KSH_TYPESET and MAGIC_EQUAL_SUBST are set.

Here's a piece of code:

  for var; do
    case ${(Pt)var} in
    (*readonly*) ;;
    (*(association|array)*) print -r "$var=( ${(kv@Pqq)^^var} )";;
    (*)                     print -r "$var=${(Pqq)^^var}";;
    esac
  done >! "$_cache_dir/$_cache_ident"

And here is how to reproduce a bug:

$ var=perl_modules
$ perl_modules=(AutoLoader DynaLoader SelfLoader)
$ emulate -R zsh
$ print -r "$var=( ${(kv@Pqq)^^var} )"
perl_modules=( 'AutoLoader' 'DynaLoader' 'SelfLoader' )
$ setopt KSH_TYPESET MAGIC_EQUAL_SUBST
$ print -r "$var=( ${(kv@Pqq)^^var} )"
perl_modules=( 'AutoLoader DynaLoader SelfLoader' )
$

So the cache data are unusable in the second case.
Actually this bug is not specific to _store_cache.

Any ideas?


-- 
Alexey Tourbin
ALT Linux Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: bug: _store_cache and ksh arrays

[Bart Schaefer]

On Tue, 19 Oct 2004, Alexey Tourbin wrote:

> I think I found a bug.  _store_cache produces wrong output when
> both KSH_TYPESET and MAGIC_EQUAL_SUBST are set.

_store_cache is meant to be called from the completion system functions,
which are meant to execute only with the setopts in the $_comp_options
array in effect.  Nearly all functions in the completion system assume
those settings and make no effort to work with arbitrary combinations of
setopts.

Re: bug: _store_cache and ksh arrays

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

On Mon, Oct 18, 2004 at 09:54:21PM -0700, Bart Schaefer wrote:
> > I think I found a bug.  _store_cache produces wrong output when
> > both KSH_TYPESET and MAGIC_EQUAL_SUBST are set.
> 
> _store_cache is meant to be called from the completion system functions,
> which are meant to execute only with the setopts in the $_comp_options
> array in effect.  Nearly all functions in the completion system assume
> those settings and make no effort to work with arbitrary combinations of
> setopts.

The bug still persists when _store_cache is called from completion
system functions (this is how I tracked down _store_cache), and I believe 
that the bug can be easily reproduced.

Please consider this:

$ rm -rf ~/.zcomp*
$ zsh
$ emulate -R zsh
$ zstyle ':completion::complete:*' use-cache 1
$ perl -M<TAB>
zsh: do you wish to see all 1917 possibilities (959 lines)? n
$ head -c70 ~/.zcompcache/perl_modules; echo
_perl_modules=( 'AcidRip::acidrip' 'AcidRip::interface' 'AcidRip::sign
$ rm -rf ~/.zcomp*
$ zsh
$ emulate -R zsh
$ setopt KSH_TYPESET MAGIC_EQUAL_SUBST
$ zstyle ':completion::complete:*' use-cache 1
$ perl -M<TAB>
zsh: do you wish to see all 1917 possibilities (959 lines)? n
$ head -c70 ~/.zcompcache/perl_modules; echo
_perl_modules=( 'AcidRip::acidrip AcidRip::interface AcidRip::signals
$

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: bug: _store_cache and ksh arrays

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Mon, Oct 18, 2004 at 09:54:21PM -0700, Bart Schaefer wrote:
> _store_cache is meant to be called from the completion system functions,
> which are meant to execute only with the setopts in the $_comp_options
> array in effect.  Nearly all functions in the completion system assume
> those settings and make no effort to work with arbitrary combinations of
> setopts.

Actually _comp_options neither set no unset KSH_TYPESET along with
MAGIC_EQUAL_SUBST.  Hence the problem.  Here is a patch.

Anyway I can't understand why "$var=( ${(kv@Pqq)^^var} )" should give
only one element for array with those options set.


--- zsh-4.2.1/Completion/compinit-	2004-08-13 10:22:16 +0000
+++ zsh-4.2.1/Completion/compinit	2004-10-19 14:06:27 +0000
@@ -145,6 +145,8 @@ _comp_options=(
     NO_aliases
     NO_errexit
     NO_octalzeroes
+    NO_kshtypeset
+    NO_magicequalsubst
 )
 
 # And this one should be `eval'ed at the beginning of every entry point

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: bug: _store_cache and ksh arrays

[Bart Schaefer]

On Tue, 19 Oct 2004, Alexey Tourbin wrote:

> Actually _comp_options neither set no unset KSH_TYPESET along with
> MAGIC_EQUAL_SUBST.  Hence the problem.  Here is a patch.

_comp_options can't change MAGIC_EQUAL_SUBST because some completers 
behave differently depending on an [[ -o magicequalsubst ]] test.
Just NO_kshtypeset should be sufficient.

> Anyway I can't understand why "$var=( ${(kv@Pqq)^^var} )" should give
> only one element for array with those options set.

I know why it happens, but I think it's a bug.  However, it might be just
a documentation bug rather than a code bug.  Here's the doc:

MAGIC_EQUAL_SUBST
     All unquoted arguments of the form `ANYTHING=EXPRESSION' appearing
     after the command name have filename expansion (that is, where
     EXPRESSION has a leading `~' or `=') performed on EXPRESSION as if
     it were a parameter assignment.  The argument is not otherwise
     treated specially; it is passed to the command as a single
     argument, and not used as an actual parameter assignment.  For
     example, in echo foo=~/bar:~/rod, both occurrences of ~ would be
     replaced.  Note that this happens anyway with typeset and similar
     statements.

     This option respects the setting of the KSH_TYPESET option.  In
     other words, if both options are in effect, arguments looking like
     assignments will not undergo wordsplitting.

The problem is with the word "unquoted" in the first line above.  It would 
seem that MAGIC_EQUAL_SUBST applies to double-quoted arguments, and only
single quoting entirely protects them.  In the absence of KSH_TYPESET this
is not apparent, because double-quoting is sufficient to prevent filename
expansion, but with KSH_TYPESET the side-effect on parameter expansion is
revealed.