trailing slash in scp completions

trailing slash in scp completions

[Adam Spiers]

Might there be time to squeeze in a fix for this before 4.0.1?

  $ scp my.remote.host:rem<TAB>
  $ scp my.remote.host:remote_dir
                                  ^

The completion works fine, but doesn't add a trailing slash.

Thanks,

Adam

Re: trailing slash in scp completions

[Bart Schaefer]

On Jun 1,  9:55pm, Adam Spiers wrote:
}
} Might there be time to squeeze in a fix for this before 4.0.1?

You were a couple of hours too late.

}   $ scp my.remote.host:rem<TAB>
}   $ scp my.remote.host:remote_dir
}                                   ^
} The completion works fine, but doesn't add a trailing slash.

The problem is that there's no reliable way for zsh to ask the remote
host what names are files and what names are directories.  It doesn't
even know what the shell on the remote host is.  So right now this
completion is extremely simplistic (see _remote_files in C/U/C/_ssh);
it doen't even work consistently for complete_in_word, much less with
case-folding match specs and approximation and the like.

This is similar to the issues we've been discussing for _man, with the
added complication that `compfiles' cannot come to the rescue and doing
the full glob is potentially even more expensive.

Possible ways to improve it include:

* add zstyles to configure the remote listing command on a per-host-
  per-user basis;

* cache per-host-per-user the result of $(ssh user@host 'echo $SHELL')
  and use a `case' on the shell to choose the remote listing command;

* supply a utility function -- which would have to be loadable from a
  well-known fpath, or defined/loaded in the user's ~/.zshenv -- to
  perform part of the completion on the remote machine and pass back
  the results, and use that only when the remote shell is the proper
  version of zsh.

Of these, only the utility function can do very much with matchers and
approximation.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: trailing slash in scp completions

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> }   $ scp my.remote.host:rem<TAB>
> }   $ scp my.remote.host:remote_dir
> }                                   ^
> } The completion works fine, but doesn't add a trailing slash.
> 
> The problem is that there's no reliable way for zsh to ask the remote
> host what names are files and what names are directories.  It doesn't
> even know what the shell on the remote host is.

Right.  I suspected it might be something like that.

> Possible ways to improve it include:
> 
> * add zstyles to configure the remote listing command on a per-host-
>   per-user basis;
> 
> * cache per-host-per-user the result of $(ssh user@host 'echo $SHELL')
>   and use a `case' on the shell to choose the remote listing command;
> 
> * supply a utility function -- which would have to be loadable from a
>   well-known fpath, or defined/loaded in the user's ~/.zshenv -- to
>   perform part of the completion on the remote machine and pass back
>   the results, and use that only when the remote shell is the proper
>   version of zsh.
> 
> Of these, only the utility function can do very much with matchers and
> approximation.

I think that whatever we decide on, it makes more sense for the
responsibility (for deciding how to provide the necessary information)
to lie with the remote machine.  That way if things change on the
remote machine (e.g. someone installs zsh on it, which would
presumably make things easier), you don't end up with a load of
incorrect zstyles or stale caches locally.  This is especially
significant when you consider that people might have several "local"
accounts, ie. several machines from which they would want to ssh/scp
to the remote machine in question.

Hmm.  This does throw up the problem of requiring two ssh processes
though - one to ask the remote machine how to retrieve the infomation
we want, and one to actually retrieve it - and of course two ssh
processes are way too expensive.  Maybe a cache is unavoidable?

Of course we could really go to town on this and support matchers
etc. if the remote shell is an appropriate zsh, but personally I would
be plenty happy if it just managed to get the trailing slash right.
Presumably an `ls -l' is going to work pretty much everywhere?