From owner-freebsd-current Mon Jan 5 06:48:51 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA08116 for current-outgoing; Mon, 5 Jan 1998 06:48:51 -0800 (PST) (envelope-from owner-freebsd-current) Received: from unix.tfs.net (as1-p111.tfs.net [139.146.210.111]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA08035 for ; Mon, 5 Jan 1998 06:47:51 -0800 (PST) (envelope-from jbryant@unix.tfs.net) Received: (from jbryant@localhost) by unix.tfs.net (8.8.8/8.8.5) id IAA11455; Mon, 5 Jan 1998 08:47:31 -0600 (CST) From: Jim Bryant Message-Id: <199801051447.IAA11455@unix.tfs.net> Subject: Re: Time to retire fetch? In-Reply-To: <4721.883994636@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 5, 98 02:03:56 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 5 Jan 1998 08:47:30 -0600 (CST) Cc: freebsd-current@freebsd.org Reply-to: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Operating-System: FreeBSD 3.0-CURRENT #0: Thu Jan 1 19:03:58 CST 1998 X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > I just noticed that FTP in -current now supports http:// style > fetches, a feature which seems to have crept in under my nose during > the sync with NetBSD's ftp client. Given that, the questions now in > my mind are: > > 1. Do we want to retire fetch and just use ftp now as our > FETCH_CMD in -current? Would any fetch features be missed > that would also be overtly difficult to merge into the ftp > client? Strengthening one tool rather than putting two > into competition is obviously a worthy goal if it's possible > to do it. > > 2. Do we simply want to ignore this new feature of ftp, perhaps > under the premise that having an ftp client fetch http URLs > is rather counter-intuitive if one is a stickler for naming > conventions, and just go on like we are now? > > 3. Given that ftp probably doesn't deal well with the file:/ > URLs that can also be passed to fetch(1) from the ports > collection, does fetch(1) perhaps want to stick around but > simply become a smaller pre-parsing script which hands its > work off to other tools rather than doing it itself? > > I've no clear preference right now, I'm just musing out loud. > Comments? i find fetch to be more reliable than either ncftp or ftp when it comes to retreiving files from wcarchive in recent weeks. also fetch has the ability to resume a terminated transfer. to give one example, i transferred the last snapshot first with ncftp, then ftp, and then fetch from a hand-built script [pain in the butt]. the only thing that worked, even after approximately 37 script restarts, was the fetch script. my vote is to keep fetch. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+