From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2066 invoked from network); 30 May 2000 15:58:15 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 May 2000 15:58:15 -0000 Received: (qmail 13191 invoked by alias); 30 May 2000 15:57:59 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11667 Received: (qmail 13184 invoked from network); 30 May 2000 15:57:57 -0000 Subject: Re: Fw: poor man's wget In-Reply-To: <0FVD007CJOL1JJ@la-la.cambridgesiliconradio.com> from Peter Stephenson at "May 30, 2000 04:05:25 pm" To: Peter Stephenson Date: Tue, 30 May 2000 16:57:14 +0100 (BST) CC: Zsh hackers list X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Peter Stephenson wrote: >> > { echo GET /; echo; cat; } <>/dev/tcp/www.server.com/80 Having the shell give pathnames magic semantics that the rest of the OS doesn't is evil and rude. That sort of feature should be done in a user-space filesystem. >This could be done without much difficulty by simplifying zftp_open and >wiring the code into the existing redirection stuff. Unfortunately no-one >else apart from Zefram has shown much interest in the network stuff, so >it's unlikely to happen any time soon. Hmm. I do have some future plans for a shell module that would do generic socket stuff of this nature (using a more rational syntax), though, as you say, it's unlikely to happen any time soon. >You could probably then rewrite most if not all of zftp as shell functions. Yes. -zefram