From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12475 invoked from network); 5 Jun 2001 13:14:43 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Jun 2001 13:14:43 -0000 Received: (qmail 18339 invoked by alias); 5 Jun 2001 13:14:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14721 Received: (qmail 18328 invoked from network); 5 Jun 2001 13:14:27 -0000 Date: Tue, 5 Jun 2001 14:14:33 +0100 From: Adam Spiers To: zsh workers mailing list Subject: Re: trailing slash in scp completions Message-ID: <20010605141433.B8911@thelonious.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh workers mailing list References: <20010601215540.A14573@thelonious.new.ox.ac.uk> <1010603191650.ZM30422@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1010603191650.ZM30422@candle.brasslantern.com>; from schaefer@candle.brasslantern.com on Sun, Jun 03, 2001 at 07:16:50PM +0000 X-Home-Page: http://www.new.ox.ac.uk/~adam/ X-OS: RedHat Linux Bart Schaefer (schaefer@candle.brasslantern.com) wrote: > } $ scp my.remote.host:rem > } $ 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?