From: john@math.nwu.edu (John Franks)
Subject: Re: gopher eval and questions
Reply-To: john@math.nwu.edu
Organization: Dept of Math, Northwestern Univ
Date: Fri, 18 Dec 1992 23:15:40 GMT

In article <=pbrrl+@lynx.unm.edu>, datkins@hydra.unm.edu (Drexel Atkinson CIRT) writes:
> 
> 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 have played with it some, and the best I can seem to do is
> get a telnet run by using type telnet.  Can you execute a program from
> gopher(ie. a suggestion box program or even something as simple as an ls)
> and make it work.  I understand that gopher is really more of an information
> server and was not designed for this, but it would be nice to be able to
> it.  

Exec may be the one aspect of gopher that confuses new gopher admins the
most.  Exec works in gopher as it was designed to, but it cannot do what
many people expect it to be able to do.  

In particular there is no facility for the server to run a program which
behaves interactively with the client or user.  This is not possible given
the stateless nature of the protocol.  This means that "Yes, you can run
a simple 'ls' of a directory known to the server, but no, you cannot run
a suggestion box program which takes input from the user."  

The simplest way to explain this is to observe that as a general rule
(with very few exceptions) the only thing a client can send to a server
is a path to a file on the server.  There is no way for a client to 
send, say, a paragraph of text composed by the user.  You can, of course,
break out of gopher and fire up a telnet session to another program and
do whatever you want there.

Two exceptions to the general rule are slightly relevant to what you
want to do:

1.  A gopher client can send a path to a search program and accompany
it by a term to be searched for.  (This is type 7 among gopher types).
The search program can in fact be any program and doesn't have to
actually search for anything.  Its output will be returned to the
client.  It is rather a hack, but some people have used this to allow
users to give input to a program on the server.  This wouldn't work
very well for a suggestion box, however.  First unless you modify the
client it will prompt the user for a term or phrase to be searched for,
rather than a suggestion.  And second, the search term cannot be more
than a single line (I think).

2.  A second exception involves the "exec" feature which you first
asked about.  Here the client can send a path to a program to be
executed and include arguments to that program.  This is not a very
good way to get user input to the server either.  First the arguments
can't be longer than a line, and second, as far as I know, no clients
are designed to prompt the user to enter these arguments.  Some clients
won't let you do anything at all like this, others will let you edit
the raw path to be sent to the server.

So how can one gain the functionality of something like a suggestion
box?  Well, one option is to wait for Gopher+ which will address these
issues cleanly (see the Gopher+ protocol).  But if you are impatient
and your server runs on a Unix machine, there is a way to get much of
the functionality you want.  First write a suggestion box program which
reads from stdin and writes to stdout.  Run this program under inetd at
some port, say, 2345 on your Unix machine.  In your gopher hierarchy
create a .link entry which looks like

Name=Suggestion Box
Type=8
Port=2345
Path=
Host=your.unix.edu

When the user selects this menu item he actually breaks out of gopher
and telnets to your.unix.edu at port 2345.  However, he does not see a
login message nor is he prompted for a password.  Instead he is
connected to your suggestion box program in an interactive fashion --
he is typing to its stdin and viewing its stdout.  When he exits the
suggestion box program the telnet connection is broken and he returns
to gopher.  I tried this briefly as an experiment a few months ago and
it works fairly well.


-- 

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu