"invalid arguments" in cpio completion

"invalid arguments" in cpio completion

[Danek Duvall]

This is on 5.2, but I don't see any changes to either _cpio or _arguments
between then and HEAD that appear to be relevant.

Here's the problem:

    $ cpio -p <TAB>
    _arguments:comparguments:313: invalid argument: 

The comparguments call is

    +_arguments:313> comparguments -i '' -s : '' '-d[create directories as needed]' '-l[link files instead of copying]' '-L[follow symbolic links]' '-m[preserve file modification times]' '-R[set user and group for files]:user (and group) for files:->user' '*:destination directory:_files -/' '-a[reset access time of input files]'

I'm guessing that it's the empty argument after "-s :", but I'm not sure.
That seems to be coming from this oddity:

    $ local args
    $ args+=(a b c)
    $ print -l -- "$args[@]"

    a
    b
    c

But explicitly declaring args as an array makes it work:

    $ local -a args
    $ args+=(a b c)
    $ print -l -- "$args[@]"
    a
    b
    c

and making that change in _cpio makes the completion work.  I'm just not
sure if the += construct on a scalar is supposed to make any sense here.

Thanks,
Danek

Re: "invalid arguments" in cpio completion

[Daniel Shahaf]

Danek Duvall wrote on Thu, Nov 03, 2016 at 13:32:56 -0700:
>     $ cpio -p <TAB>
>     _arguments:comparguments:313: invalid argument: 
> 

In HEAD I get filename completion at this point, regardless of whether
I choose the 'gnu' or 'unix' variant.

> That seems to be coming from this oddity:
> 
>     $ local args
>     $ args+=(a b c)
>     $ print -l -- "$args[@]"
> 
>     a
>     b
>     c
> 

This behaviour is the same in HEAD.

> But explicitly declaring args as an array makes it work:
⋮
> and making that change in _cpio makes the completion work.  I'm just not
> sure if the += construct on a scalar is supposed to make any sense here.

Will fix.

Cheers,

Daniel


diff --git a/Completion/Unix/Command/_cpio b/Completion/Unix/Command/_cpio
index 4027cc0..699b1d8 100644
--- a/Completion/Unix/Command/_cpio
+++ b/Completion/Unix/Command/_cpio
@@ -1,6 +1,7 @@
 #compdef cpio
 
-local args ig curcontext="$curcontext" state line
+local -a args
+local ig curcontext="$curcontext" state line
 local expl ret=1
 local fmts='(bar bin odc newc crc tar ustar hpbin hpodc)'
 

Re: "invalid arguments" in cpio completion

[Bart Schaefer]

On Nov 5,  8:39pm, Daniel Shahaf wrote:
}
} Danek Duvall wrote on Thu, Nov 03, 2016 at 13:32:56 -0700:
} > 
} >     $ local args
} >     $ args+=(a b c)
} >     $ print -l -- "$args[@]"
} > 
} >     a
} >     b
} >     c
} > 
} 
} This behaviour is the same in HEAD.

That's not new behavior; using array-append on a scalar converts the
scalar into a 1-element array before appending to it.

The question is whether an empty scalar should be converted into a
1-element array or an empty array.  This goes back to the fact that
in zsh without posixbuiltins, a declared variable is implicitly set,
and therefore its value is the empty string.

BTW, in the current HEAD zsh *with* posixbuiltins, attempting to
assign an array to an exported scalar will result in an error message
*but also* causes the scalar to become set (to empty).  I'm not sure
what if anything posix compatibility would say about this.