HDTenEightyP/NetNews huggingface dataset:
From: mpm@boombox.micro.umn.edu (Mark P. McCahill)
Newsgroups: comp.infosystems.gopher
Subject: Re: Gopher+ Considered Harmful
Date: 14 Dec 92 15:28:10 GMT
Article-I.D.: news2.1992Dec14.152810.28054
     <MARCA.92Dec11073613@wintermute.ncsa.uiuc.edu> <billy.724093293@sol>
Organization: Universty of Minnesota
X-Useragent: Nuntius v1.1

>In article <MARCA.92Dec11073613@wintermute.ncsa.uiuc.edu> Marc
Andreessen, marca@ncsa.uiuc.edu writes:
>What are the standards by which a networked information system can be
>judged to be ``past critical mass''?
>
>Obviously gopher is past critical mass so far as campus-wide
>information servers go, but that's a very minor part of the
>information processing realm -- a fact that kills your general
>argument.  Right?  Or is your statement implicitly qualified and I'm
>just not noticing it?

I looked at the log on our main gopher server and saw that between
November 2 
and December 7 there were 35,135 different machines that contacted our
main 
server, and there were 1,006,275 requests (transactions) done by the
server.
About 75% of this is from outside the University of Minnesota. I don't
know if 
this qualifies as critical mass though :-).

-----------------------------------------------------------------------
-----
 Mark P. McCahill                                       Gopherspace
Engineer
 mpm@boombox.micro.umn.edu
 612 625 1300 (voice)                         Computer & Information
Systems
 612 625 6817 (fax)                                  University of
Minnesota
-----------------------------------------------------------------------
-----
      "...This Snow Crash thing - is it a virus, a drug, or a religion?"
       Juanita shrugs. "What's the difference?"
-----------------------------------------------------------------------
-----
Newsgroups: comp.infosystems.gopher
From: jpw@sansfoy.lib.virginia.edu (John Price-Wilkin)
Subject: titles for WAIS-indexed files
Organization: University of Virginia
Date: Mon, 14 Dec 1992 15:13:56 GMT

The new release of the server gets titles from a .cap directory if one  
exists.  However, I've got cases where I use the .cap directory only for  
some resources (primary file; archive files) and index the file as "-t  
para."  In this case, the server gets the name from the .cap directory and  
provides users with the name of the primary file rather than the first  
line of each paragraph.  Is there a way to have my cake and eat it too, or  
do I have to get rid of .cap directories in all cases where I'm indexing  
for "-t para"?
Newsgroups: comp.infosystems.gopher
From: bdesimon@uga.cc.uga.edu (Bert DeSimone)
Subject: Phrase Searching Again
Organization: UCNS
Date: Wed, 16 Dec 1992 14:03:21 GMT

Well, I guess it must be me.  Having made gopher 1.1 using Don Gilbert's WAIS
mods, I can still do boolean and partial word ... but no pharase searching.
Paths to the indexes are done with Path=7/... (as opposed to Path=waissrc:/..).
Also, I have removed the -DBIO option (both places) and included it (both 
places), with no related differences in result.

In fact, whenever I enclose any search term -- even a single term -- in
quotes ("term" or "term1 term2") I get "No files Available ..." and a core
file and index.query.lock file where my indexes reside.

I am compiling using cc on Sun/OS 4.1.1.  BTW, I can still search the indexes
using waisserver and waissearch, and all is fine.

Hints, tips, and allegations appreciated.
From: M.Houlahan@uws.edu.au (Michael Houlahan)
Subject: Veronica
Keywords: veronica gopher
Organization: Computer Services, University of Western Sydney, Nepean
Date: Tue, 15 Dec 1992 06:24:22 GMT

I've heard a lot about veronica but can't find a thing about it in archie.

Where do ya get it !!
Date: Wed, 16 Dec 92 18:10:42 +0100
From: whna@ciba-geigy.ch (Heinz Naef)
Original-To: firewalls@greatcircle.com, gopher-news@boombox.micro.umn.edu
Subject: gopher proxy
Original-Cc: a-tuchman@uiuc.edu, gopher@boombox.micro.umn.edu, wdbu@ciba-geigy.ch,
        whna@ciba-geigy.ch, wreb@ciba-geigy.ch
Newsgroups: comp.infosystems.gopher
Distribution: comp

We have an experimental gopher service in our firewalled environment up
and running. It consists of a Gopher proxy server running on an Internet
relay host and a curses gopher client with minimal changes.

As required by the fundamental design of Gopher, the Gopher proxy server
is completely stateless: it is launched by inetd for each Gopher object to
be dealt with, connects to the ultimate Gopher server, copies the retrieved
information back to the client and then ends.

The following Gopher object types are currently supported:

 - Directory
 - File, document
 - Wide Area Information Service (WAIS) indexed document
 - Telnet (via itelnet)

The following Gopher object types are not yet supported:

 - CSO nameserver query
 - Tn3270 access

We did the development in Version 1.03 of the UNIX Gopher distribution.

As time permits, we will incorporate similar changes into the X Gopher
client (Version 1.2).

If there is enough interest, we may, after implementing the remaining
object types in the proxy server, think about getting in touch with the
Gopher developers and have them incorporate the changes and additions to
an upcoming release.

Please send me a short message if you are interested. Please don't send
the message to the firewalls mailing list, send it to hn@chsun.chuug.ch.

Regards,
Heinz Naef, hn@chsun.chuug.ch
David Buehler
Newsgroups: comp.infosystems.gopher
From: Albert-Lunde@nwu.edu (Albert Lunde)
Subject: Re: Disclaimer page on client startup...
Followup-To: comp.infosystems.gopher
Originator: lunde@casbah.acns.nwu.edu
Reply-To: Albert-Lunde@nwu.edu (Albert Lunde)
Organization: Northwestern University, Evanston, Illinois, USA
Date: Mon, 14 Dec 1992 17:42:53 GMT

In article <1gck66INNk3q@phantom.gatech.edu> ccoprmm@phantom.gatech.edu (Michael Mealing) writes:
>  With the pervasivness of lawsuits it has been recommended that if
>we setup a CWIS with gopher that ALL clients have a disclaimer page
>appear before any connection to the system. I know this can be done
>easily with shell scripts and other such stuff but how hard would
>it be for all client programmers to add a disclaimer page to the
>command line? Something like:
>gopher -disc /usr/local/etc/disclaimer.txt gopher.gatech.edu 70
>
>  I can do this in about 5 minutes on the UNIX implementation but I 
>was wondering if I could talk the other implementors into doing it?

I think you are asking for something the protocol does not support.

Since there is no connection between client and server between
transactions it is pretty hard for the server to tell what the
start-up is.

Yes, all the clients used at your site could be modified to
post a message at start-up, but folks reading with standard gopher
clients at another site wouldn't see it.

Putting a disclaimer at the top level of the server (or if you
are really paranoid, in every directory or appended to text files)
would get your message to more people.  It might be possible
to hack the UNIX server to stick in disclaimers for you, though
be careful about sticking your disclaimer on material
linked from someone else's server.

-- 
    Albert Lunde                      Albert-Lunde@nwu.edu
Newsgroups: comp.infosystems.gopher
From: MAHE@YaleVM.YCC.Yale.Edu
Subject: Yale Gopher servers
Organization: Yale University
Date: Wed, 16 Dec 92 14:58:58 EST

Good news - the Yale University Gopher server is progressing from Invisible
to officially Experimental :-).  It includes all the data from
Enterprise, our older cwis based on CUINFO, and of course
many Internet resources.
 
Please be sure to use the alias if you point to it, because it's very likely
to move in the next few months.
 
Name=YaleInfo
Type=1
Host=gopher.yale.edu
Port=70
 
Highlights include the list of Internet Libraries, previously announced on
this list, at Path=1/Libraries.  A new directory of Internet-wide usefulness
is the one at Path=1/Enterprise/Academic/Forestry, for the Ecological
Data Exchange at Hubbard Brooks NH, an offshoot of the LTER (Long-Term
Ecological Research) project of the National Science Foundation.  We
apologize for the fact that the test version of the Forestry directory
was announced before getting to its final resting place, and please
correct your listing if you were already pointing to it.
 
Marie-Christine
mahe-marie-christine@yale.edu
gophadmi@gopher.yale.edu
From: mathog@seqvax.caltech.edu (David Mathog)
Newsgroups: comp.infosystems.gopher
Subject: All local WAIS indices are "Unknown index type"
Date: 15 Dec 1992 16:20 PST
Organization: Division of Biolgy, CALTECH
Distribution: usa
NNTP-Posting-Host: seqvax.bio.caltech.edu
News-Software: VAX/VMS VNEWS 1.41    

Gopher 1.03, SunOS 4.1.1, D. Gilbert's WAIS modifications.

Even though my Gopher server seems to be working ok it will not search local
WAIS indices.  These show up correctly as WAIS searches, but when a query is
made the client shows a "Server Error: Unknown index type". swais has no
problem with these indices.  I've tried every variant on the path name I could
think of in the .Link files and nothing works.  The error message is the same
whether or not the files are inside the gopher server directory tree. 

The only work around that I've come up with so far is to run a WAISserver
locally and to link to these indices as remote WAIS sources.  Very inelegant.

Would one of you Gopher tamers please share the appropriate trick?

Thanks,

David Mathog
mathog@seqvax.caltech.edu
Manager, sequence analysis facility, biology division, Caltech 
Newsgroups: comp.infosystems.gopher
From: lux@sol.UVic.CA (Michael O'Henly)
Subject: NeXT-and-WAIS searching - it works!
Organization: University of Victoria
Date: 13 Dec 92 18:55:59 GMT

    Thanks to Don Gilbert for pointing out that the -DBIO switch
shouldn't be used to compile the 1.1 gopher server unless it was also
used to compile the IUBIO WAIS. Since I don't need the features that
-DBIO adds, I recompiled WAIS and gopher without it and now everything
works beautifully.

    This would appear to answer my earlier question about whether
NeXTstep was "supported" or "required". I'm running NS2.2 and have
encountered no problems.

    Michael
-- 
           Michael O'Henly |     o   | 604-721-7623 (604-721-8215 fax)
    Library Systems Office |  --/--  | LUX@UVVM.BITNET
    University of Victoria |  __\    | lux@sol.UVic.CA
    Victoria, B.C., Canada |     \   | mohenly@malahat.Library.UVic.CA
Newsgroups: comp.infosystems.gopher
Subject: Re: What is exec good for?
From: pmurray@watson.lib.muohio.edu (Peter Murray)
Date: 14 Dec 92 11:15:35 -0500
Organization: Miami University Libraries
X-Newsreader: TIN [version 1.1 PL6]

Stew Ellis (ellis@nova.gmi.edu) wrote:
: I have tried the following
: #
: Name=GMI library catalog, non-telnet
: Type=0
: Port=+
: Host=+
: Path=exec:" ":/bin/falcon
: 
: where /bin is a subdirectory of my gopher datadir and falcon is a shell
: script that does the rlogin -l stuff.  It is a direct copy of the script
: that is in the /usr/local/bin/ directory for interactive use from the shell
: prompt.  It does not give any errors, but exits without putting anything on
: gopher's stdout.  This is an improvement.  Until I loaded it referenced to
: the root of datadir, I got error messages.  Why doesn't it check outside the
: datadir since I am running -c?
: 
: Is this mechanism even the proper one to be looking at to do what I want?
: Is there something I am leaving out?

This will not work.  The "rlogin" will be executed on the SERVER side
of Gopher, not on the CLIENT side.  Gopher does not include a way to
send an arbitrary, interactive stream of data to the client, because on
some clients (such as the Macintosh Hypercard, X-windows, etc) this
arbitrary stream of data cannot be interpreted.

To do what you want, you'll have to modify the CLIENT software to
handle the rlogin session.  I've done some work with this, but the
code isn't very clean, so I hesitate to distribute it.


Peter
--
Peter Murray, Library Systems Manager        pmurray@watson.lib.muohio.edu
King Library Technical Support                      pemurray@miavx1.bitnet
Miami University, Oxford, Ohio                              W:513/529-2884
Newsgroups: comp.infosystems.gopher
From: tuchman@ux1.cso.uiuc.edu (Allan Tuchman)
Subject: Re: Allowing clients to hop into the middle of a Gopher tree
Keywords: client hierarchy microlabs
Organization: University of Illinois at Urbana
Date: Thu, 17 Dec 1992 21:48:26 GMT

In <1992Dec16.214459.25297@msuinfo.cl.msu.edu> rww@mugwump.cl.msu.edu (Richard W. Wiggins) writes:

>Has anyone modified a client to allow it to fire up a 
>Gopher session jumping into the middle of a tree?  Ie, rather
>than starting up with the null selector string to get
>the root menu, the client knows the string for a particular
>item, and it fires up and sends that string to begin with?
>This could be in a config file, or an optional command parameter
>(or both).

Rich, 

Xgopher has a resource called rootPath that can be set in your
defaults file or (slightly awkwardly) on the command line.  An
alias would take care of the awkward syntax.

Also, bookmarks in Xgopher would allow you to get anywhere with
a single action if you have your desired "root" in your .gopherrc
file.

-Allan
-- 
-Allan Tuchman    University of Illinois at Urbana-Champaign (UIUC)
		  Computing and Communications Services Office (CCSO)
		  phone: (217) 244-0048
a-tuchman@uiuc.edu   -or-  tuchman@ux1.cso.uiuc.edu
From: zlsiimw@info.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.infosystems.gopher
Subject: Re: Xgopher 1.2 under Ultrix for X11R5
Date: 15 Dec 92 12:52:37 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

In article <WALSH.92Dec11085757@ibis.cs.umass.edu>, walsh@cs.umass.edu (Norman
Walsh) writes:
|> I hope this hasn't already been hashed out (well, actually, maybe I hope
|> it has ;-).  In any event, I've just compiled Xgopher 1.2 under Ultrix
|> for X11R5 on a DECstation and I get the following errors when I fire it
|> up...
|> 
|> Warning: Cannot convert string "other" to type Widget
|> Warning: Actions not found: unselectAll
|> Warning: Actions not found: unselectAll
|> Warning: Actions not found: unselectAll
|> 
|> The top row of buttons contains only the "Quit" button.  And a quick perusal
|> of the source leads me to believe that it should also contain "Help" and
|> "Other" buttons at the very least.
|> 
|> X11 isn't my forte, does anyone have any suggestions?

It sounds like you've still got the Xgopher app-defaults file from the previous
version hanging about - you'll need to get rid of this and replace it with 
the new one before it will work properly.
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre
Newsgroups: comp.infosystems.gopher
From: ruck@delta.ee.ufl.edu (John R Ruckstuhl Jr)
Subject: Xgopher 1.2 w/OW3 problem + solution
Organization: EE Dept at UF
Date: Sat, 12 Dec 92 03:33:26 GMT


I posted:

>Sun's OpenWindows 3 xnews, with bundled OW3 olwm, and I get
>
>The Xgopher Application Resources file is not available.
>The file 'Xgopher' should be stored in the directory
>/usr/local/X11R5/lib/X11/app-defaults.
>It can also be located in your own app-defaults directory, or the contents
>can be copied to one of your other X windows resources files.
>
>xgopher cannot continue without this file.
>
>I did the things obvious to me:
>Make sure LD_LIBRARY_PATH is set to /usr/local/X11R5/lib, and exported, 
>before running the xgopher client,
>Diddle with the XFILESEARCHPATH, ...


Allan Tuchman had said it in a followup to someone else earlier:
> or you have possibly set your XFILESEARCHPATH or XUSERFILESEARCH
> path values differently.

The startup routine for OW3 shipped by Sun sets XFILESEARCHPATH.

As I said, I diddled with XFILESEARCHPATH, but I thought !directories!
go on that path.  :(  
It turns out the !specific file! should go on that path (or some string
that expands to the specific file when ??Xt routines?? grok it).

One easy solution for me, in a Bourne-ish shell, is simply:
    (unset XFILESEARCHPATH; xgopher)
csh users probably have to use unsetenv to get the same result?

Frank Peters (fwp@CC.MsState.Edu) suggested adding
    /usr/local/X11R5/lib/X11/%T/%N%S
to XFILESEARCHPATH, which works for me also and is perhaps the more
general and better solution.


I must say that the error message printed:
    The Xgopher Application Resources file is not available.
    The file 'Xgopher' should be stored in the directory
    /usr/local/X11R5/lib/X11/app-defaults.
confuses some of us novices, because, dangit, the file !is! there.

Thanks to Frank Peters, and anyone else whose reply is in transit.
Apologies to Allan Tuchman, for not realizing he identified the problem
already.

Regards,
ruck
-- 
John R. Ruckstuhl, Jr.                  ruck@alpha.ee.ufl.edu
Dept of Electrical Engineering          ruck@cis.ufl.edu, uflorida!ruck
University of Florida                   ruck%sphere@cis.ufl.edu, sphere!ruck
Newsgroups: comp.infosystems.gopher
From: lux@sol.UVic.CA (Michael O'Henly)
Subject: Problem with 'tstb' menu indexing utilities...
Organization: University of Victoria
Date: 11 Dec 92 22:16:53 GMT

    If you're using the 'tstb' utilities (version 1.1), could you
please look at this configuration and tell me what I'm doing wrong? I
get "nothing available" for every search...

      -	/is/gd is where our server lives.

      - I've installed the ts script in /is/gd. Execute bits are set.

      -	I've made a /is/gd/.cap/ts file with the appropriate info...
	
		Name=Search menu items
		Type=7
		Path=7/ts

      -	I've made a /is/gd/.ts subdir and installed tsc, tsp, and tb.

      -	I've compiled tsc.c. to tsc. The ts script calls tsc.

      -	I've run the tb command manually from /is/gd directory, like
	so...
		./.ts/tb /is/gd/

	(I find that if I don't give the gopherhome directory as a
	parameter, tb wants to index the whole system...)

      - tb produces the /is/gd/.ts/tsdata file. (The docs refer to a
	.tsdata file but nowhere in this whole process do I see
	anything with this name.)

      - When I run the ts script from the command line, it seems to be
	working. If I say...

		ts victoria 

	...it returns all the items containing "victoria". But when I
	call it from within gopher, I get "nothing available".

    If it makes any difference, I'm running this on a NeXT with the
server compiled for NeXT searching...

    Michael
-- 
           Michael O'Henly |     o   | 604-721-7623 (604-721-8215 fax)
    Library Systems Office |  --/--  | LUX@UVVM.BITNET
    University of Victoria |  __\    | lux@sol.UVic.CA
    Victoria, B.C., Canada |     \   | mohenly@malahat.Library.UVic.CA
Newsgroups: comp.infosystems.gopher
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: MVS Gopher Server Abends
Organization: Draper Laboratory
Date: Wed, 16 Dec 1992 20:59:00 GMT

Not to alarm anybody, but I've noticed that when running REXX execs
off the MVS Gopher server, the thing gets an 0C4 in an internal
TSO REXX routine whenever two people try to connect to Gopher to do
a REXX-driven function.

This is an inherent problem with anything that runs multiple
parallel tasks and sets up TSO REXX environments.  In our case the
Gopher server is running under IKJEFT01 (the MVS/TSO TMP) so that
the REXX execs can issue TSO commands (in batch mode, of course).

I thought that eliminating XPROC from REXX execs written to run as
Gopher "shell scripts" would solve the problem, but apparently
that is not enough.  I know that there are PTF's to MVS that fix
problems with TSO multitasking applications, but we have never
applied them since they have huge prerequisite-in-error chains.

Anyway, be warned.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Newsgroups: comp.infosystems.gopher
From: billy@sol.acs.unt.edu (Billy Barron - VAX/UNIX Systems Manager)
Subject: E-journals at UNT - IMPORTANT! Change your links
Keywords: journals
Organization: University of North Texas
Date: Fri, 11 Dec 1992 21:44:20 GMT

If you have a link pointed at the "Newsletters & Journals" entry at UNT
or want a link to a somewhat complete electronic journal tree in Gopher,
please read the following.  If not, then go on to the next message.

For CICNet sites in the Midwest, please make your electronic journal
pointer to the following link file:

    Name=Electronic Journals
    Type=1
    Port=70
    Path=1/e-serials
    Host=gopher.cic.net

For others, you can make your new link file:

    Name=Newsletters & Journals
    Type=1
    Port=70
    Path=1/Documents & Databases/Newsletters & Journals
    Host=gopher.unt.edu

The old access at UNT will remain valid until sometime after Xmas break
when I will remove it.  There are (or will be very soon - this weekend)
crosslinks between the two archives because they are not identical at this
point.

Billy Barron
billy@unt.edu
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.infosystems.gopher
Subject: 'comp.infosystems.gopher.announce' newsgroup
Date: 19 Dec 1992 03:17:13 GMT
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: garnet.msen.com
X-Newsreader: TIN [version 1.1 PL8]

I would like to start the ball rolling on a 'comp.infosystems.gopher.announce'
newsgroup.  This would be a moderated group for announcenets of new
servers, new clients, changes to any servers, any useful pieces
of peoples gopher subtrees that they want to advertise etc.

The existing gopher newsgroup would continue, & depending on the moderators
points of view would either cross-post all .announce articles into the
main group or keep it totally separate.

I will volunteer to count the votes.  (I have vote counting mailboxes all
set up.)  What I need is
- a volunteer to issue the formal 'Request for Discussion', some time
  after the holidays
- a volunteer to issue the formal 'Call for Votes', some time in late
  January
- a volunteer or set of volunteers to actually do the day to day moderation
  and postings to the group, and to set up the mail-to-news gateway so
  that people can subscribe to the gopher-announce list.

Actually running this group will get you a lot of people sending you
updates about new things all of the time, so you will be the first to
know what all is new out there.  It will be work and take some time.
I suspect that it will pay off big time.  If I had a few (dozen)
spare hours a week I'd take it on myself, ha ha.  But I will count
the votes and help push things through.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB
From: zlsiimw@info.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.infosystems.gopher
Subject: Public access xgopher account
Date: 18 Dec 92 11:47:42 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

I'm thinking of setting up a public access login account where users
will be presented with xgopher (I've already set one up for the curses
version). Is this a good idea? Has anyone else tried it and had problems?
Has anyone else tried it and everything's gone swimmingly?
Grateful for any comments received.
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre