Re: Bug#239070: zsh: scp completion expands * too soon (patch)

[Clint Adams <schizo@xxxxxxxxxx>]

I think the tmda-like thing on the zsh lists probably blocked your
message, so I'm just going to quote your entire report in reply.

On Sat, Mar 20, 2004 at 12:50:08PM -0500, Jay Berkenbilt wrote:
> Package: zsh
> Version: 4.1.1-11
> Severity: normal
> Tags: patch
> 
> This bug is present in the current zsh in CVS as well, so I have cc'ed
> zsh-workers@xxxxxxxxxxx  I hope that works.  I am not a subscriber to
> that list.
> 
> In a recent upgrade to zsh, completion for scp broke when resolving
> remote files.  There are two problems: wildcards are expanded too
> soon, and completion through symbolic links to directories doesn't
> work right (no trailing slash is provided).  These should rightfully
> be reported as two separate bug reports, but the two bugs are caused
> by the same line of code, which makes it hard to send two separate
> patches. :-)
> 
> I have verified that both of these bugs are reproducible with a
> generic vanilla uncustomized account whose sole zsh initialization is
> 
> autoload -U compinit
> compinit
> 
> These problems are not caused by anything special about my
> environment.
> 
> I have a machine "apex" that is (at the moment) a Red Hat Linux
> machine, and my local machine is running sid.  If I do
> 
> ssh apex:/ [TAB]
> 
> I see a list of all the files and directories that are common to the
> two machines.  The "apex" machine has the directory /shares, but my
> local machine does not.  If I do
> 
> ssh apex:/shares/ [TAB]
> 
> zsh generously appends "./" to the commandline.
> 
> This trace excerpt clearly shows what's happening.  The _remote_files
> function in /usr/share/zsh/4.1.1/functions/Completion/Unix/_ssh calls
> _call_program
> (/usr/share/zsh/4.1.1/functions/Completion/Base/_call_program) which
> ultimately ends up doing eval "$argv[2,-1]" which causes all the wild
> cards to be expanded.  It appears that _call_program is not providing
> any advantage here because the zstyle check that it makes will
> probably always be false here, but my understanding of zstyle is
> murky.  (If I am reading this right, then the zstyle check is seeing
> whether the user has configured completion so that this should be
> completed as a command instead of as files.  Or something close to
> that.)  In any case, using it clearly causes problems and fixing
> _call_function to prevent wildcard expansion could have any number of
> unanticipated side effects.
> 
> Here's the trace excerpt from ssh apex:/ [TAB]:
> 
> +_ssh:238> compset -P '*:'
> +_ssh:239> _remote_files
> +_remote_files:2> local expl remfiles remdispf remdispd args suf 'ret=1'
> +_remote_files:4> zstyle -T :completion::complete:scp:argument-rest:files remote-access
> +_remote_files:5> zparseopts -D -E -a args p: 1 2 4 6 F:
> +_remote_files:6> remfiles=+_remote_files:1> _call_program files ssh -a -x apex ls -d1F '/*'
> +_call_program:3> local tmp
> +_call_program:5> zstyle -s :completion::complete:scp:argument-rest:files command tmp
> +_call_program:12> eval 'ssh -a -x apex ls -d1F /*'
> +(eval):1> ssh -a -x apex ls -d1F /bin /boot /cdrom /cdrom0 /dark /dark2 /dev /etc /fc1 /floppy /home /initrd /initrd.img /initrd.img.old /lib /lost+found /mnt /opt /proc /projects /.rnd /root /sbin /smb /sys /systems /tmp /tmp-Xhack /u1 /u2 /usr /var /vmlinuz /vmlinuz.old
> +_remote_files:6> remfiles=( bin/ boot/ dev/ etc/ home@ initrd/ lib/ lost+found/ mnt/ opt/ proc/ projects@ root/ sbin/ smb/ systems/ tmp/ usr/ var/ ) 
> 
> This patch corrects this problem by simply removing the call to
> _call_program.
> 
> The other problem (symbolically linked directories) is easily resolved
> by adding the "L" flag to "ls" in addition to the -d1F flags.  This
> results in symbolic links to directories being treated like normal
> directories which is what you want when completing.
> 
> Here's the patch.
> 
> ------8<------
> --- _ssh.qdist	2004-03-13 16:32:00.000000000 -0500
> +++ _ssh	2004-03-20 12:16:50.000000000 -0500
> @@ -6,7 +6,7 @@
>  
>    if zstyle -T ":completion:${curcontext}:files" remote-access; then
>      zparseopts -D -E -a args p: 1 2 4 6 F:
> -    remfiles=(${(M)${(f)"$(_call_program files ssh $args -a -x ${IPREFIX%:} ls -d1F ${(Q)PREFIX%%[^./][^/]#}\* 2>/dev/null)"}%%[^/]#(|/)})
> +    remfiles=(${(M)${(f)"$(ssh $args -a -x ${IPREFIX%:} ls -d1FL ${(Q)PREFIX%%[^./][^/]#}\* 2>/dev/null)"}%%[^/]#(|/)})
>      compset -P '*/'
>      compset -S '/*' || suf='remote file'
>  
> ------8<------
> 
> In CVS, this bug was introduced between revision 1.20 and 1.21 of the
> _ssh file.  There is no explanation as to why this change was made.
> Hopefully this fix can make it into zsh before 4.2.0 and into Debian
> one way or another.
> 
> 
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
> Kernel: Linux 2.4.25-q
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
> 
> Versions of packages zsh depends on:
> ii  debconf                     1.4.16       Debian configuration management sy
> ii  libc6                       2.3.2.ds1-11 GNU C Library: Shared libraries an
> ii  libcap1                     1:1.10-13    support for getting/setting POSIX.
> ii  libncurses5                 5.4-2        Shared libraries for terminal hand
> ii  passwd                      1:4.0.3-21   Change and administer password and
> 
> -- debconf information:
>   zsh/rcmove: 

> --- _ssh.qdist	2004-03-13 16:32:00.000000000 -0500
> +++ _ssh	2004-03-20 12:16:50.000000000 -0500
> @@ -6,7 +6,7 @@
>  
>    if zstyle -T ":completion:${curcontext}:files" remote-access; then
>      zparseopts -D -E -a args p: 1 2 4 6 F:
> -    remfiles=(${(M)${(f)"$(_call_program files ssh $args -a -x ${IPREFIX%:} ls -d1F ${(Q)PREFIX%%[^./][^/]#}\* 2>/dev/null)"}%%[^/]#(|/)})
> +    remfiles=(${(M)${(f)"$(ssh $args -a -x ${IPREFIX%:} ls -d1FL ${(Q)PREFIX%%[^./][^/]#}\* 2>/dev/null)"}%%[^/]#(|/)})
>      compset -P '*/'
>      compset -S '/*' || suf='remote file'
>