HDTenEightyP/NetNews huggingface dataset:
From: bolwidt@fwi.uva.nl (Erwin Bolwidt)
Subject: Recursive queries via gopher server
Organization: FWI, University of Amsterdam
Date: Thu, 24 Dec 1992 02:07:15 GMT

Does the gopher protocol allow for servers that recursively get the 
information from other server, so that the client can be behind a firewall?
I didn't find anything about it in the docs, but it could be a FAQ, so
i'm very glad if someone could just provide me with a pointer.
Merry X-mas!

Erwin Bolwidt
-- 
Erwin Bolwidt                     "Yes!"                  `O-O'
<erwin @ mars.let.uva.nl>                                 (_U_)

Newsgroups: comp.infosystems.gopher,alt.gopher
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: PC gopher client and graphics in gophers
Keywords: PC gopher graphics
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Wed, 23 Dec 1992 01:22:16 GMT

After working a couple of weeks with gopher on UNIX, setting up a 1.03
server and client and experimenting with the 1.1 curses client, then getting
xgopher 1.2 working from a Sun server running the clients to a bunch of
clients running different X servers, I discovered the UIUC weather gopher
with its treasure trove of weather graphics.  I decided it was about time to
try a PC client and was shocked yesterday to discover that it did not do
anything constructive with the weather gifs at uiuc.  Is anyone working on
getting graphics support in a PC gopher client?  Has anybody been waiting
for someone to ask?  I am a recovering DOS junky, so I cannot go near PC's,
but for those people who haven't got access to X, it would be really nice to
let them look at the pretty campus pictures I want to put in the CWIS.  Even
roundabout ways (PC Hytelnet?) would be given consideration.


Stew

--
--                                                        ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /
Xref: sparky comp.infosystems.gopher:1720 comp.infosystems.wais:758
From: sridhar@asuvax.eas.asu.edu (Sridhar Venkataraman )
Newsgroups: comp.infosystems.gopher,comp.infosystems.wais
Subject: Re: "About" information for WAIS servers via Gopher
Date: 22 Dec 92 17:18:54 GMT
Organization: Arizona State University, Tempe AZ

riddle@is.rice.edu (Prentiss Riddle) writes:

)There may actually be a way to do this without extending the protocol,
)by making a minor change in the gopher clients.
)
)When I use a WAIS client (e.g. xwaisq) and send the WAIS server a null
)search string, I sometimes get back two items:
)
)    1000  9.5K Information on database: Aesop-Fables
)    1000 48.5K Catalog for database: Aesop-Fables

Actually the same information should be returned if you send a '?'.

Sridhar.
--
Sridhar Venkataraman			sridhar@asuvax.eas.asu.edu
Newsgroups: comp.infosystems.gopher
From: lindner@mudhoney.micro.umn.edu (Paul Lindner)
Subject: Re: NeXT gopher problem
Organization: University of Minnesota, Minneapolis
Distribution: usa
Date: Mon, 28 Dec 1992 16:19:11 GMT

In <85865@ut-emx.uucp> mikael@scout.utexas.edu (Mikael Behrens) writes:

>Hi

>I've been playing around with Gopher version 1.12 on my NeXTstation and  
>have a problem.  When I click on a courier font file which is actually a  
>telnet session, the terminal application is not fired up and I get the  
>following messages in the console:

>Gopher: No such file or directory
>Gopher: Execve error code=-1.

>In the preferences I have Terminal picked and not Stuart.  I'm running  
>NeXTStep 3.0.

1.12 is broken under NextStep 3.0.  Use stewart, or get the 1.3
pre-release of the NeXT gopher client..
--
 | 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: gwatts@fnalo.fnal.gov
Subject: (Q) XGopher 1.2 WAIS gate and ftp image files
Organization: Fermi National Accelerator Lab
Date: Tue, 22 Dec 1992 11:40:50 GMT
X-Posted-From: fnalo.fnal.gov
NNTP-Posting-Host: sol.ctr.columbia.edu

Hi all,
  I'm fairly new to this, so these may be FAQs (I've been reading for a week
and havn't seen/heard of FAQs).

  I've compiled the XGopher 1.2 client.  Nothing could be simpler.  Thanks
and kudos to Allan Tuchman.  Now, the questions.  

1) Image files from ftp.  I can't fool gopher into displaying these thing.
I can path to a number of directories that have gif files via
the ftp interface.  The files are in binary format and are gifs (I can use
the same xloadimage command that xgopher does to display these images), but,
of course, they don't show up as gifs in xgopher.  So, for experiment, I tried
to use the Enter Gopher Item menu item (in "Other Commands") and set file type
to "I" and filled in the rest of the info (I got the rest of the info from the
Info about selection" button) and clicked "process".  xloadimage fails with
unknown image type.  My guess is the ftp that xgopher used was not binary. :(
Is there a way to force it?  Better yet, is there a way to display those
images with out all that work (click the left mouse button, get a pop-up
menu with "Get as Image" and "Get as Text" and "Get as Directory", etc. etc.)?

2) The WAIS interface.  All the entries show up as <idx>, and searching does
nothing.  I've seen this on the UIUC gopher (host: mudhoney.micro.umn.edu,
name: WAIS Based Information, type: 1 (directory), Port: 70, Path: 1/WAISes),
which can be found by going to harpoon.cso.uiuc.edu gopher, in the "Other
Gopher and Information Servers" subdirectory there is the WAIS connection.  If
I click on "Everything" in the WAIS Based Information directory, I get a
long list of files all with <idx> in front of them.  Now, in a README it sais
that there was a minor change in the protocal for gopher -- does xgopher 1.2
have this minor change?

	Thanks!

		Cheers,
			Gordon.

Newsgroups: comp.infosystems.gopher
From: raman@cs.cornell.edu (T. V. Raman)
Subject: Re: gopher 1.1 client dumps core erratically.
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Sun, 3 Jan 1993 13:50:12 GMT

ellis@nova.gmi.edu (Stew Ellis) writes:

>I would really like to update to the 1.1 client from 1.03, but it rather
>erratically dumps core on a Segmentation Fault.  It may work without
>problems for 10 times and then dump every time for the next 10.

Yes, I installed gopher1.1 on a SUN4 ipc running SUNON 4.1.1  and am
having the same problem. starting up gopher with the bookmark file or
by specifying a host and port on the command line works reliably but
just starting up gopher dumps core erratically. I suspected that the
client was dumping core because  the root gopher server was running an
older version, but I may be wrong.

I compiled gopher as is, ie using standard CC and just redefined the
necessary things in conf.h and Makefile.conf

--Raman
>I have compiled it on a Sun 4/490, SunOS 4.1.2, using the bundled C
>compiler, as well as GCC 2.3.1.  The behavior is identical.  The only
>non-standard think I may have done in the Makefile is select -DLOADRESTRICT
>or whatever it is called.  

>I have been running 1.03 for a month without one observed core dump.  

>Has anyone else observed this?  Any suggestions what may be causing it?  I
>have a suspicion it may be occurring during host lookup.  The Sun is using a
>totally stock Sun DNS over NIS configuration.  Please note that 1.03 works
>flawlessly, as well as xgopher 1.2.

>--
>                                                          ___________________
>  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
>  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
>  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /
-- 
   T. V. Raman <raman@cs.cornell.edu>Tel: (607)255-9202  R 272-3649
                       Office: 4116 Upson Hall,
Department of Computer Science, Cornell University Ithaca NY 14853-6201
                Res: 226 Bryant Avenue Ithaca NY 14850
Newsgroups: comp.infosystems.gopher
From: sysbrc@loki.albany.edu (Brian Cuttler)
Subject: VMS gopher server - privs?
Originator: sysbrc@loki.albany.edu
Organization: State University of New York at Albany
Date: Tue, 29 Dec 92 19:21:47 GMT

The subject says it all.  I'd like to run my Gopher server under VMS 5.5
using UCX with the minimal priv set I can.  Will someone please send the
list of privs required, a reason for each of the required privs would be
apreciated.

						thanks,

						Brian
-- 
------------------------------------------------------------------------------
 Brian R Cuttler                 |        bitnet:    sysbrc@albnyvms
 Senior System Programmer        |        internet:  sysbrc@uacsc1.albany.edu
 State Univ of NY at Albany      |        phone:     518-442-3906
From: mikael@scout.utexas.edu (Mikael Behrens)
Newsgroups: comp.infosystems.gopher
Subject: NeXT gopher problem
Date: 27 Dec 92 22:15:55 GMT
Reply-To: mbehrens@cs.utexas.edu
Distribution: usa

Hi

I've been playing around with Gopher version 1.12 on my NeXTstation and  
have a problem.  When I click on a courier font file which is actually a  
telnet session, the terminal application is not fired up and I get the  
following messages in the console:

Gopher: No such file or directory
Gopher: Execve error code=-1.

In the preferences I have Terminal picked and not Stuart.  I'm running  
NeXTStep 3.0.

Any help would be appreciated.

Mikael Behrens
Newsgroups: comp.infosystems.gopher
From: ron@rivm.nl (Ron Roozendaal)
Subject: Re: Public access xgopher account
Reply-To: ron@rivm.nl
Organization: RIVM
Date: Mon, 21 Dec 1992 08:40:51 GMT

In article <7058@m1.cs.man.ac.uk> zlsiimw@info.mcc.ac.uk (Mark Whidby) writes:
>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
>

We did so without any problems.


Ron

____________
  Ron Roozendaal (ron@rivm.nl)
  Senior Consultant
  National Institute on Public Health and Environmental Protection (RIVM)
  Informatics Service Centre
  Postbox 1, 3720 BA Bilthoven, the Netherlands
  Tel. ++31 30 742790, Fax. ++31 30 282 316

Newsgroups: comp.infosystems.gopher
From: riddle@is.rice.edu (Prentiss Riddle)
Subject: Can't get gopherd 1.03 to run both setuid and chroot
Organization: Ministry of Information, William's Marsh
Date: Sat, 2 Jan 1993 22:29:58 GMT

I hate to whine with what sounds like a typical newbie question :-) , but:

I can't seem to make the Gopher 1.03 server work with both chroot() and
setuid().  That is, I can run gopherd with both -u and -c or with
neither, but not with -u and without -c.  When I try to do so, the
server gives the client nothing but a "Server error: Data_Dir
dissappeared!" message.  I added some debug output to the code and
determined that the chroot() call fails and errno gets set to 82
(ENOLINK, "the link has been severed" -- no, I'm not using RFS so I
don't know why this triggers an ENOLINK error).

Looking at the code, I can't really see how the chroot() call *could*
work, since the setuid() call in main() has already been executed
before we get to the chroot() call in do_command().

I am running Gopher 1.03 with SunOS 4.1.2.  The gopherd command which
fails is:

     gopherd -s /chico-b/cwis/gopher/etc/test.sec -l /tmp/gopher-1113 \
     	-u cwis /chico-b/cwis/gopher/test 1113

Anyone know what I'm doing wrong, or is this a bug?

-- Prentiss Riddle ("aprendiz de todo, maestro de nada") riddle@rice.edu
-- Unix Systems Programmer, Office of Networking and Computing Systems
-- Rice University, POB 1892, Houston, TX 77251 / Mudd 208 / 713-285-5327
-- Opinions expressed are not necessarily those of my employer.
Newsgroups: comp.infosystems.gopher
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: Re: Problem with Xgopher 1.2 and/or gethostbyname
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Mon, 21 Dec 1992 20:55:03 GMT

droelke@spirit.aud.alcatel.com (Daniel R. Oelke) writes:

>I just compiled Xgopher 1.2 - my first gopher client.
>It appears to work great, but only with numerical IP address.  

>The problem I have is that the function call to gethostbyname according
>to my man pages only resolves hosts listed in /etc/hosts , but apparently
>it is intended to (in net.c of xgopher.c) to access the domain name server
>and resolve the host this way.  This defficiency of course creates 
>problems as I can't use anything other than the IP addresses for
>xgopher.

>My big question is: Is there a workaround or fix for this?


>The flavor of UNIX I am running is 
>"SunOS Release 4.1.2 (GENERIC) #1: "
>and I am running OpenWindows 3 (and I have gotten around the problems with
>the Xmu library).

>Thanks for any and all help you can give me.

>Dan Oelke

>-----------------------------------_---_--------------------------------------
>Dan Oelke                         / \ / \              Alcatel Network Systems
>droelke@aud.alcatel.com           \  V  /                       Richardson, TX
>Phone: (214) 996-5013              \VMS/             #include <std-disclaim.h>
>  Fax: (214) 996-7119               \ / 
>-------------------------------------V----------------------------------------

I have compiled xgopher 1.2 on SunOS 4.1.2 and am able to invoke is for
example:
 xgopher gopher.msen.com

gopher.msen.com is definitely being resolved by DNS.  It is not in our
/etc/hosts or our NIS maps.  The difficulty is the way that Sun does DNS.
It generally assumes you will either have complete /etc/hosts tables or that
you will be running NIS, which will then hand off DNS requests to DNS.  Is
DNS working in general at your site?  Can you do ftp by name to other sites?

This is a frequent discussion item in comp.sys.sun.admin.  There are ways of
fixing Sun DNS service to work without NIS, but we run NIS and I have not
needed to do that.  It involves remaking libc.so with the lookup routines in
libresolv.a or something.

--
--                                                        ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /
Newsgroups: comp.infosystems.gopher
From: gilbertd@sunflower.bio.indiana.edu (Don Gilbert)
Subject: Re: WAIS: Boolean vs. "Standard" searching...
Organization: Biology, Indiana University - Bloomington
Date: Mon, 21 Dec 1992 23:29:03 GMT

The boolean search ability resides with gopher/wais servers.  It
is always going to be the case in gopher/wais land that users
will need to pay some attention to the customizations at the 
servers that they use.  I may want to provide a unique search service
suited only to biology data, and I will make help available via
gopher to explain this as need be.  After all, gopher is a great
tool for making such help available also.  We can lead the horses
but we can't force the stuff down their throats.

However, I have in the back of my mind that a Gopher+ server and client
might use an extended query (+ASK ?) that would have additional lines
of info as the query is presented to the user, with such pertinent 
help as:
Question from server ------
   Search for what recipe?
   (use "and" and "not" between terms to limit responses,
    use "word*" to match partial words, and 
    use "'some phrase!'" to match literal strings )

I don't know yet if this can be shoehorned into the protocol.

-- 
Don Gilbert                                     gilbert@bio.indiana.edu
biocomputing office, biology dept., indiana univ., bloomington, in 47405
Newsgroups: comp.infosystems.gopher
From: lindner@mudhoney.micro.umn.edu (Paul Lindner)
Subject: Re: Gopher and Symbolic links
Organization: University of Minnesota, Minneapolis
Date: Thu, 31 Dec 1992 05:16:21 GMT

In <1992Dec30.200953.28176@midway.uchicago.edu> rich@delphi.bsd.uchicago.edu (Rich Long) writes:


>Does (should?) gopher follow symbolic links?  The service I am trying to  
>provide includes many large files that I want to reside in one place and
>have links to them in more specific areas.  However, gopher does not seem  
>to follow symbolic links, is there a way around this?

The solution to most Unix gopher daemon problems 1/2 :-)

use the -c option..
--
 | 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: rgg@yarra-glen.aaii.oz.au (Rupert G. Goldie)
Subject: Re: Problem with Xgopher 1.2 and/or gethostbyname
Organization: Australian Artificial Intelligence Institute
Date: Thu, 24 Dec 1992 03:57:38 GMT

droelke@spirit.aud.alcatel.com (Daniel R. Oelke) writes:

>I just compiled Xgopher 1.2 - my first gopher client.
>It appears to work great, but only with numerical IP address.  

>The problem I have is that the function call to gethostbyname according
>to my man pages only resolves hosts listed in /etc/hosts , but apparently
>it is intended to (in net.c of xgopher.c) to access the domain name server
>and resolve the host this way.  This defficiency of course creates 
>problems as I can't use anything other than the IP addresses for
>xgopher.

>My big question is: Is there a workaround or fix for this?

I have run into this problem many times on the Sun. I just add -lresolv to
the list of libraries to be linked to make it use the nameserver. You can
hack your libc to make it use the resolver by default, but I haven't tried
that yet.

Hope this helps,

Rupert
-- 
Rupert G. Goldie, Research Scientist                rgg@aaii.oz.au
Australian Artificial Intelligence Institute        
Life's a bitch and then you die.
From: rosenblg@calvin.NYU.EDU (Gary J. Rosenblum)
Newsgroups: comp.infosystems.gopher
Subject: Getting archive of gopher news
Date: 22 Dec 1992 03:08:18 -0500
Organization: New York University
NNTP-Posting-Host: calvin.nyu.edu

I sent this to the gopher team, but it may have gotten lost - does anyone
know where one can get the *full* archive of gopher news?  It's currently
served as individual files, but when I search for 'wais' I get back far
too many to read via gopher - I'd much rather search the whole file on-line.
(I'm looking for this archive since I've been having a devil of a time 
trying to get wais searching to work in gopher1.1 under Ultrix 4.3).

The files are on mudhoney, in /Mailstuff/gopher-archive, but I can't
ftp there as anonymous.

					Gary
-- 
Gary J. Rosenblum	
UNIX Systems Manager			rosenblg@nyu.edu
New York University			gary@nyu.edu
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: Sat, 26 Dec 1992 15:42:12 GMT

In article <1havm0INNes2@phantom.gatech.edu> 
 ccoprmm@phantom.gatech.edu (Michael Mealling) writes:
>In article <1992Dec23.202920.2994@galileo.cc.rochester.edu> 
 kann@picasso.cc.rochester.edu (Kirk Anne) writes:
>>In <1992Dec22.164051.5141@news2.cis.umn.edu> 
 lindner@mudhoney.micro.umn.edu,
>>(Paul Lindner) writes:
>>>I think gopher+ will address some of these shortcomings.  There are
>>>two ways to do it right, the first might be to make an alternative
>>>directory view, clients that understood it..  Or, you could specify an
>>>alternate block like this:
>>
>>Another thought is to include an "announcement" file that old gophers
>>can see.  Something like
>
>  I figured Gopher+ could do this better but (and I hate to sound impatient)
>our lawyers won't go along with a system unless it has such a disclaimer.
>I know the current versions of the Mac clients are Gopher+ ready but when
>should we expect to see servers and clients for other platforms?

Most clients require either no changes or only trival mods not to break
under gopher plus. However, this kind of popup announcement is an extra
feature that is not going to come automatically even with support of
the gopher plus protocol.

I would repeat one of my earlier suggestions: Modify the server code
to put a disclaimer after (or even before) all plain text items.

This way all clients will see it.

(I would be personally annoyed at having to dismiss lots of little pop-up
announcements.)

-- 
    Albert Lunde                      Albert-Lunde@nwu.edu
Newsgroups: comp.infosystems.gopher
From: shenton@nsisrv.gsfc.nasa.gov (Chris Shenton)
Subject: No logging when running ``gopherd -u gopher'' ?
Organization: Hughes/STX, Lanham, MD
Date: Wed, 23 Dec 1992 20:50:51 GMT

I had logging working fine when running (gopher 1.1) gopherd, both as
a background process and from inetd.

Now I'm running it from inetd, and because of security concerns, am
running it as user gopher. Here's my inetd incantation, with
linebreaks for readibility:

	gopher stream tcp nowait root /usr/local/etc/gopherd
		gopherd -I -c -u gopher -l /tmp/Gopher_Daemon_Log
		/usr/local/gopher-data 70

It no longer creates the log file in /tmp, nor does it append to a log
file which I create with world-write access.

Any ideas? Email preferred as I don't want to miss responses while on
vacation; I'll summarize when I return.

Thanks.

-- Chris Shenton    shenton@nsisrv.gsfc.nasa.gov    NASA/GSFC/HSTX 301-286-9430
--
-- Chris Shenton    shenton@nsisrv.gsfc.nasa.gov    NASA/GSFC/HSTX 301-286-9430
Newsgroups: comp.infosystems.gopher
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: gopher 1.1 client dumps core erratically.
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Sun, 3 Jan 1993 03:58:16 GMT

I would really like to update to the 1.1 client from 1.03, but it rather
erratically dumps core on a Segmentation Fault.  It may work without
problems for 10 times and then dump every time for the next 10.

I have compiled it on a Sun 4/490, SunOS 4.1.2, using the bundled C
compiler, as well as GCC 2.3.1.  The behavior is identical.  The only
non-standard think I may have done in the Makefile is select -DLOADRESTRICT
or whatever it is called.  

I have been running 1.03 for a month without one observed core dump.  

Has anyone else observed this?  Any suggestions what may be causing it?  I
have a suspicion it may be occurring during host lookup.  The Sun is using a
totally stock Sun DNS over NIS configuration.  Please note that 1.03 works
flawlessly, as well as xgopher 1.2.

--
                                                          ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /