HDTenEightyP/NetNews huggingface dataset:
Date: Sun, 22 Nov 92 14:47:28 +0100
From: fkappe@fiicmds04.tu-graz.ac.at (Frank Kappe)
Original-To: barrie@futique.scs.unr.edu
Original-Cc: gopher-news@boombox.micro.umn.edu
Subject: Bug in Veronica
Newsgroups: comp.infosystems.gopher
Distribution: comp

>>>>> On Fri, 20 Nov 92 12:26:14 GMT+0500, barrie@futique.scs.unr.edu (Fred Barrie) said:

Fred> Veronica *will not* work with unix gopher client 1.02...

Fred> It will work with 1.01 and 1.03.  I have not looked in to what the
Fred> difference between 1.02 and 1.01 and 1.03 is.

I also had problems interfacing to Veronica from our Hyper-G client. This is
what I fopund out:

It appears to me that Veronica insists on terminating the keyword with '\r\n' (C
notation). If the client fails to send the '\r' you have to supply one more
character that is going to be ignored (?).

Furthermore, strange things happen on some keywords. E.g., when asking for 'gra'
I get:

   -->    1.  Shoebox Activities II: A Working Session for Teachers of Gra.
          2.  Space Travel: Classroom Activities for Teachers of Grades K-.
          3.  Stefan Gravenstein.
          4.  Poltrock S. E., Steiner D. D., Tarlton P. N.: Graphic Interfaces for Knowledge-Base.
          5.  Proceedings of ACM CHI+GI'87 Conference on Human Factors in Computing Systems and G.
          6.  Proceedings of the ACM SIGGRAPH Symposium on User Interface Software and Technology.
          7.  Proceedings of the ACM SIGGRAPH Symposium on User Interface Software and Technology.
          8.  Proceedings of the ACM SIGGRAPH Symposium on User Interface Software and Technology.
          9.  Proceedings of the ACM SIGGRAPH Symposium on User Interface Software; User Interfac.
          10. Programmer's Cheer.
          11. Rationalisieren (9): Gras auf dem Mond.
          12. Real Programmers.
          13. Reiser B. J., Friedmann P., Gevins J., Kimberg D. Y., Ranney M., Romero A.: A Graph.
          14. Reisner P.: Further Developments Toward Using Formal Grammar as a Design Tool.

----------------------------------------------------------------------------
Frank M. Kappe                                     fkappe@iicm.tu-graz.ac.at
Institute for Information Processing and Computer Supported New Media (IICM)
                  Graz University of Technology, Austria
Voice: ++43/316/832551-22                               Fax: ++43/316/824394
----------------------------------------------------------------------------
From: RBF@psuvm.psu.edu
Newsgroups: comp.infosystems.gopher
Subject: Re: Waisindex indexing the index.* files
Date: 17 Nov 92 16:00:06 GMT
 <1992Nov17.064002.9696@news2.cis.umn.edu>
Organization: Penn State University

Thanks very much.  Adding "/*" to the pathname in the invocation of
waisindex fixed the problem.
   Bob Fowles, Center for Academic Computing, Penn State
Date: Tue, 17 Nov 92 11:16:34 +1000
Original-To: gopher-news@boombox.micro.umn.edu
From: m.connell@ucq.edu.au
X-Sender: connellm@pinjel.ucq.edu.au
Subject: Apple Gopher Server
Newsgroups: comp.infosystems.gopher
Distribution: comp

Can anyone give me the details of the Gopher server at Apple ?

Thanks.

Merv Connell
m.connell@ucq.edu.au
From: RBF@psuvm.psu.edu
Newsgroups: comp.infosystems.gopher
Subject: Waisindex indexing the index.* files
Date: 16 Nov 92 22:12:24 GMT
Article-I.D.: psuvm.92321.171224RBF
Organization: Penn State University

I am running the 1.03 Unix server from Boombox and the Wais code (from
wais-8-b5) under Aix/ESA.  I build indexes in the usual way by cd'ing to a
.index directory and then running waisindex.  The index.* files that are
built work fine except that they also include the data in the index.* files.
How do I prevent waisindex from indexing the index.* files that it builds in
the .index directory (this occurs right before waisindex finishes).  I have
tried this with and without the gopher daemon running and get the same
result.

Bob Fowles, Center for Academic Computing, Penn State
From: yandros@MIT.EDU (Chad Phillip Brown)
Newsgroups: comp.infosystems.gopher
Subject: Re: Is There an Open Look Xgopher?
Date: 16 Nov 1992 08:27:37 GMT
Organization: /mit/yandros/.organizations
	<1992Nov15.064138.22008@ra.msstate.edu>
NNTP-Posting-Host: deathtongue.mit.edu
In-reply-to: fwp@CC.MsState.Edu's message of Sun, 15 Nov 1992 06:41:38 GMT


->From: fwp@CC.MsState.Edu (Frank Peters)
> Sacrificing user satisfaction in favor of some abstract ideal of
> purity is, in my opinion, a bad idea.

I must say that I agree, and I suspect that most other people will,
too.  One of the major advantages of gopher that I can see is that the
protocol is simple enough that building clients is trivial; for people
who want an `pure' interface, there's always the one you mentioned:
telnet.

-C
--
-->Chad Phillip Brown<--||INTERNET:---->yandros@Athena.MIT.EDU
------------------------||NeXT:---------->yandros@milo.mit.edu
-->Student Information<-||UUCP:-->mit-eddie!mit-athena!yandros		
--->Processing Board<---||BITNET:------>yandros%mit.edu@mitvma
----->CSSConsultant<----||US:--->19 Myrtle;Somerville MA;02143
-------->IS-DCNS<-------||Voice:----------------->617-623-0877
Newsgroups: comp.infosystems.gopher
From: lindner@mudhoney.micro.umn.edu (Paul Lindner)
Subject: Re: More bugs gopher1.1b1 (beta programmers as well as code)
Organization: University of Minnesota, Minneapolis
Date: Mon, 16 Nov 1992 18:51:58 GMT

In <BxrI8o.Ir0@alsvid.une.edu.au> mark@alsvid.une.edu.au (Mark Garrett Internet: mark@arvak.une.edu.au Phone: +61 66 20 3859) writes:

>I feel like being abusive, I'll attempt not to be. I'd like to ask
> one question? 

>	Who has put in the work on gopher1.1b1 ?? One of you has not been
>coding in C for long. If there are some inexperienced programmers working on
>this software for my sake and others please vet their code changes.

Well, I have been coding in C for quite some time now..  BTW, I'm the
*only* one working on this software (not counting the oodles of
countless code contributions of course!!).  Let me rephrase this.  I'm
the only one around here getting paid to actually code this :-)


>	strlen returns the length of a string not counting the null
>terminator!!!!! please inscribe this into them... So that when they malloc
>space or whatever they allow for that one extra. 

Okay, alright, point taken...  I come from the hippie programming
school.. I like to get stuff mostly working.  I let the AR's
like yourself fix my little bugs :-)

>	Here is a diff of my 1.1b1 against the release version.
>I hope this helps somebody else with the code, which I might add has some
>major advantages despite my flame about coding. 

Of course, throw in the features and everything else will follow :-)

I've learned my lesson.  I'll add my +1's from now on....
--
 | Paul Lindner | lindner@boombox.micro.umn.edu   | Slipping into madness
 |              | Computer & Information Services | is good for the sake
 | Gophermaster | University of Minnesota         | of comparision.
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /
From: brockie@golem.wcc.govt.nz (Roger Brockie)
Newsgroups: comp.infosystems.gopher
Subject: Re: unix gopherd -s and -l don't work togeather
Date: 17 Nov 1992 19:46:22 +1300
Organization: Wellington City Council, Wellington, NZ
NNTP-Posting-Host: golem.wcc.govt.nz

In article <BxtyKC.B39@uxa.ecn.bgu.edu> xcea@uxa.ecn.bgu.edu (Chad Adams) writes:
>I am tring to use the following in inetd.conf on SunOS 4.1.2 and it does
>not work:  (line split up to into 80 column chunks to put in article)
>
>gopher stream tcp nowait root /usr/local/etc/gopherd gopherd -I
>-s/home/uxa/xgopher/public_access -l/home/uxa/xgopher/log/public -uxgopher
>/home/uxa/xgopher/gopher-public 70
>
>It can't access the main menu.  If I take out the -s or the -l it works.
>We need to use both -s and -l.

You can only have 5 parameters in inetd.conf.  You have 6 which is why it works
when you remove one.

I think you'll find that the last 2 (the directory and port) are not needed
because they are builtin into the code via the Makefile.  But that maybe
1.1b1.

But it is a problem.  Maybe we need an /etc/gopherd.conf file instead ?

Roger


-- 
brockie@golem.wcc.govt.nz
Newsgroups: comp.infosystems.gopher
From: rahardj@ccu.umanitoba.ca (Budi Rahardjo)
Subject: perl gopher (was Re: More bugs gopher1.1b1 )
Organization: University of Manitoba, Winnipeg, Canada
Date: Thu, 19 Nov 1992 05:57:45 GMT

schemers@Slapshot.Stanford.EDU (Roland Schemers) writes:

>In article <1edt7rINN1sl@nigel.msen.com>, emv@msen.com (Edward Vielmetti) |> 
>|> I have a hunch that a competent perl programmer could put together a
>|> bare bones totally new server in a fairly short amount of time, either
>|> of the traditional "it's a file system" model plopped down on a bunch of
>|> directories or some kind of "it's a database" model stuck in in front
>|> of dbm or oracle or sybase databases.  The protocol per se is just not
>|> that complicated.
>|> 

>Actually I was going to do this. After thinking about the go4gw stuff, it
>seemed that a perl gopher would be much easier to write, maintain, modify,
>etc, in perl.  

Yes, yes, yes, please.

...
>Sounds like a project for this weekend... :-O



>Roland

-- budi
-- 
Budi Rahardjo <Budi_Rahardjo@UManitoba.Ca>
Unix Support - Computer Services - University of Manitoba
Newsgroups: comp.infosystems.gopher
From: lindner@mudhoney.micro.umn.edu (Paul Lindner)
Subject: Re: building gopher wais search server
Keywords: build gopherd wais index search
Organization: University of Minnesota, Minneapolis
Date: Mon, 16 Nov 1992 17:25:02 GMT

In <BxrEGC.2t7@usenet.ucs.indiana.edu> gilbertd@sunflower.bio.indiana.edu (Don Gilbert) writes:

>The modification's I have made to gopher, for use of my changes to wais,
>are only needed if (a) you want to index and search biology or other data
>that contains symbols, (b) you would like to add some minor enhancements or
>hacks of mine (like date+size display, display of header files for
>range retreivals, extended search retrievals >200, or likewise small things).

True...  However I noticed that I was getting core dumps when using
iubio-wais-v8b5 with stock 1.x gopher code.  Turns out that gopher
wasn't setting the WordDelimiter function...  If this function isn't
set the Wais code blows up trying to execute a NULL function...

>You do not need to edit the gopher v1 server or client in order to use
>the enhancements to WAIS that many of you want:  booleans, partial words
>and literal phrase searches.  These three changes affect only the WAIS
>server portion.   If you want to add just these features, fetch the
>iubio-wais-v8b5.tar.Z source, compile it WITHOUT the -DBIO option,
>then re-compile your gopherd program linking to this new wais, and
>you should be set.   No need even to re-index your data.   

Perhaps the above bug doesn't happen if you don't compile with
-DBIO????? 




--
 | Paul Lindner | lindner@boombox.micro.umn.edu   | Slipping into madness
 |              | Computer & Information Services | is good for the sake
 | Gophermaster | University of Minnesota         | of comparision.
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /
Newsgroups: comp.infosystems.gopher
From: simpsong@dns0.bham.ac.uk (Glyn Simpson)
Subject: Problem with GONNTP
Date: Fri, 20 Nov 1992 12:10:39 GMT
Reply-To: G.Simpson@bham.ac.uk
Organization: The University of Birmingham, England
X-Newsreader: TIN [version 1.1 PL7]

Hi, i'm using gonntp Gopher-NNTP interface on a Sun (SunOS4.1.1) and have
had a few problems in getting it working. Ive spoken to Danial Schales a
bit, but dont want to continue hassling him.....

Testing it out with the following line:

chroot /usr/local/lib/gopher-data /bin/gonntp -g comp.sys

the gonntp writes in the log, but fails on the line

connect(NNTPSOCK, $rsockaddr) || die "connect $!";

with the message

connect:  at /bin/gonntp line 33

can anyone shed light onto why i should be getting this message, i reckon
i have everything set up correctly..

Thanks in advance

--
Glyn Simpson, Systems Officer,  //  Voice: +44 (0) 21 414 6575
University of Birmingham        //  Fax:   +44 (0) 21 414 3952
Email: G.Simpson@bham.ac.uk     //  NIC Handle: GS56
Date: Fri, 20 Nov 92 15:41:53 -0800
From: heycke@sumex-aim.stanford.edu (Torsten Heycke)
Original-To: gopher-news@boombox.micro.umn.edu
Subject: New CAMIS Gopher at Stanford University
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: comp.infosystems.gopher
Distribution: comp

This is to announce the CAMIS (Center for Advanced Medical Informatics at
Stanford) gopher at:

Name=CAMIS (Center for Advanced Medical Informatics at Stanford)
Type=1
Path=
Port=70
Host=camis.stanford.edu


Although this gopher will be accessible under the Stanford gopher, we
wouldn't mind if it were given more prominence, i.e., a spot in the North
American gophers list. CAMIS has a national responsibility to disseminate
and further the state of medical computing in much the same way that its
predecessor, SUMEX-AIM (host of the Info-Mac archives*), did. How an
"Artificial Intelligence in Medicine" resource got involved in furthering
AI medical computing by offering Mac games, virus detection programs and
other things is a separate discussion. ;)

The CAMIS gopher features much of the usual and the following:

o  technical report abstracts from the last 10 years from
   the Knowledge Systems Laboratory (which includes the
   Section on Medical Informatics and the Heuristic
   Programming Project)

o  an extensive collection of Mac documentation (including
   Word5, Canvas and other applications)

o  a search test directory, originally designed for testing
   the NeXT's Digital Librarian indexing) that now can be
   used to test the searching capabilities of Don Gilbert's
   WAIS enhancements (in the About the CAMIS Gopher
   directory). It's simple, but especially useful for
   novices like myself to figure out what you will get with
   a particular search on a small, well-defined database.


Torsten Heycke
From: jqj@duff.uoregon.edu (JQ Johnson)
Newsgroups: comp.infosystems.gopher
Subject: Unix gopherd functionality suggestion
Date: 18 Nov 1992 21:21:38 GMT
Organization: University of Oregon Network Services
Distribution: world
NNTP-Posting-Host: duff.uoregon.edu

The current Unix gopherd has a notion of a "security file" that restricts
access to the server based on soure IP address or name.  This is a nice
idea, but is somewhat inflexible.  Also, it currently restricts access
only to gopher items of type '0' or 'h'.  For such items, it returns
the "bummer" string instead of the real data.

In addition to not blocking other file accesses (binary downloads, sounds,
etc., it allows some type 1 directory accesses.  There's a bug here though
in the handling of cache files (if a .cache file exists, then type 1
entries are also blocked, but if no .cache file exists then directory
access is not blocked.  This means that the first time a blocked host
displays a directory it may work, but not the second time).

Before I go off and start hacking on the code, I'd like some advice from
the community as to what features are desirable.  My inclination is that
access checks should be for ANY gopher transaction, not just for file
printing.  However, what should the server return in response to a client
request for something random?

More generally, what security model would a typical Unix gopher server
administrator like to be able to enforce?

-- 
JQ Johnson				Office: 250E Computing Center
Director of Network Services		Internet: jqj@ns.uoregon.edu
Computing Center, Univ. of Oregon	voice:	(503) 346-1746
Eugene, OR  97403-1212			fax: (503) 346-4397
Newsgroups: comp.infosystems.gopher
From: grady@ux1.cso.uiuc.edu (Mike Grady)
Subject: Order of "hit list"/Gopher index on NEXT?
Summary: what is the order of returned list from NEXT index search?
Keywords: gopher index ordering NEXT
Organization: University of Illinois at Urbana
Date: Wed, 18 Nov 1992 00:29:30 GMT


What is the ordering of the returned "hit" list from an index search 
against an index built on the NEXT? I know that on a NEXT one can control
the sort order of this return list, and that one of the options is a simple
weighting algorithm. Does Gopher utilize this?

A second question is the "pager" used to present documents in the Unix
interface. Has any thought been given to having a Gopher pager environment
variable or storing the pager to be used in the .gopherrc file? Hiliting the
hits from an index search only works with "more" or with the appropriate
flags on "less", and one might not want this as one's default Unix PAGER.
-- 
Michael Grady,  Univ. of Illinois Computing & Communications Services Office
Internet: mike-grady@uiuc.edu   phone: (217) 244-1253    fax: (217) 244-7089
Disclaimer: The opinions of CCSO may differ from mine.

-- 
Michael Grady,  Univ. of Illinois Computing & Communications Services Office
Internet: mike-grady@uiuc.edu   phone: (217) 244-1253    fax: (217) 244-7089
Disclaimer: The opinions of CCSO may differ from mine.
From: puetter@pe.chalmers.se (Johan Puetter)
Newsgroups: comp.infosystems.gopher
Subject: Client for SuperTCP?
Date: 18 Nov 92 19:13:28 GMT
Reply-To: puetter@pe.chalmers.se
Organization: Chalmers University of Technology, Gothenburg, SWEDEN

Hi netters!

Does a Gopher client for SuperTCP (Frontier Technologies Corp.) exist?
(SuperTCP is a TCP/IP-stack for MS-Windows (and DOS), it supports the
WinSockAPI...

Any info would be appreciated!

Regards
Johan

--
Johan Puetter, Production Engineering, Chalmers University of Technology,
Sweden. Internet: puetter@pe.chalmers.se
Newsgroups: comp.infosystems.gopher
From: lbroda@s.psych.uiuc.edu (Larry Broda)
Subject: Re: Wais search not working
Organization: UIUC Department of Psychology
Date: Mon, 23 Nov 1992 23:12:18 GMT
Keywords: wais index

lbroda@s.psych.uiuc.edu (Larry Broda) writes:

>Surely I'm making a simple configuration error here: on a simple WAIS
>index search (wais-8-b5, gopher 1.03) I get "Nothing available" though
>I know this is incorrect (a waissearch proves this).

>Furthermore, I tried running gopherd in  Debug mode and the debugging
>output clearly showed that it was finding the correct documents on and
>index search... though there was an odd "dangling file" message.  Here
>is an example of gopherd debug output:

etc, etc...

I found the cause myself.  In the WAIS utility (under ir/) futil.c,
the call to the Sun library routine "access" was not working right.
It was saying the file didn't exist when it did.  I kludged it by
replacing the calls to access with my own routine, but wonder what is
up.

--
Larry Broda
Systems Administration
Department of Psychology,
University of Illinois at Champaign-Urbana
email: lbroda@s.psych.uiuc.edu
Date: Fri, 20 Nov 1992 16:07:51 +1000
Original-To: site-contacts@cscgpo.anu.edu.au, wombat@aarnet.edu.au,
        gopher-news@boombox.micro.umn.edu
From: tony@info.anu.edu.au (Tony Barry)
Subject: ANU Gopher top level reorganisation
Original-Cc: rosalind@library.anu.edu.au (Rosalind Goodwin),
        glynn@library.anu.edu.au (Glynn Shepherd),
        leszek@library.anu.edu.au (Leszek Szychowski),
        claire@library.anu.edu.au (Claire Wehner),
        c.steele@library.anu.edu.au (Colin Steele, University Librarian),
        keith@info.anu.edu.au,
        sueb@library.anu.edu.au (Sue Brudenall, Head of User Services),
        mje@library.anu.edu.au
Newsgroups: comp.infosystems.gopher
Distribution: comp

To site-contacts@anu
   wombat@aarnet
   gopher-news
   

The Australian National University gopher / prototype Campus Information
System will be reoranising on the top level over the next few days.
Hopefully the result will be more rational. It you have links into it from
local servers or booksmarks they may need to be relinked.

Access to the service will still be at info.anu.edu.au port 70

Apologies if this causes any inconvenience.
Apologies for cross posting also.

Regards Tony
______________________________________________________________________
Tony Barry. Head, Centre for Networked Access to Scholarly Information

    Australian National University Library     | fone   +61 6 249 4632
GPO Box 4 Canberra City A.C.T. 2601, AUSTRALIA | phax   +61 6 249 4063
  tony@info.anu.edu.au, Tony_Barry@anu.edu.au  | telex  10717252     
 

Newsgroups: comp.infosystems.gopher
From: lindner@danzig.micro.umn.edu (Paul Lindner)
Subject: Re: Any online student newspapers?
Organization: University of Minnesota, Minneapolis
Date: Sat, 21 Nov 1992 00:26:18 GMT

In <marshall.722122613@stimpy.cs.iastate.edu> marshall@cs.iastate.edu (Bill Marshall) writes:

>Are there any newspapers in gopherspace? I've been talking to the
>journalism folks and I was looking for examples or ideas.

Minnesota Daily, and the Daily Texan come to mind,

gopher on down to gopher.tc.umn.edu, port 70, look in the News folder.

--
 | Paul Lindner | lindner@boombox.micro.umn.edu   | Slipping into madness
 |              | Computer & Information Services | is good for the sake
 | Gophermaster | University of Minnesota         | of comparision.
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /
From: jml4@cus.cam.ac.uk (John Line)
Newsgroups: comp.infosystems.gopher
Subject: Veronica - problem with servers that impose access restrictions
Date: 22 Nov 92 22:13:11 GMT
Organization: U of Cambridge, England

I just tripped over a problem with Veronica, though I'm not sure there's any
simple way to resolve the problem.

Trying to access one of the menu items returned by a Veronica search, I got the
"no off-campus connections" message (though the standard message can be
misleading, since it applies regardless of the scope of the restrictions!).
From the item description (which was not very informative; menu entries often
need the context of at least the associated menu's description...), it may have
been a Clarinet news item, but the problem could arise regardless of the reason
for access restrictions.

If the indexing mechanism includes all menu entries which are accessible to the
indexing site - which is pretty much bound to be what happens - but there are
access controls which prevent access to some (or many/most) other sites, it's
going to lead to a lot of irritation and user complaints about inaccessible
items scattered at random through search results.

I can't see any obvious solution to this, since the security information is
held privately by the gopher servers (and could be altered at any time). If in
reality the problem is mainly servers where access to all items is restricted
to less than the whole world, a solution of sorts would be to exclude all those
sites from indexing - but if all of North America (say) is allowed access,
that's losing potentially-valuable information for a lot of people. And it
doesn't help with auxiliary gateways (go4gw etc.) which may impose access
controls selectively (particular newsgroups, dictionary searches, etc.).

                                John Line
-- 
John Line - Cambridge University Computing Service, Computer Laboratory,
            New Museums Site, Pembroke Street, Cambridge CB2 3QG, ENGLAND.
Internet: jml4@cus.cam.ac.uk  JANET: jml4@uk.ac.cam.cus  Phone: +44 223 334708
Newsgroups: comp.infosystems.gopher
From: dawn@math.wayne.edu (Dawn Endico)
Subject: Re: Veronica: unix gopher hangs?
Reply-To: dawn@math.wayne.edu
Organization: Mathematics Department, Wayne State University
Date: Sat, 21 Nov 1992 02:00:37 GMT



---
:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:
Dawn Endico                                             dawn@math.wayne.edu
Wayne State University                        ... umich!wsu-cs!mathsun!dawn 
Mathematics Department                                        (313)577-3183


Newsgroups: comp.infosystems.gopher
From: marshall@cs.iastate.edu (Bill Marshall)
Subject: Any online student newspapers?
Organization: Iowa State University, Ames IA
Date: Wed, 18 Nov 1992 21:36:53 GMT

Are there any newspapers in gopherspace? I've been talking to the
journalism folks and I was looking for examples or ideas.

Thanks,
Bill

--
			    Bill Marshall
		     Computer Science Department
			Iowa State University
		       marshall@cs.iastate.edu