HDTenEightyP/NetNews huggingface dataset:
From: ccoprmm@phantom.gatech.edu (Michael Mealing)
Newsgroups: comp.infosystems.gopher
Subject: Re: Disclaimer page on client startup...
Date: 14 Dec 1992 21:35:43 -0500
Organization: Office of Information Technoloy, Georgia Tech
NNTP-Posting-Host: oit.gatech.edu

In article <1992Dec14.224353.7718@galileo.cc.rochester.edu> kann@picasso.cc.rochester.edu (Kirk Anne) 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 think you are asking for something the protocol does not support.
>What if there was a standard file that existed in the root directory similar
>to the message that is displayed on some of the 'ftp' sites?

  That's what I was thinking. Kind of like what .about.html does with
hypertext clients (read www).

>On receiving the directory listing, if a particular file name appears,
>display it in a dialog box or on the screen first before displaying the
>file list (minus the particular file).

  I bet something like this could be done easily with Gopher+ but I
can't wait until all the clients are Gopher+ compatible.

  How does Gopher Central feel about this change to the clients?
Have the client monitor the contents of each directory that gets barfed back
to it for a .popup file. If it sees it then it initiates a type 0 connection,
gets the .popup file and puts it in a popup window/regular file display
if that client can't display a popup window. Any objections?

-- 
------------------------------------------------------------------------------
Michael Mealling                     ! Hypermedia WWW, WAIS, and gopher will be
Georgia Institute of Technology      ! here soon via MIME. Your view of the 
Michael.Mealling@oit.gatech.edu      ! internet is about to change completely!
From: lindner@mudhoney.micro.umn.edu (Paul Lindner)
Newsgroups: comp.infosystems.gopher
Subject: Re: dev directory is showing
Date: 19 Dec 92 02:50:17 GMT
Distribution: comp
Organization: University of Minnesota, Minneapolis

In <9212162002.AA09721@info.cren.net> mah@info.cren.net (Marco Hernandez) writes:


>	I recently intalled the UN*X gopher server from UMN (1.1), upgraded
>from the previous version which I was using (1.03).  The problem is my
>/dev directory is now present on though the gopher.  This wasn't the
>case with the previous version.  (I am using my anonymous ftp directory
>for gopher).  I am using a sun 4/330 SUNOS 4.1.1

>	Any clues as to what might have gone wrong (perhaps I missed
>something in the configuration)


Ooops!  The hard coded methods of ignoring files were moved into the
file "gopherd.conf"  You can specify that you want to ignore the dev
directory by putting the following line in gopherd.conf

ignore: dev

Check the new man page gopherd.conf for more info..
--
 | 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: mtm@CAMIS.Stanford.EDU (Mike Macgirvin)
Subject: Re: Problem with 'tstb' menu indexing utilities...
Organization: Stanford University, California, USA
Date: Tue, 15 Dec 1992 01:59:21 GMT

lux@sol.UVic.CA (Michael O'Henly) writes:

>    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...

	The problem is in the way "gopherls" works, especially in
conjunction with "tb". I sent some patches to Gopher central to make
all this stuff work, but they arrived too late to get into 1.1.
	Basically, "gopherls" trips up because everything is taken to
be relative to it's filename argument, and I haven't dug into it, but
if you look through the tsdata file (wherever it is) you'll find
incorrect pathnames like
	./foo/bar/baz/foo/bar/baz

	where the name gets appended onto itself. The solution is to
alter gopherls functionality to allow $gopherdir as an argument to
gopherls, and further arguments are files/directories/whatever to
search relative to $gopherdir. The preceding period on the tsdata file
pathname might also cause problems, and I've fixed that also.
	I'm not at work this week, but I'll save this and try and send
you some patches when I get back. This changes gopherls functionality,
but it's a question of whether or not you want it to work, not how it
functions, IMHO.
	You can also hand edit the tsdata file and fix all the !@#$%
pathnames. 
	Now I -also- have some Bio-WAIS patches to generate WAIS
indexes of all your user-visible gopher names from the .tsdata file.
This is a lot better than grep, and doesn't hit on every sub-path of a
popular name, for instance. Send me mail if you'd like a copy. It
makes for a real nice "local Veronica".


mike



Newsgroups: comp.infosystems.gopher
From: lux@sol.UVic.CA (Michael O'Henly)
Subject: "Nothing available" error - solved (weird)!
Organization: University of Victoria
Date: 13 Dec 92 18:26:50 GMT

    I had one directory on our server that 1.1 would not let me
browse. It would display the directory name, but when I selected it,
I'd get a "nothing available" error. (Links to items below that point
on that particular branch worked properly - I just couldn't browse. )

    After reinstalling 1.03 and removing the .caches, I could browse
in that directory without problems.

    The directory is called "libcat", which a .cap entry expands into
"Library catalogues". 

    The short answer is that after I commented out "ignore=lib" in
gopherd.conf, 1.1 could see that directory. This doesn't strike me as
being the way the "ignore" directive should work...

    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
From: ccoprmm@phantom.gatech.edu (Michael Mealing)
Newsgroups: comp.infosystems.gopher
Subject: Disclaimer page on client startup...
Date: 12 Dec 92 01:59:02 GMT
Article-I.D.: phantom.1gck66INNk3q
Organization: Office of Information Technoloy, Georgia Tech
NNTP-Posting-Host: oit.gatech.edu


  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?

Any comments?

-- 
------------------------------------------------------------------------------
Michael Mealling                     ! Hypermedia WWW, WAIS, and gopher will be
Georgia Institute of Technology      ! here soon via MIME. Your view of the 
Michael.Mealling@oit.gatech.edu      ! internet is about to change completely!
From: mah@info.cren.net (Marco Hernandez)
Subject: dev directory is showing
Original-To: gopher-news@boombox.micro.umn.edu
Date: Wed, 16 Dec 1992 15:02:54 -0500 (EST)
Organization: CREN/BITnet
X-Mailer: ELM [version 2.4 PL3]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 509       
Newsgroups: comp.infosystems.gopher
Distribution: comp


Hello:

	I recently intalled the UN*X gopher server from UMN (1.1), upgraded
from the previous version which I was using (1.03).  The problem is my
/dev directory is now present on though the gopher.  This wasn't the
case with the previous version.  (I am using my anonymous ftp directory
for gopher).  I am using a sun 4/330 SUNOS 4.1.1

	Any clues as to what might have gone wrong (perhaps I missed
something in the configuration)

	Thanks in advance .....

-- 

       Marco Hernandez <mah@info.cren.net>
Newsgroups: comp.infosystems.gopher
From: ullmer@uiuc.edu (Brygg Ullmer)
Subject: Re: Gopher and FTP - is there a better way to do it
Originator: bau50671@uxa.cso.uiuc.edu
Reply-To: ullmer@uiuc.edu
Organization: University of Illinois at Urbana
Date: Sun, 20 Dec 1992 04:58:14 GMT

mitra@pandora.sf.ca.us (Mitra) writes:

>Is anyone else worried about the efficiency of Gopher FTP? 

Yes!  There is definitely something to be said for the simplicity 
of protocol supported by hiding the underlying access mechanisms to 
FTP data sources.  However, when clients have the ability to perform 
direct retrievals themselves (as in the case of the Unix clients) it 
seems to me this definitely benefits all parties concerned.  Can anyone 
think of a reason why FTP retrievals shouldn't be negotiated directly 
by the client, when local support is available?  

>The alternative, of course, would be to have built the ftp protocols
>into the client instead of the server. I'm tempted to hack the client to
>recognize the ftp: string, and go and fetch the file itself, or - at the
>least - fetch it through our local gopher server.

I had something very similar in mind.  While I haven't attacked this
specific problem yet, I was simply planning to investigate a merger of the
FTP access mechanisms from the Unix Gopherd server into the Unix Client, 
with automatic fallback deferral to the specified "host" of the FTP 
gateway upon local access failure.  I haven't checked into this yet, 
though... any obvious problems with this approach?

Brygg Ullmer (ullmer@uiuc.edu)
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.infosystems.gopher
Subject: Re: gopher eval and questions
Date: 19 Dec 1992 03:21:15 GMT
Organization: Msen, Inc. -- Ann Arbor, Michigan
NNTP-Posting-Host: garnet.msen.com
X-Newsreader: TIN [version 1.1 PL8]

Drexel Atkinson CIRT (datkins@hydra.unm.edu) wrote:
: Second, I have just recently begun reading this group, and noted some
: questions on making exec run in gopher.  I would be interested in a complete
: description of the capability of exec and of executing programs from
: gopher.  

I tell people setting up something they think they want to do with 'exec'
to go and get the 'go4gw' code and hide their service behind that.  It
lets you have a tad more flexibility in setting things up, and it also
hides any hint of unix path names from the protocol.

The suggestion to punt the user to a captive telnet session if you want
to engage in some kind of dialog with them is a good one.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB

Newsgroups: comp.infosystems.gopher
From: danj@welchgate.welch.jhu.edu (Dan Jacobson)
Subject: Re: dev directory is showing
Organization: Johns Hopkins Univ. Welch Medical Library
Distribution: comp
Date: Fri, 18 Dec 1992 18:38:10 GMT

In article <9212162002.AA09721@info.cren.net> mah@info.cren.net (Marco Hernandez) writes:
>
>Hello:
>
>	I recently intalled the UN*X gopher server from UMN (1.1), upgraded
>from the previous version which I was using (1.03).  The problem is my
>/dev directory is now present on though the gopher.  This wasn't the
>case with the previous version.  (I am using my anonymous ftp directory
>for gopher).  I am using a sun 4/330 SUNOS 4.1.1
>
>	Any clues as to what might have gone wrong (perhaps I missed
>something in the configuration)
>


When you start up the new gopherd there is a new option (-o) which
allows you to specify an 'options' or 'configuration' file. 

Usage: gopherd [-CDIc] [-u userid] [-U uid] [-s securityfile] [-l logfile] <datadirectory> <port>
   -C  turns caching off
   -D  enables copious debugging info
   -I  enable "inetd" mode
   -c  disable chroot(), use secure open routines instead
   -u  specifies the username for use with -c
   -U  specifies the UID for use with -c
   -o  specifies the name of an options file
   -l  specifies the name of a logfile


A sample file is provide as gopherd.conf with the gopher1.1 distribution.  This
file allows you to set a variety of parameters for your server - one
of which is what files/directories to ignore:

#
# Trash we never want to see (Note that it checks from the end)
#
ignore: lost+found
ignore: lib
ignore: bin
ignore: core
ignore: tmp
ignore: etc
ignore: usr
ignore: hate_mail_to_paul


Thus if you add "ignore: dev" to this list your server should ignore it.


Best of luck,

Dan Jacobson

danj@welchgate.welch.jhu.edu
From: zlsiimw@info.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.infosystems.gopher
Subject: Re: Disclaimer page on client startup...
Date: 18 Dec 92 10:02:23 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

In article <1992Dec14.224353.7718@galileo.cc.rochester.edu>,
kann@picasso.cc.rochester.edu (Kirk Anne) writes:
|> On receiving the directory listing, if a particular file name appears,
|> display it in a dialog box or on the screen first before displaying the
|> file list (minus the particular file).

The same sort of thing could be used as an urgent newsflash type of
message. Potentially quite a useful thing in a gopher being used as a CWIS...
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre
From: zlsiimw@info.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.infosystems.gopher
Subject: Re: Using Gopher for a News Group
Date: 18 Dec 92 11:39:09 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

In article <37902@uflorida.cis.ufl.edu>, fishwick@fish.cis.ufl.edu (Paul
Fishwick) writes:
<stuff deleted, which when I read it I thought "why isn't this guy using
wais?">

|> this a good way, or is there something better? I know nothing of
|> WAIS, unfortunately. If WAIS is the method to use, then I'll be glad
|> to read whatever is necessary.

Use WAIS. It really is quite simple once you've got hold of it and built
it. Look in the gopherd man page for help on building indexes and try
looking at the comp.infosystems.gopher archives on the gopher.micro.umn.edu
server as an example of what you can achieve using WAIS.
Good luck.
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre
From: montjoy@thor.ece.uc.edu (Robert Montjoy)
Subject: Re: FTP with BETA gopher 1.1b4
Organization: University of Cincinnati
Date: Sat, 12 Dec 1992 22:24:35 GMT


Hi...

This problem has gone away in the release version of 1.1.....


-- 
Rob Montjoy                   		- Rob.Montjoy@UC.Edu
Computer Engineer    	      		- montjoy@ucbeh.BITNET
University of Cincinnati      		- montjoy@babbage.ece.uc.edu
Electrical and Computer Engineering	- uunet!uceng!rmontjoy

--  To Save the Earth. The Humans must die.

Newsgroups: comp.infosystems.gopher
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: 'MYIP' variable in PC client
Organization: Mount Holyoke College
Date: Fri, 18 Dec 1992 21:04:37 GMT

In article <1gne54INN1pc@mizar.usc.edu> sharp@mizar.usc.edu (Malcolm Sharp) writes:
>Does anyone know how the 'MYIP' environment variable is used in the PC
>client?  I have tested putting a bogus IP address in my configuration
>and then launching the client without setting 'MYIP' and it works.
>What is the importance of having this set?

Are you sure the IP address you put in your configuration is "bogus"..?
MYIP doesn't /have/ to be set... it's there for configuration convenience.

>My reason for asking this is that I want the client available on the
>LAN I manage and since each user's PC has an IP address, I've been
>experimenting with the set-up.

That's precisely the way I use 'MYIP'.  I set in a '.bat' file that
starts gopher to override the configured value for the IP #.  Works
well.

--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
From: joe@mivax.mc.duke.edu (Joe Hales)
Newsgroups: comp.infosystems.gopher
Subject: gopher server NLM
Date: 15 Dec 92 19:50:00 GMT
Organization: Duke University Medical Center
News-Software: VAX/VMS VNEWS 1.41

This may sound like a dumb idea to all you that know more about TCPIP than I. 
It occurred to me, however, that it ought to be possible to write an NLM
(Netware Loadable Module) that is a gopher server running on top of Novell's
TCPIP NLM.  Please do not confuse difficulty with stupidity of the idea. 
Perhaps the other question to ask is why?  I suppose the best answer I have is
why write it for other platforms if one is enough.  I think another useful
reason is because  it might be possible to write an extension of a pure TCPIP
gopher server NLM that is protocol independent and would permit an IPX client
to communicate with the server and translate all non-local requests into
appropriate TCPIP requests.  This would eliminate the need for each IPX client
to have its own IP address.  I realize there are some directory structure
issues, address issues and of course issues about extensions to gopher
functionality.  Again, please do not confuse difficulty of the idea
with stupidity.

Is anyone working on such an idea?  Is anyone interested?  Let me know

Joe Hales
Division of Medical Informatics
Duke University Medical Center
Newsgroups: comp.infosystems.gopher
From: JONESD@kcgl1.eng.ohio-state.edu (David Jones)
Subject: VMS gopher client update (revision d)
Organization: The Ohio State University
Date: Wed, 16 Dec 1992 19:57:22 GMT

I've added directory caching, a much requested feature, to the gopher client
I distribute through anonymous FTP on job.acs.ohio-state.edu.  With directory
caching, backtracking up the menu heirarchy is much snappier.

The distribution is a VMSHARE file, which when invoked as a command procedure
upacks itself into source files.

In case you haven't been following the changes that I've been making to
the boombox 0.6 version, here is an extract from the AAAREADME.TXT

----------------------------------------------------------------------------
Items changed (13-SEP-1992):

    Telnet command changed to UCX format (i.e. "telnet host port" instead of
     "TELNET/PORT=port host").

    Fixed setsockopt() calls in gopher.c to work around bug in UCX 2.0.
    Conditionally compile setscokopt() calls that Wollongong doesn't
    support.

    Created wollongong.opt options file.

    Modified screen management to set scroll region based on size of
    screen (supports 48-line DECterms now).

    Perform cannonical interpretation of control-Z (e.g. exit program).

    Fixed showfile()'s failure to close the connection.

    Optimize reads done by readline() and readfield().  Character-at-a-time
    I/O is horribly inefficient with UCX (2K QIOs/sec when receiving text).

    Fixed bug in feed_a_gopher/feed_gophers that was causing infinite
    loops.

    Fixed bug in querying index servers (wasn't sending search string).

Items changed to 'c' release (OCT-1992).

    Increased storage for selector string.  The newer gopher servers do
    not follow the convention of keeping selector strings less than 255
    characters and this was causing the client to crash.

    Cache address translations to speed up connect times.

    Minor optimization in MANAGER.C to make few SMG$PUT_CHARS calls.

    Make connect fails not abort the program.

    Added support for special 'background' operations, whereby gopher is
    run as a sub-process which executes pageer and telnet commands by
    attaching back to the parent rather than spawning a new process each
    time.  The new file GOPHER_BG.COM is used to run gopher in background
    mode.  If you run the gopher image as a normal foreign command,
    it reverts to it's previous method (spawning).

Items changed to 'd' release (DEC-1992).

   Cache directory listings.  Save up to the last 20 directories retrieved
   and uses the cached entry when you go back to a directory instead of
   re-retrieving it.

   Hopefully improved multinet support.
----------------------------------------------------------------------------

David L. Jones               |      Phone:    (614) 292-6929
Ohio State Unviversity       |      Internet:
1971 Neil Ave. Rm. 406       |               jonesd@kcgl1.eng.ohio-state.edu
Columbus, OH 43210           |               jones-d@eng.ohio-state.edu

Disclaimer: A repudiation of a claim.
Newsgroups: comp.infosystems.gopher
From: gilbertd@sunflower.bio.indiana.edu (Don Gilbert)
Subject: 1.1 patches for IUBio WAIS (was Re: 1.1 compile errors on NeXT)
Organization: Biology, Indiana University - Bloomington
Date: Sat, 12 Dec 1992 14:13:05 GMT

Here are a couple of small patches to gopher1.1 to use the IUBio WAIS
modifications correctly.  

Patch 1: I recommend NOT using the -DBIO compile switch unless you 
need symbols within words in WAIS indexing and searching.  The need for 
this is probably limited to some science data.  HOWEVER, you must
compile WAIS and Gopher with the same -DBIO or NOT -DBIO setting.

Patch 2: Re-include the WAIS header cutil.h (if using -DBIO) in
Waisindex.c.


diff -bwcr gopher1.1/Makefile.config gobio11/Makefile.config
***************
*** 99,106 ****
  #     (Note you'll need to add -lkvm in SERVERLIBS)  Note also that this has
  #     only been tested under SunOS 4.1.1
  #
! # Add -DBIO if you're using Don Gilbert's modified wais8b5 that supports
! #     boolean and phrase searching.  The source can be gotten from:
  #
  #      ftp.bio.indiana.edu
  #
--- 100,112 ----
  #     (Note you'll need to add -lkvm in SERVERLIBS)  Note also that this has
  #     only been tested under SunOS 4.1.1
  #
! # Add -DBIO if you're using the biology portion of Don Gilbert's modified
! #     wais8b5 that supports boolean and phrase searching.
! #     PLEASE NOTE: the -DBIO option is NOT needed nor recommended for use
! #     of the boolean and phrase searching portion of this modified wais,
! #     just the symbol searching.  But, you must compile wais and gopher with
! #     the same option setting (-DBIO or NOT).
! #     The source can be gotten from:
  #
  #      ftp.bio.indiana.edu
  #
***************
*** 113,119 ****
  #       admin.viccol.edu.au
  #       pub/dl/describe-1.8.tar.Z  or higher...
  #
! SERVEROPTS    = -DBIO #-DDL # -DLOADRESTRICT
  DLPATH                = /home/mudhoney/lindner/src/describe
  #DLOBJS               = $(DLPATH)/getdesc.o $(DLPATH)/enddesc.o

--- 119,125 ----
  #       admin.viccol.edu.au
  #       pub/dl/describe-1.8.tar.Z  or higher...
  #
! SERVEROPTS    = #-DBIO #-DDL # -DLOADRESTRICT
  DLPATH                = /home/mudhoney/lindner/src/describe
  #DLOBJS               = $(DLPATH)/getdesc.o $(DLPATH)/enddesc.o


diff -bwcr gopher1.1/gopherd/Waisindex.c gobio11/gopherd/Waisindex.c
*** gopher1.1/gopherd/Waisindex.c       Thu Dec 10 18:17:46 1992
--- gobio11/gopherd/Waisindex.c Sat Dec 12 08:26:44 1992
***************
*** 48,53 ****
--- 48,54 ----
  #include "../ir/irsearch.h"
  #include "../ir/docid.h"
  #include "../ir/irtfiles.h"
+ #include "../ir/cutil.h"   /* dgg fix for -DBIO wais needs */
  #include <math.h>


-- 
Don Gilbert                                     gilbert@bio.indiana.edu
biocomputing office, biology dept., indiana univ., bloomington, in 47405
Newsgroups: comp.infosystems.gopher