completion bug: treats substitution of unset parameter as empty string

completion bug: treats substitution of unset parameter as empty string

[Greg Klanderman]

[resending as my post from Monday seems not to have made it to the list]

% unset Q
% ls $Q/ <tab>

lists completions in '/' rather than beep because there are no
completions.

I do have the 'nounset' option set, though I think this should
give an error / no completions either way, as it did with the
old compctl system.

greg

Re: completion bug: treats substitution of unset parameter as empty string

[Greg Klanderman]

>>>>> On July 29, 2009 -- Greg Klanderman <gak@klanderman.net> wrote:

> % unset Q
> % ls $Q/ <tab>

> lists completions in '/' rather than beep because there are no
> completions.

> I do have the 'nounset' option set, though I think this should
> give an error / no completions either way, as it did with the
> old compctl system.

OK, so just this line in _path_files needs 'setopt nounset':

|    eval 'realpath=${(e)~linepath}' 2>/dev/null

Is the best way to do that to use an anonymous function:

|    function {
|      setopt localoptions nounset
|      eval 'realpath=${(e)~linepath}' 2>/dev/null
|    }

or is this paradigm which I see in a few places preferred:

|    setopt nounset
|    eval 'realpath=${(e)~linepath}' 2>/dev/null
|    setopt unset

How exactly is the default set of shell options arrived at for the
evaluation of completion functions?  My own setopts do not seem to
effect the completion functions.. how is that?

thanks,
Greg

Re: completion bug: treats substitution of unset parameter as empty string

[Peter Stephenson]

Greg Klanderman wrote:
> How exactly is the default set of shell options arrived at for the
> evaluation of completion functions?  My own setopts do not seem to
> effect the completion functions.. how is that?

See _comp_options and _comp_setup in compinit and the use of _comp_setup
in _main_complete.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: completion bug: treats substitution of unset parameter as empty string

[Greg Klanderman]

>>>>> On September 10, 2009 Peter Stephenson <pws@csr.com> wrote:

> See _comp_options and _comp_setup in compinit and the use of _comp_setup
> in _main_complete.

OK, thanks for the pointer..

Here's a patch to fix the originally reported problem - that
_path_files incorrectly treats a parameter expansion of an
unset parameter as the empty string, i.e. that

% ls $foobar/ <tab>

lists completions under '/'.

thanks,
Greg


Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.47
diff -u -r1.47 _path_files
--- Completion/Unix/Type/_path_files	5 Aug 2009 00:46:45 -0000	1.47
+++ Completion/Unix/Type/_path_files	10 Sep 2009 14:26:53 -0000
@@ -247,7 +247,9 @@
   # meant as a partial path.
 
   linepath="${(M)pre##*\$[^/]##/}"
+  setopt nounset # do not treat an unset parameter expansion as the empty string
   eval 'realpath=${(e)~linepath}' 2>/dev/null
+  setopt unset
   [[ -z "$realpath" || "$realpath" = "$linepath" ]] && return 1
   pre="${pre#${linepath}}"
   i='[^/]'

Re: completion bug: treats substitution of unset parameter as empty string

[Peter Stephenson]

On Thu, 10 Sep 2009 10:30:42 -0400
Greg Klanderman <gak@klanderman.net> wrote:
> Here's a patch to fix the originally reported problem - that
> _path_files incorrectly treats a parameter expansion of an
> unset parameter as the empty string, i.e. that
> 
> % ls $foobar/ <tab>
> 
> lists completions under '/'.

That's fine, however I think (belatedly answering your other question)
that, since we don't need to backport this anywhere, using an anonymous
function would be neater---so we're not relying on the value of "nounset"
outside.  In practice if it were set outside all hell would break loose, so
this is pretty pernickety, but perhaps it's a useful precedent.

Index: Completion/Unix/Type/_path_files
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Type/_path_files,v
retrieving revision 1.47
diff -u -r1.47 _path_files
--- Completion/Unix/Type/_path_files	5 Aug 2009 00:46:45 -0000	1.47
+++ Completion/Unix/Type/_path_files	10 Sep 2009 14:36:56 -0000
@@ -247,7 +247,11 @@
   # meant as a partial path.
 
   linepath="${(M)pre##*\$[^/]##/}"
-  eval 'realpath=${(e)~linepath}' 2>/dev/null
+  function {
+    # do not treat an unset parameter expansion as the empty string
+    setopt localoptions nounset
+    eval 'realpath=${(e)~linepath}' 2>/dev/null
+  }
   [[ -z "$realpath" || "$realpath" = "$linepath" ]] && return 1
   pre="${pre#${linepath}}"
   i='[^/]'

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: completion bug: treats substitution of unset parameter as empty string

[Greg Klanderman]

>>>>> On September 10, 2009 Peter Stephenson <pws@csr.com> wrote:

> That's fine, however I think (belatedly answering your other question)
> that, since we don't need to backport this anywhere, using an anonymous
> function would be neater---so we're not relying on the value of "nounset"
> outside.  In practice if it were set outside all hell would break loose, so
> this is pretty pernickety, but perhaps it's a useful precedent.

That works too.  I went with the setopt .. unsetopt since that's what
other completion functions were doing.  I do prefer the anonymous
function, aside from my objection to calling such things functions.
If I could pass arguments after the '}' maybe but you still cannot
control when it is called - it's only a local scope, not a function.

greg