HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.infosystems.gopher
Subject: Re: 's' broken in gopher1.11?
From: pmurray@watson.lib.muohio.edu (Peter Murray)
Date: 12 Jan 93 10:37:26 -0500
X-Newsreader: TIN [version 1.1 PL6]

Peter Murray (pmurray@watson.lib.muohio.edu) wrote:
: Mark Boyns (boyns@hercules.sdsu.edu) wrote:
: : In the UNIX gopher client 1.1 's' could be used to save a file
: : from a menu.  In gopher 1.11 's' does not do anything.  
: : 
: : Am I doing something wrong or is it really broken?
: : 
: : BTW I am not using secure mode.
: 
: In the new code, there is a new parameter in the "Save_file" function call.
: The call from gopher/gopher.c does not include this new parameter.  I'm not
: sure what was indended here, but you can fix the problem by adding a NULL 
: parameter at the end of line 971, so that it looks like this:
: 
:   Save_file(GDgetEntry(CurrentDir,GDgetCurrentItem(CurrentDir)-1),NULL,NULL);
: 
: Seems to work fine after that change.

I found another one...in gopher/ourutils.c at line 446 add another "NULL"
parameter at the end of the call.  The line should look like this:

  Save_file(gs, Filename, NULL);

The third parameter is used as a filename to save the file to.  In most
cases, the user should be prompted.  However, the download function uses
this function call also, and in that case, the download code sends the
Save_file function call the file name it wants it to use to save file file.
That way the download code can find the file and send it back to the user.


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: dan@ortta.umn.edu (Daniel C. Cummings)
Subject: Re: Telnetting under the PC Client...a solution!
Organization: U of Mn
Date: Sun, 10 Jan 1993 00:47:40 GMT

In article <1993Jan9.174023.29071@sun0.urz.uni-heidelberg.de> flight@vogon.mathi.uni-heidelberg.de (Gregor Hoffleit) writes:

>In article <dan.67.726532246@ortta.umn.edu> dan@ortta.umn.edu (Daniel C.  
>Cummings) writes:
>> There was a discussion a while back about the problem of launching telnet 
>> under the PC Client.  Basically, within the tiny confines of PC memory, 
>> gopher uses up too much memory to successfully run the 200-300 KB telnet 
>> emmulators we're all so fond of.  The solution was basically to find a 
>> smaller telnet.  But I saw a post on the Novell net today describing a  
>> relatively simple memory swap that allows even a large telnet program to 
>> be launched nicely.  I picked up the program and it works great!  I'll test 
>> it more over the weekend and see if it is stable enough to release to my 
>> users.  Anyway, here's the post...hope it is helpful to you as well....
>[...]

>Thanks for the tip, Daniel, it really works great!

>One questions remains:

>Is it possible to disable the requester that tells that gopher is short of  
>memory and asks if you want to start telnet nevertheless ? It's a little bit  
>annoying to have to choose 'Ok' and press Enter every time you want to start a  
>telnet sessions.

>Is there perhaps anybody who worked around this ?

>---------------
>gregor hoffleit
>mathematisches institut der universitaet heidelberg
>telephon: (49) 6221 56-5771 (new phone number) <---------------------
>email: flight@vogon.mathi.uni-heidelberg.de (nextmail preferred)
>snail: inf 288, w-6900 heidelberg, germany

Well.....gosh....I hate to admit this but, Daniel Torrey, the author of the 
PC Client added that little message after a complaint of mine!  At the time, 
if a Telnet session was launched without enough memory, it would just fail 
with no explanation.  The message was designed to give you some more 
information for troubleshooting in these types of situations. 

Now with this new "swap" routine, this type of trouble has gone away for me
and it sounds like it has for you too!  I'll forward this correspondence to 
Daniel and see what he thinks.  Maybe an optional warning, or maybe do away 
with it......It is rather useful though if your still fighting the RAM cram 
blues!


Regards -

Dan

~!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Daniel C. Cummings, CNE                   Voice:  (612) 624-2574
Manager of User Services                  FAX:    (612) 624-4843
University of Minnesota - ORTTA
1100 Washington Avenue, Suite 201
Minneapolis, Minnesota  55419-1226      Internet: dan@ortta.umn.edu
USA
Newsgroups: comp.infosystems.gopher
From: kadie@eff.org (Carl M. Kadie)
Subject: Whatsnew version 0.4
Originator: kadie@eff.org
Organization: The Electronic Frontier Foundation
Date: Wed, 6 Jan 1993 01:14:42 GMT

I've changed "findwhatsnew" so that keeps items in its database even
if it can't find them when updating the database. (Before, if a gopher
server went down and then came backup, "findwhatsnew" thought all its
items were new.)

- Carl

ANNOTATED REFERENCES

(All these documents are available on-line. Access information follows.)

=================
admin/whatsnewd
=================
* Code for and description of "whatsnewd" (v. 0.3)

(Connect your Gopher to "gopher.eff.org", port "5070" to play with it.)

It is a gopher-protocol server.

What it does:

When a user gives a date (e.g. "1 day ago") or enters a dated bookmark
(generated by a previous query), he or she gets a gopher menu of the
gopher items that are new or changed since that date.


=================
=================

If you have gopher, you can browse the CAF archive with the command
   gopher gopher.eff.org

These document(s) are also available by anonymous ftp (the preferred
method) and by email. To get the file(s) via ftp, do an anonymous ftp
to ftp.eff.org (192.88.144.4), and get file(s):

  pub/academic/admin/whatsnewd

To get the file(s) by email, send email to archive-server@eff.org.
Include the line(s) (be sure to include the space before the file
name):

send acad-freedom/admin whatsnewd


-- 
Carl Kadie -- I do not represent EFF; this is just me.
 =kadie@eff.org, kadie@cs.uiuc.edu =
From: lindner@danzig.micro.umn.edu (Paul Lindner)
Newsgroups: comp.infosystems.gopher
Subject: Re: How to get rid of this error message in 1.11 client
Date: 12 Jan 93 19:57:42 GMT
Article-I.D.: news2.C0rBG8.8rv
Organization: University of Minnesota, Minneapolis

In <1993Jan12.160122.25243@news.csuohio.edu> cowboy@trans.csuohio.edu (Joe Rosenfeld) writes:

>I just compiled the 1.11 latest client, and set up a login that took one right into my gopher  
>client, which access an older gopher server (problems compiling on the NeXT with NS 3.0).

>When someone running gopher -s tries to log into the gopher client it works, but when you try  
>to access any text file this window pops up:

>	"Sorry Cannot Display this file anonymously"

>Any suggestions as to how I can rid of this message and display text files in this manner?

>thanks
>Joe

Oooops!! I wanted to restrict picture viewing and the like.
Unfortunately I got normal files as well..  

Get gopher1.11a.tar.Z on boombox in about an hour..
--
 | 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: rob@dragon.acadiau.ca (Rob Hutten)
Subject: Partially restricting access to non-local users
Organization: Acadia University
Date: Wed, 6 Jan 1993 20:04:01 GMT

I haven't seen this in the FAQ, so forgive me if it's been asked
before...

Is there any way to restrict access to certain files in gopher
so that only local users can read them?  We want to allow off-site
access to all but a few files.

Please email and I'll summarize (assuming I won't get flamed to a crispy
for posting a FAQ)

Thanks a heap.

-Rob

-- 
Rob Hutten, UNIX Systems Programmer          Acadia University, Wolfville, NS
rob@dragon.acadiau.ca      (902) 542 2201x158        I speak for myself only.
From: kbarger@cellar.org (Kyle Barger)
Newsgroups: comp.infosystems.gopher
Subject: Re: Macintosh Gopher Server -- alias files, ordering of items
Date: 10 Jan 93 03:36:55 GMT
Organization: The Cellar BBS and public access system

murphy@dccs.upenn.edu writes:

> I ran the Gopher server on a MAC the other day and
> noticed two things:
> 
> 1) I can't seem to use MAC OS aliases within the Gopher
> server's folders to link one document to another.  I
> expected the Gopher server to figure out what an alias
> is and give me the file it points to.  It doesn't do
> that -- it gives an empty response, I think.  It seems
> unreasonable that I should have to make a second,
> identical copy of a document on my disk drive when what
> I really want is the same document to appear in more
> than one place in the Gopher's info structure.

Hmmm.  I'm not sure about this one, but the Gopher server uses its own
aliases for links.  I imagine you could use this feature to get the link.

> 2) I could not figure out how to control the ORDER of
> the documents within a folder.  How does the MAC Gopher
> Server decide what order to send the items?  How can I
> change that order?  Does Gopher's Helper do it?

The documents are displayed alphabetically by FILE NAME.  So if you want
your "Welcome" file to be first on the list, you could call it something
like "AAWelcome".  Then you can use Gopher's Helper to change the Long Name
of that document to what you want the client to display (e.g., "Welcome too
the FooBar Gopher Server!!")  The Long Name is ignored for purposes of
alphabetizing the files names.

> TechInfo (CWIS written by MIT) handles these two things
> quite easily.  I'm surprised that Gopher doesn't.
> Perhaps I'm not using the software correctly...

I myself found it difficult to figure out how to implement some of the item
types (such as telnet sessions) with the Mac server.  I found that reading
the Gopher protocol description helped a lot--you might want to try that.  I
think the Gopher's Helper could definitely use some examples of setting up
item types besides folders and text documents.  

--------------------------------------------------------------------------
Kyle Barger                     "Beauty, alas, is not relevant to Usenet."
kbarger@cellar.org      --Brendan Kehoe, _Zen and the Art of the Internet_
--------------------------------------------------------------------------
Newsgroups: comp.infosystems.gopher
From: lindner@mudhoney.micro.umn.edu (Paul Lindner)
Subject: Re: Gopher+ Release; when?
Organization: University of Minnesota, Minneapolis
Date: Thu, 7 Jan 1993 18:58:35 GMT

In <1igj9kINN3vb@morrow.stanford.edu> GA.SBP@forsythe.stanford.edu (Bo Parker) writes:

>Any news on release of Gopher+ clients and servers?

>I recall an announcement at an EDUCOM presentation last
>October that a release was planned by the end of the year.

Well....  we're still working on a few little nits..  Just about ready
to go.

>******* scene from a 12-step plan  **********
>"Hi, my name is Bo and I'm a gopher addict."

And my higher power is UNIX    :-)
--
 | 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: RETRIEVE MAX PER SESSION NEEDED...
Organization: Stanford University, California, USA
Date: Fri, 8 Jan 1993 17:15:58 GMT

kemp@uiatma.atmos.uiuc.edu (John Kemp) writes:

>I would like to prevent people from running tree 
>walking programs on our gopher server.  We have 
>an unusual set up with maybe 4000-5000 entries
>in our server.  Many of them are sym links and 
>duplicate directories.

>And yet, without fail, every day or two, some 
>bozo traverses the whole tree.

>Is there an easy way to limit the number of accesses
>per session?

>JohnKemp@uiuc.edu

	Unfortunately, there's not much of a notion of "session" in
gopher. Each directory access is a separate session. My suggesstions
would be to build "-DLOADRESTRICT" in order to at least prevent them
from killing your machine.
	You can also do some logging and if it's the same host,
contact them or restrict them.
	Perhaps we should think again about an idea that came up a
while back of having your tree available in a file at the top level
(under a hidden name) where clients could just grab the file
instead of walking the tree. This won't prevent somebody who isn't
aware of the file, but might make life easier for everybody in the
future, both Veronica maintainers and us system folk who are
stuck trying to keep our machines usable.

"mike" (Mike Macgirvin)     Mike_Macgirvin@MED.Stanford.EDU
Unix Server Administrator   Center for Advanced Medical Informatics at Stanford
From: nigelm@ohm.york.ac.uk (Nigel Metheringham)
Newsgroups: comp.infosystems.gopher
Subject: Gopher and exec scripts - argument passing
Date: 8 Jan 93 17:03:34 GMT
Organization: Electronics Department, University of York, UK

In the Unix gopher 1.1 you can have an exec script which has
effectively fixed arguments by having them encoded in the selector
string.

Is there any reason why I shouldn't modify the server slightly to
take any additional info passed following a tab and add that to the
script arguments?

The point of doing this is that I could then start up some form of
script with variable arguments supplied by the gopher user - so in
the case of what I want to do, I can have an archie started up and
passed a search string from the user without needing to make a
special archie psuedo-gopher-server running on yet another random
machine port.

If this is a bad thing (tm), please let me know why.

	Nigel.
-- 
#   Nigel Metheringham  -- (NeXT) EMail: nigelm@ohm.york.ac.uk    #
#   System Administrator, Electronics Dept, University of York    #
#   York YO1 5DD. Phone: +44 904 432374, Fax: +44 904 432335      #
Newsgroups: comp.infosystems.gopher,comp.infosystems.wais
From: kadie@eff.org (Carl M. Kadie)
Subject: Re: Intelligent news+wais+archie+gopher+... -> Daily Personal News
Originator: kadie@eff.org
Organization: The Electronic Frontier Foundation
Date: Tue, 12 Jan 1993 22:54:38 GMT

estephen@whosnext.cad.gatech.edu (Eric R Stephens) writes:

>I would like a way to automatically go through the various  
>information services so that the ones of interest to me are presented  
>each day, already sorted, ....
[...]

I have a set of programs for gopher that does some of what want.
I use it everyday to
  1) read new college newspaper articles
  2) see what material is new on the EFF gopher
  3) see what material is new on the U. of Illinois gopher

Connect your Gopher to "gopher.eff.org", port "5070" to play with it.

- Carl

ANNOTATED REFERENCES

(All these documents are available on-line. Access information follows.)

=================
admin/whatsnewd
=================
* Code for and description of "whatsnewd" (v. 0.4)

It is a gopher-protocol server.

What it does:

When a user gives a date (e.g. "1 day ago") or enters a dated bookmark
(generated by a previous query), he or she gets a gopher menu of the
gopher items that are new or changed since that date.


=================
=================

If you have gopher, you can browse the CAF archive with the command
   gopher gopher.eff.org

These document(s) are also available by anonymous ftp (the preferred
method) and by email. To get the file(s) via ftp, do an anonymous ftp
to ftp.eff.org (192.88.144.4), and get file(s):

  pub/academic/admin/whatsnewd

To get the file(s) by email, send email to archive-server@eff.org.
Include the line(s) (be sure to include the space before the file
name):

send acad-freedom/admin whatsnewd

-- 
Carl Kadie -- I do not represent EFF; this is just me.
 =kadie@eff.org, kadie@cs.uiuc.edu =
Newsgroups: comp.infosystems.gopher
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: Accessing images from a (free) PC Client
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Tue, 5 Jan 1993 15:24:38 GMT

I posted a request the other day for pointers to a PC gopher client that
would allow viewing of graphic images, similar to the ability under xgopher.
Several people responded that there are PC clients using commercial TCPIP
stacks that have been ported from the UNIX curses client.  Our network is
too big and messy to go out and buy commercial TCPIP stacks for all of the
PC's.  There must be someone who is working on a graphic capable PC client
that runs on top of Packet Drivers or some other non-commercial TCPIP
stack.  Given the choice of a point and click client that doesn't do
graphics or a text-oriented client that does graphics, I would much prefer
the ability to display graphics in the gopher.


--
                                                          ___________________
  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: masinter@parc.xerox.com (Larry Masinter)
Subject: MOO Gopher: a new Gopher client (in MUD)
Keywords: gopher mud
Organization: Xerox PARC
Date:  8 Jan 93 01:36:55 GMT

I've built a new Gopher client which is a little different. This
client allows access to Gopher space from inside a MOO. MOO is a kind
of MUD -- multi-user interactive environment.

In MOO-Gopher, multiple users can be searching together in a gopher
room. There are also various 'virtual reality' objects: a gopher note
(which acts like a 'note', can be carried, handed to others, etc., but
goes through gopher to get the text when read.), a gopher list (like a
set of bookmarks, but an object in its own right), and a few others.

To try this, visit JaysHouseMOO:
   telnet theory.cs.mankato.msus.edu 1709
    (or use a Mud client)
   connect guest
   go up east enter down

Also, if you can find it, there's a weather map in the living room
that gets its data from the University of Illinois weather machine.

If you want to see source code, an earlier version is available for
anonymous FTP on:

  parcftp.xerox.com:/pub/MOO/contrib/moocode/gopher.moo.
   
I thought this was an interesting way of linking the 'interactive
community' of mudding with the 'information retrieval' space that
gopher represents. It's interesting watching people in a gopher room
help each other find something (and get in each other's way).
--
Larry Masinter <masinter@parc.xerox.com> Xerox Palo Alto Research Center (PARC)
3333 Coyote Hill Road; Palo Alto, CA 94304; (415) 812-4365 Fax: (415) 812-4333
From: dsewell@milori.ccit.arizona.edu (SEWELL, DAVID R.)
Newsgroups: comp.infosystems.gopher
Subject: Selective directory limitations?
Keywords: gopher, publishing, library, access
Date: 10 Jan 93 17:55:00 GMT
Distribution: world,local
Organization: University of Arizona
News-Software: VAX/VMS VNEWS 1.41

This may be an RTFM question, but I haven't had hands-on experience
setting up a gopher server and so haven't yet studied the
documentation.  

Suppose I have on a gopher server one area that contains files
I want people to be able to read on-line but not to copy readily.
(Let's say it's copyrighted material.)  I know that anything that can
be read can be screen-grabbed or logged.  But would it be possible to 
make copying more difficult by doing the following:

  1) disable the mail-to function for the selected files
  2) run scrolling for the selected files not through the client's
     pager but through a pager on the server that slows down scrolling
     speed so that a reader can't just zip through the file to 
     "download" it.

Before everyone yells at me for un-gopherlike desires to restrict
information flow, the point is it would be a choice between publishing 
with some controls and not publishing at all, and I'd rather do the
former, if gopher will allow it.

--
David Sewell, English Dept, U of Rochester   |  "Grammarians without any
  dsew@troi.cc.rochester.edu                 |  character at all lecture
  dsewell@violet.ccit.arizona.edu            |  us on that of Odysseus."
(On leave in Tucson, Arizona, '92-'93)       |     --Diogenes the Cynic
Newsgroups: comp.infosystems.gopher
From: datta@cs.uwp.edu (David Datta)
Subject: Testing a Gopher server modification
Organization: University of Wisconsin - Parkside
X-Newsreader: TIN [version 1.1 PL8]
Date: Fri, 8 Jan 1993 19:17:38 GMT

I need help testing a server modification. I have changed a test 1.03
server to parse delimited lyrics files as if they were a kind of
mailbox. I need people to connect to it and see if it crashes....
it is running at gopher.uwp.edu port 2000. (Port 70 is the normal
gopher that I know works...)

If folks could try it out and let me know if things work okay....

(All of the entries at the root of the server are single album files I
have delimited from the lyric archives.)
-- 
-Dave datta@cs.uwp.edu
	"Such abuse would be illegal and is therefore unlikely." 
		- FBI Director William Sessions
Newsgroups: comp.infosystems.gopher
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: FREE Graphics-capable PC Gopher that runs on FREE TCPIP stack?
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Fri, 8 Jan 1993 12:37:14 GMT

I am so far disappointed in my quest for a gopher client that will run on
top of Packet drivers AND display GIFs.  The standard-issue PC-Gopher 1.05
or whatever release it is has a nice user interface, but I am still
overwhelmed by the irony of having a GUI look, but not being able to do
graphics. (Unless I have missed soething).  The UofTexas Med.School port of
the curses client has a lot of nice features, including the use of the
spawn0 library to conserve memory use, BUT the version I found will only run
over PC/FTP (the developers of the Packet driver protocol?) COMMERCIAL TCPIP
stack.

IF the source code to either of these were readily available I could at
least contemplate porting the features I wanted to the already existing
features, BUT in true PC fashion, the distributions either are binary only
or STRESS binary distribution.  We have a couple of real Pascal graphics
jocks here that I could work with on the Pascal code for PC-Gopher, or there
is another bunch of us who could tackle the curses client and try to figure
out how to get it going with packet drivers.  IF we could get our hands on
the source to both PC clients it might turn into a pretty short hack.

If any of the principles are listening, would you be amenable to someone
else playing with your code?  What about if the changes were returned to you
to release?  Barring that SOMEBODY needs to begin the process of developing
a FREE PC client that will continue to be available in source code so that
people will be able to make modifications as they are needed.



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