HDTenEightyP/NetNews huggingface dataset:
From: sauer@chama.eece.unm.edu (Tom Sauer)
Newsgroups: comp.soft-sys.khoros
Subject: Re: FAQ's and help requested
Date: 17 Nov 92 16:38:45 GMT

On Nov 16, 11:08, Tracy Bowlin wrote:
} Subject: FAQ's and help requested
>> Greetings from Idaho!
>> 
>> 
>> I am new to khoros and would like information on FAQ's. 

The FAQ and Compile_FAQ can be ftp'ed from "pprg.eece.unm.edu" in the
directory pub/khoros/release


>> 
>> Also I have a problem with khoros?
>> 
>> When ever I have a window with an image in it (editimage, displayimage) when my cursor is outside the active display window everything is fine, but when I move the cursor inside the active window my screen goes black except for the image its self. This blacks out all of the information and I can see just a ghost of the pulldown menu icons. This is running on a SUN Sparc station IPX. I have tryed the different .Xdefaults provided with khoros, including the .Xdefaults  that came with the sun for OPENWIN. 







Any help will be appreciated.


>From the Khoros FAQ

   Q29. I'm on a SUN architecture, using OpenWindows 2.0. When I display images,
        they come up  with colored speckles in them, or strangely colored in
        some way. This condition rights itself when I move the cursor into
        the image, but then the colors in my user interface get messed up -
        sometimes I can't see anything but the image.  Is this a bug in Khoros?

   A29. No, it is a result of us having to work around a bug in the X server
        which will cause the server to dump when any display routine attempts
        to create a private colormap.  We managed to work around the bug,
        but at the cost of user interface colors no longer being defined as
        the original colors.  This implies that with any display routine, your
        user interface colors will be undefined if the programs cannot use
        the default colormap;  in this case, your user interface colors may
        disappear, may be arbitrarily defined, or may have their colors
        re-defined according to the current colormap.  The best you can do
        is try to limit the colors used in your image, thus leaving more
        color cells "left over" for the user interface to use.
        Note that this bug has been fixed in OpenWindows 3.0.

>> 
>> 
>> Tracy Bowlin
>> Remote Sensing/ GIS analyst 
>> Idaho State University
>> Box 8007
>> Pocatello, Idaho 83209-8007
>> Internet: bowlin@ecol.lter.isu.edu
}-- End of excerpt from Tracy Bowlin



Tom

-- 
============================================================================
Tom Sauer                 |  Email: sauer@chama.eece.unm.edu
The Khoros Group          |
Dept. of EECE             |  
University of New Mexico  |  Phone: (505) 277-6563
Albuquerque, NM 87131     |    Fax: (505) 277-1439
============================================================================
From: NLAFLAMM@vma.cc.nd.edu (Nick Laflamme)
Newsgroups: comp.infosystems.gopher
Subject: Re: More people would use Gopher if...
Date: 19 Nov 92 19:57:42 GMT
 <1992Nov18.033951.26978@msuinfo.cl.msu.edu>

I knew I should have kept out of this thread.... :-)

We computer nerds will always call this Gopher for as long as we talk
about it.  I have no particular problem with that.

However, I doubt I'm the only one who wraps a front-end around his
"GOPHER" program.  Mine's called "NDInfo", because it connects primarily
to Notre Dame's gopher server and from there to the rest of the world.

Will my users see the word "gopher"?  Sure, on node names and menu items
and other things internal to the system they're already using.  Some
will be confused by it, some amused, some will charge forth and learn as
they go what Gopher must mean.

But before they get to that point, they'll first see icons or commands
or whatever called "NDInfo", which I feel is a much more meaningful
name.  If someone tells them to find this "Gopher" thingamajig and try
it, they'll get the same program; I'm not ruthlessly eliminating the
name from the few systems I control.  But I'll always try to give my
users a more meaningful alias than "GOPHER" (or "PNN", or whatever the
next trendy information access method will be).

Obligatory disclaimer:  I do not speak for Notre Dame's Office of
University Computing.  In fact, I lost a major flame war over just this
point.  Some of my colleagues are intrigued by the cuteness of the
name.  Others find calling it "NDInfo" incredibly parochial and
arrogant, given the breadth of information accessible which is not
"Notre Dame Information."

I, of course, was not swayed by their arguments, nor they by mine.

The points remain, though, that we need to remember the other point of
view.

Dismantling the soap box once more,

Nick
From: rick@sjsumcs.sjsu.edu (Richard Warner)
Newsgroups: comp.infosystems.gopher
Subject: Re: Is There an Open Look Xgopher?
Date: 15 Nov 92 20:06:00 GMT
Organization: San Jose State University - Math/CS Dept.

fwp@CC.MsState.Edu (Frank Peters) writes:

>In article <1992Nov12.223837.28926@sjsumcs.sjsu.edu> rick@sjsumcs.sjsu.edu (Richard Warner) says:
>: cdh@eng.cam.ac.uk (Chris Horne) writes:
>: 
>: >I've just disovered GOPHER and have compiled the Xgopher client. Great!
>: >Does an Open Look Xgopher exist? Is anyone working on one?
>: 
>: Why? 

>So that its behavior will be similar to other Open Look applications that
>he or his users are presumably using perhaps.

>The success of the Mac interface in spite of some real functional
>limitations seems, as much as anything, to be a product of the solid
>consistency of function in its programs.  Users like knowing how to
>make the scroll bar work in all of their applications once they learn
>to make it work in one application.  A lot of end user pleasure can be
>derived from such "trivial" user interface issues.

>:       I prefer that all freely available X software remain 
>: neutral in the matter of user interface.  There is nothing that
>: prevents an X client written for Xt or the Athena widgets, etc., from
>: functioning under the Open Look window manager 

>Sacrificing user satisfaction in favor of some abstract ideal of purity
>is, in my opinion, a bad idea.

This is not an abstract ideal.  There are a half-dozen major X based
UI's, and a lot more minor variants.  Do we have one client for each?
The *ENTIRE* idea of X was to have one, unifying protocol.  To add
multiple interfaces somewhat debases this ideal.  The ideal is *real*,
not abstract.  Do you want to port and support a dozen different 
X clients for each application?  That is what will happen *if* this
stupid, idiotic "we need a separate version for my favorite UI" crap
continues.  The UI in X was meant to be a function if the Window
Manager.  The basic cults have violated this by making the UI
dependent on external factors.  Let's stop the wars, tell the idiots
to put the UI back in the window manager, and get back to the ideal
of an X world in which every X application is independent of UI and
Window Manager.  (if folks want an Open Look interface, all the
SHOULD require is that they run an Open Look WM!  Period!).

>--
>Frank Peters  -  UNIX Systems Programmer  -  Mississippi State University
>Internet: fwp@CC.MsState.Edu  -  Phone: (601)325-7030  -  FAX: (601)325-8921
Newsgroups: comp.infosystems.gopher
From: aldrich@leland.Stanford.EDU (Jeff Aldrich)
Subject: Re: More people would use gopher if ...
Organization: Stanford University
Date: Tue, 17 Nov 92 17:52:02 GMT

In article <92321.102821NLAFLAMM@vma.cc.nd.edu>, Nick Laflamme <NLAFLAMM@vma.cc.nd.edu> writes:
> For what it's worth, the problem with "gopher" may be simply that it's
> too cute and meaningless.

C'mon, folks.  I refuse to believe that I'm the only one reading this group
old and decrepit enough to understand the significance/origin of the name
"gopher" in this general context.  The term began as a play on words, I 
think in the auto racing community, referring to the kids who ran errands
in the pits, which kids got ordered around with suggestions like "hey kid, 
go for some solvent, go fer some coffee, gopher this'n'that..."  Thus the
general-purpose fetcher of whatever is needful came to be known as a
gopher, ok?

................................................
 Jeff Aldrich    <aldrich@sunrise.Stanford.EDU>
 R&D Engineer    Center for Design Research
                 Stanford University
Newsgroups: comp.infosystems.gopher
From: lwv26@cas.org (Larry W. Virden)
Subject: Re: How to find new gopher databases.
Followup-To: comp.infosystems.gopher
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Thu, 19 Nov 1992 12:29:22 GMT

I believe that what think.com or whoever does is just use WAIS to index
all of the database .src files as they are submitted.  They only use
the descriptions that the database providers submit - thus the index is
only as good as the material submitted.

Perhaps a similar mechanism could be used for Gopher.  Have gopher sites
submit documents describing their data.  Then use WAIS to index those
descriptive documents.  Make the database accessible by gopher.

Personally, what _I_ want to see is some mechanism where the user can add
either personal or public notes to such an index.  For instance, let's
say that Univ of Thundaria indicates that they have a series of files
concerning cats.  In my browsing, I discover that someone has loaded
some files on dogs as well.  I would like to be able to add, to the index,
a note indicating - at least for my own long term use, and possibly for
public searching - that this site also has data on dogs.

In other words, I am still stuck in the late 60s and early 70s model 
the I first encountered in Ted Nelson's writings on Xanadu ... 
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
Newsgroups: comp.infosystems.gopher
From: lindner@danzig.micro.umn.edu (Paul Lindner)
Subject: Re: Using .cap files and the "Path" line
Organization: University of Minnesota, Minneapolis
Date: Sat, 21 Nov 1992 00:28:43 GMT

In <6792@m1.cs.man.ac.uk> zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby) writes:

>|> This works insofar as the name appears in the gopher client. However, 
>|> when I try to actually retrieve the document, it responds with 
>|> 
>|> OServer error: /afs/pitt.edu/public/info/pittdocblah-blah.doc' does 
>|> not exist!! error.host 1
>|> 
>|> The file exists just fine. I've tried a whole lotta combinations with 
>|> this. The file is world readable, and it behaves just the same whether 
>|> or not it is in afs. 

>I don't think you can do this. The pathname in the Path= line is relative
>to your gopher home directory (and so cannot be outside the gother tree).
>Try creating a file called blah-blah.doc in the directory
>/usr/gopher/data/afs/pitt.edu/public/info/pittdoc
>and see what happens. I don't know if you can access stuff outside the
>gopher tree.


If you run with the -c option you can create symbolic links outside
the gopher-tree.  Works fine.
--
 | Paul Lindner | lindner@boombox.micro.umn.edu   | Slipping into madness
 |              | Computer & Information Services | is good for the sake
 | Gophermaster | University of Minnesota         | of comparision.
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /
From: bill@biome.bio.ns.ca (Bill Silvert)
Newsgroups: comp.infosystems.gopher
Subject: Veronica:  an Archie for Gopher
Date: 18 Nov 92 17:52:54 GMT
Distribution: comp
Original-To: gopher-news@boombox.micro.umn.edu
Original-Cc: foster@cs.unr.edu (Steve Foster)
Content-Transfer-Encoding: 7BIT
X-Mailer: ELM [version 2.3 PL11]

I've just given Veronica a try, and it is definitely a step forward in
the gopher universe.  However, I still feel (as I've posted to Usenet)
that a more structured approach to gopher classification is needed.

For example, I did a search on "ecology" and came up with over 100
entries.  Very exciting, until I realized that most of these are for
specific university courses (Plankton Ecology 516 at U. Wisconsin for
example).  We need some way to filter out references to local gopher
sites.  Sure, it may well be that there is interest at one university in
looking at class notes at another, but my concern is whether there is
some way to find the gophers that offer specific types of information.

If the information could be structured in a hierarchical fashion, all
the better.  Say a couple of master gophers for physics, which point at
secondary masters for nuclear and other fields.
-- 
Bill Silvert at the Bedford Institute of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2
InterNet Address: bill@biome.bio.ns.ca
From: mandell@bach.helios.nd.edu (Dan Mandell)
Newsgroups: comp.infosystems.gopher
Subject: Gopher search capability
Summary: search
Date: 19 Nov 92 01:56:17 GMT
Organization: OUC, University of Notre Dame

At the risk of sounding really stupid, how does one set up gopher to search 
for a keyword in a directory or file (or would this require scripting
something like a wais search).  We have been experimenting with gopherd running
under unix/hpux and have the basics working...but so far I have not been able
to provide more than simple file retrieval. How would I set up a search for a
specific keyword in a set of documents in one directory?  I was under the
impression that gopher had built in search capability.

s
Dan Mandell (mandell@bach.helios.nd.edu)
Saint Mary's College, Computer Services 
Notre Dame, Indiana 46556  -  Phone: (219) 284-4610
Newsgroups: comp.infosystems.gopher
From: ccksb@trentu.ca (Ken Brown)
Subject: execing shell scripts
Organization: Trent University, Ontario
Date: Mon, 16 Nov 1992 18:19:14 GMT

I can see how to set up the link file to run a script from gopher.  What
I gather is that in the gopher data directory there must exist
directories which contain the script/programs desired.  If this is so
and I want to run a csh script called `testme' and chroot is used (the
default) then testme and csh must reside in the gopher tree.  If the
gopher data directory is /usr/local/gopherdata and the script starts
#!/bin/csh then I take it the gopher tree must appear like so;

/usr/local/gopherdata
	|
	bin

and in /usr/local/gopherdata/bin we must have csh and the script testme.

If this is so, how do I stop bin from being seen by clients as a
directory entry in the top level?  After all, /usr/local/gopherdata
contains other entries I wish to display but I don't wnat to display the
bin dir.

Comments, pointes, etc. most welcomed...

-- 
====================================================================
Ken Brown                                       voice: (705)748-1540
Trent University Computing & Telecommunications   fax: (705)748-1246
Peterborough, Ontario, Canada K9J 7B8     internet: kbrown@trentu.ca
From: zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.infosystems.gopher
Subject: Re: Gopher search capability
Date: 20 Nov 92 09:10:30 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

In article <1992Nov19.015617.1781@news.nd.edu>, mandell@bach.helios.nd.edu (Dan
Mandell) writes:
|> At the risk of sounding really stupid, how does one set up gopher to search 
|> for a keyword in a directory or file (or would this require scripting
|> something like a wais search).  We have been experimenting with gopherd
|> running
|> under unix/hpux and have the basics working...but so far I have not been
|> able
|> to provide more than simple file retrieval. How would I set up a search for
|> a
|> specific keyword in a set of documents in one directory?  I was under the
|> impression that gopher had built in search capability.

Basically you need to waisindex the files in the directory and set up a gopher
link of type 7 to the index created. You should look in the manual page for
gopherd for examples on how to do this. 
(of course this requires having the WAIS sruff and that your gopher is
built with WAISINDEX defined)
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre
Date: Sat, 21 Nov 92 08:18:11 PST
From: cook%bluemoon@hub.ucsb.edu (Steve Cook)
Original-To: gopher-news@boombox.micro.umn.edu
Subject: Sizing off-campus access infrastructure
Original-Cc: cook@bluemoon.ucsb.edu
Newsgroups: comp.infosystems.gopher
Distribution: comp

Our campus is reviewing the current infrastructure for
access from off-campus.  I would like to get some feedback
regarding what other campuses have in the way of:       
  1) student/faculty/staff FTE
  2) modem quantity 
  3) modem speeds
  4) pricing models
  5) access time limitations
  6) service and performance expectations

Thanks
Steve Cook
Computing Coordinator, College of Letters and Science
UC Santa Barbara
cook@bluemoon.ucsb.edu
From: singer@almaden.ibm.com (David Singer)
Newsgroups: comp.infosystems.gopher
Subject: Re: CMS Gopher
Date: 24 Nov 92 04:38:45 GMT
Reply-To: singer@almaden.ibm.com (David Singer)
Organization: IBM Almaden Research Center

If you're asking about the Rice CMS Gopher client, the current server
is displayed on the top line of every screen (but there's no way to get
the full path information, at least not without fiddling with the
code).

--  
David Singer -- Internet: singer@almaden.ibm.com   BITNET: SINGER at ALMADEN
                Voice: (408) 927-2509              Fax: (408) 927-4073
(If I needed a disclaimer, I'd put one here.)
From: keijo@kiwi.atk.vtt.fi (Keijo Tuominen)
Newsgroups: comp.infosystems.gopher
Subject: Go500 how to make it work ?
Date: 17 Nov 1992 11:23:18 +0200
Organization: Technical Research Centre of Finland, Computing Services
Distribution: world
NNTP-Posting-Host: kiwi.atk.vtt.fi


I just installed go500 but when there wasn't any advises how to make it
work.

It seems to work file when I telnetd straiht to port it's running
but inside gopher service it don't work.

Any ideas.

My links is:

name=X.500 directory searcheas
Type=1
Port=5555
Path=1/
Host=gopher.vtt.fi
-- 
* Keijo Tuominen; PL 105 Vuorimiehentie *  INTERNET: Keijo.Tuominen@vtt.fi  *
* 02151 Espoo, Finland                  *  BITNET:   atkktu@finvtt.bitnet   *
* Phone: +358 (9)0 456 4295             *  X.400:    C=FI,ADMD=MAILNET      *
* Fax: +358 (9)0 460 648	        *      PRMD=VTT,S=TUOMINEN,G=KEIJO  *
From: Andrew Gilmartin <Andrew_Gilmartin@Brown.Edu>
Newsgroups: comp.infosystems.gopher
Subject: Re: Expiring information ???
Date: 20 Nov 1992 17:59:42 GMT
Organization: Computing & Information Services
Distribution: world
NNTP-Posting-Host: cis_staff-kntx22.cis.brown.edu
X-UserAgent: Nuntius v1.1.1d7
X-XXDate: Fri, 20 Nov 92 18:06:02 GMT

In article <1992Nov20.045322.29298@cc.uow.edu.au> Kirk,
kirk@cc.uow.edu.au writes:

>When this expiry time is reached the information is removed
>and the owner of the files is notified by mail although the notification
is 
>really only the icing on the cake.

We are planning (and currently implementing) this here at Brown
University. The plan is to extend the number of fields in a document's
.cap file to include information for expiring. Fields added in part for
expiration are Creation, Modification, Expiration, and Provider. Each
night I have code that walks gopher space (from the disk side) looking
for documents that are about to expire and those that have expired. Mail
is sent to the document's provider when a document is about to expire or
is expiring that night. Expired documents are moved to the .expired
directory, and a stub is left telling the user community who to contact
for a current version of the document.

When I have a working system I will notify the group.

-- Andrew

-- 
Andrew Gilmartin                        
Computing & Information Services
Brown University

Andrew_Gilmartin@Brown.Edu
(401) 863-7305
Newsgroups: comp.infosystems.gopher
From: schieb@shark.gsfc.nasa.gov (Brian D. Schieber)
Subject: You gotta get this thing?? (was Re: More people would use Gopher
Reply-To: schieb@shark.gsfc.nasa.gov (Brian D. Schieber)
Organization: Oceans & Ice Branch, NASA/GSFC/GSC
Distribution: na
Date: Wed, 18 Nov 1992 15:39:37 GMT

if...)
Keywords: 

What is Gopher? I feel so left out. Why do I want it? I know I want it
because it exists but why else? Is it like ARCHIE? Is it FSP? I have
those and am most happy but now I am distressed because I don't have
gopher. So tell me why I want it.
From: peter@cujo.curtin.edu.au (Peter N Lewis)
Subject: Re: MacToISO utility
Organization: Curtin University of Technology
Date: Sun, 22 Nov 1992 09:11:39 GMT

<BELLVER@EVALUN11.BITNET> writes:
>This Mac program translates an ASCII Macintosh file (type "TEXT") into an
>ISO Latin-1 file. Therefore, international characters can be seen properly
>with an ISO Latin-1 compliant Gopher client, like TurboGopher. Please e-mail
>me any remarks and suggestions.

Shouldn't this be built into any mac gopher servers or clients?  I
thought it was part of the gopher protocol that any text sent across the
wire was to be in ISO format.  If all clients and servers do this there
would be minimal problems (well, about as minimal as we're likely to
get).  Or perhaps I'm confused?
   Peter.
-- 
_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       peter@cujo.curtin.edu.au
GPO Box U1987, Perth WA 6001, AUSTRALIA              Ph: +61 9 368 2055
From: zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.infosystems.gopher
Subject: Re: Anyone running shell  scripts on HPs?
Date: 17 Nov 92 09:26:04 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

In article <1992Nov13.154707.14790@news.nd.edu>, mandell@bach.helios.nd.edu (Dan
Mandell) writes:
|> Has anyone figured out how to get shell scripts running under hpux?
|> I would be gratefull for any tips.

Well, I thought I understood the situation but I'm not so sure now.
In the early experimental days I was running a test server manually (ie. not
under inetd) and with -c on the command line. I could execute shell scripts
any where in the gopher tree so long as they had the executable bits set and
they had the #! at the beginning.

Now, I'm running under inetd but still with -c and now I find it will only
execute scripts if I put them in a directory called bin at the top of the
gopher tree. I should point out that this is with the latest beta 1.1 version
of the server so I'm not sure if this has caused the change.

So all in all scripts _will_ work under HPUX - you just may need to play
around a bit to get it working. Try running with debugging on and checking
the logs; try running non-chroot and see if that makes a difference;
ensure the exceutable bits are on and that the #! is present.

Meanwhile, I'm going to have another look at the source to see if I can
understand what's going on...
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre
From: jqj@duff.uoregon.edu (JQ Johnson)
Newsgroups: comp.infosystems.gopher
Subject: Re: Veronica - problem with servers that impose access restrictions
Date: 23 Nov 1992 21:59:01 GMT
Organization: University of Oregon Network Services
Distribution: world
NNTP-Posting-Host: duff.uoregon.edu

John Line notes that Veronica presents a problem since many gopher servers
allow menu items referring to restricted resources (and hence would appear
in the Veronica listing) but block actual access to the resources.  This
problem should become somewhat less acute when Unix gopherd 1.1 is
deployed, since it will allow secure gopher servers that block the menu as
well.

Even better would be a gopherd that checked access rights when generating
a menu (i.e. a type 1), and did not return items that were inaccessible
to the particular client.



-- 
JQ Johnson				Office: 250E Computing Center
Director of Network Services		Internet: jqj@ns.uoregon.edu
Computing Center, Univ. of Oregon	voice:	(503) 346-1746
Eugene, OR  97403-1212			fax: (503) 346-4397