Received: with ECARTIS (v1.0.0; list gopher); Wed, 07 Aug 2002 09:28:10 -0500 (EST) Return-Path: <jgoerzen@complete.org> Delivered-To: gopher@complete.org Received: from christoph.complete.org (unknown [168.215.193.254]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "christoph.complete.org", Issuer "John Goerzen -- Root CA" (verified OK)) by gesundheit.complete.org (Postfix) with ESMTP id 90E6261CF0; Wed, 7 Aug 2002 09:28:09 -0500 (EST) Received: by christoph.complete.org (Postfix, from userid 1000) id 85DC4166B4; Wed, 7 Aug 2002 02:09:26 -0500 (EST) Date: Wed, 7 Aug 2002 02:09:26 -0500 From: John Goerzen <jgoerzen@complete.org> To: gopher@complete.org Subject: [gopher] Re: PyGopherd UMN Broken Message-ID: <20020807070926.GC832@complete.org> References: <3D50C2BD.4010005@myrealbox.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D50C2BD.4010005@myrealbox.com> User-Agent: Mutt/1.4i Content-Transfer-Encoding: 8bit X-archive-position: 661 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: jgoerzen@complete.org Precedence: bulk Reply-to: gopher@complete.org List-help: <mailto:ecartis@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Ecartis version 1.0.0 List-ID: Gopher <gopher.complete.org> X-List-ID: Gopher <gopher.complete.org> List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe> List-owner: <mailto:jgoerzen@complete.org> List-post: <mailto:gopher@complete.org> List-archive: <http://www.complete.org/mailinglists/archives/> X-list: gopher

On Wed, Aug 07, 2002 at 01:48:29AM -0500, Aaron J. Angel wrote: > > I can't seem to get .Links working. From what I read from the handler > in the comments, it only merges when path begins with ./ or ~/? Does > that mean it discards everything else? If so, why? UMN doesn't do > this, IIRC; the whole point of .Links is to provide external links, > otherwise it'd be fairly useful.

Can you provide an example of the problem?

In fact, PyGopherd is emulating UMN gopherd behavior. The thing is, UMN gopherd does not actually treat .Links differently from .names, or any other file beginning with a . that looks like a UMN dotfile. They are all read and parsed the same way. You could name it .Frobnitz and it would still work exactly the same.

When you have a Path that begins with ./, this means that you are applying the lines that follow as an override for a menu entry automatically generated for that particular file. This is typically used in .names files in UMN gopherd installations.

When the Path does not begin with ./, it is assumed to be a new menu entry and is thusly inserted as specified in .Links.

I do not recall the exact semantics of ~/ at the moment; I will have to check on that.

> And, if I'm reading this correctly, then what I'm reading is wrong (line > 210 of UMN.py from v1.0.0: > > > if len(line) >= 7 and (line[5:7] == './' or line[5:7] == '~/'):

> I don't know too much about Python per se, but isn't [5:7] 3 characters > long?

No:

"asdfaewrqwrqwerwrdfasdfasfaf"[5:7] 'ew'

Python's range end (the 7 in this case) is not inclusive, but the range beginning is, so that will include characters 5 and 6 only.

> > Also, another problem: The UMN gopherd(8) manpage specifies an available > type, -, to hide the entry from the menu for use in .cap/XX files.

I had always used type X for that. I will investigate the type -.

> PyGopherd doesn't seem be able to hide files from the menu using .cap > files. Can that functionality be added to PyGopherd's link handler?

Does it work if you use type X in the .cap files?

-- John Goerzen <jgoerzen@complete.org> GPG: 0x8A1D9A1F www.complete.org