From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4303 invoked from network); 22 May 2000 16:18:16 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 22 May 2000 16:18:16 -0000 Received: (qmail 16941 invoked by alias); 22 May 2000 16:17:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11511 Received: (qmail 16925 invoked from network); 22 May 2000 16:17:50 -0000 Date: Mon, 22 May 2000 17:17:23 +0100 From: Peter Stephenson Subject: Re: Proxy support for zftp functions In-reply-to: "Your message of Mon, 22 May 2000 20:03:46 +0400." <000d01bfc407$4f1c1980$21c9ca95@mow.siemens.ru> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Message-id: <0FUY009QZYKZGE@la-la.cambridgesiliconradio.com> Content-transfer-encoding: 7BIT > > This was on my original plan, but not only didn't I need it > > myself I didn't > > even have a proxy host to try on, so I never thought much about it. > > I was actually imagining doing it in the C code. > > Yes, it makes more sense. Proxy is relevant only for a logon - then it > is completely transparent (hopefully :-). Actually, for just that reason, your idea of doing it in the functions is probably better. The less hidden code the more I like it. > Actually, much more interesting (needed) feature is ls parsing. > Currently, zftp relies on MDTM/SIZE to exist - and, unfortunately, they > are missing in "common" Unix servers. Have you ever thought about it? There's a nice project for someone with a bit of time. This can probably be done in shell functions too --- it's system-specific, so not good to hard code, and the only place this is used internally is for supplying to functions doing progress reports, which can be rewritten to use information returned by ls where necessary. -- Peter Stephenson Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070