- 1 -


Kansas University Academic Computing Services 

Introduction to the Lynx Hypertext Browser
Version 1.06



Lynx is a program that displays distributed hypertext documents.  It will display 
hypertext documents containing links to files residing on the local system, as 
well as links to files residing on remote systems running Gopher servers.  Lynx 
also performs most Gopher client functions and can process special hypertext 
links that launch programs on both local and remote systems.  These special 
links are used to integrate database systems into the hypertext network.

This document introduces the general notion of "hypertext", as it is used with 
Lynx, and then discusses special capabilities of Lynx, including the ability to 
access files managed by Gopher servers and launch programs on remote systems 
as part of the hypertext network.  This description concludes with summaries of 
Lynx command-line options, interactive commands, link syntax, and 
environment variables.



Basic Lynx

Imagine that you would like to provide access to some enrollment information 
similar to what might be found in a university timetable and course catalog.  
Suppose the timetable information is in the file /info/cs/timetable as follows:


     The Computer Science Department is offering the
   following classes during the Spring Semester of 1992


CS 200   Introduction to Computer Science      MWF  3:30
         104 Strong Hall       A Lovelace

CS 600   Introduction to Data Structures       TR   2:30
         210 Snow Hall         A Turing


Suppose further that you have prepared a description of each course and stored it 
in a file in the directory /info/cs/catalog.  The description of CS200, for example, 
is stored in /info/cs/catalog/cs200; the description of CS600 is stored in 
/info/cs/catalog/cs600, etc.  You can then use Lynx  to display these files as a 
hypertext document by converting the file above to a hypertext file with "links" 
pointing to the files describing each class.  The file above might end up looking 
like:


LINK_DELIMITER = <
END_LINK_DELIMITER = >
OWNER = Michael Grobe
OWNER_ADDRESS = grobe@kuhub.cc.ukans.edu
OWNER_INFO = Academic Computing Services, University of Kansas
PATH = catalog/

     The Computer Science Department is offering the
   following classes during the Spring Semester of 1992


<cs200>CS 200   Introduction to Computer Science      MWF  3:30
         104 Strong Hall       A Lovelace

<cs600>CS 600   Introduction to Data Structures       TR   2:30
         210 Snow Hall         A Turing


The link information was identified by surrounding it with angle brackets (<>).  
These delimiters were selected by defining the LINK_DELIMITER and 
END_LINK_DELIMITER variables in the file preamble.

The file itself is considered to be "owned" by a user named Michael Grobe, whose 
electronic mail address is grobe@kuhub.cc.ukans.edu.  Users may mail messages 
to the file owner within Lynx and Lynx itself may mail messages to the owner in 
response to certain error conditions, such as a link within the file proving to be 
inaccessible.  The owner may be a representative of an organization which will 
be identified using the OWNER_INFO variable.  In this example, the 
organization responsible for the contents of the file is the Computing Services 
group of The University of Kansas.

The directory holding the course descriptions was specified by setting the Lynx 
variable PATH at the beginning of the file.  (Note that the trailing slash is 
necessary in catalog/, since file names in links in the file will be simply appended 
to the PATH string.)

The example document can be displayed by using the Lynx command

		lynx /info/cs/timetable

When Lynx displays the file, the link pointers will not be displayed.  Instead, the 
screen will look something like:


                                                         

where everything inside the shaded area will actually be highlighted on a video 
display.  That is, all the text in the original file between the end of the first link 
and the next newline will be highlighted on the screen.

If the user presses a down arrow at that point, the first link will cease to be 
highlighted and the second link will become highlighted.  Each link defined in 
the file may be selected by using the down-arrow key in this fashion.  (On some 
display devices, and with some versions of Lynx, non-selected links will appear 
in bold face type.)

When the user presses right arrow (or Return), Lynx examines the link 
information for the highlighted link, retrieves the specified file 
(/info/cs/catalog/cs200) and displays it on the screen.

In general, the up and down arrows are used to "select" a topic (represented by a 
highlighted link), and the right-arrow or Return keys are used to "activate" a 
link.  The left-arrow instructs Lynx to deactivate the current link and redisplay 
the previous screen.

A file specified in a link may itself contain links to other files (or even to itself).  
Once the selected file is displayed on the screen, its links may also be selected and 
activated by using the arrow and Return keys.  

Lynx will display a list of all currently active links in response to pressing the 
Backspace or Delete key.  The displayed list is actually a Lynx file itself, where 
each entry is a Lynx link back to an already active link, and may be selected and 
activated again.

The Lynx command "m" positions the user in the first file read by Lynx (the 
"main" menu), and "q" causes Lynx to terminate.  A short help file will be 
displayed in response to the "h" key, and "i" displays an index file containing 
links that move users directly to topics of interest.



Linking Files Stored on Gopher Servers

Gopher is a software package developed at the University of Minnesota that 
provides a number of distributed services.  Its primary function is to provide 
remote access to information stored in a hierarchical file system.  Information 
stored on a particular host system is managed by a Gopher server, which 
responds to access requests by Gopher clients, or by programs like Lynx that can 
emulate Gopher client functions. 

Lynx links can contain file names for files stored on remote Gopher servers.  The 
following version of the timetable file shown above, directs Lynx to take course 
catalog information from a Gopher server running on a system whose Internet 
address is ukanaix.cc.ukans.edu:


LINK_DELIMITER = <
END_LINK_DELIMITER = >
OWNER = Michael Grobe
OWNER_ADDRESS = grobe@kuhub.cc.ukans.edu
OWNER_INFO = Academic Computing Services,University of Kansas

     The Computer Science Department is offering the
   following classes during the Spring Semester of 1992


<0-0/cs200@ukanaix.cc.ukans.edu>CS 200   Introduction to 
Computer Science      MWF  3:30
         104 Strong Hall       A Lovelace

<0-0/cs600@ukanaix.cc.ukans.edu>CS 600   Introduction to Data 
Structures       TR   2:30
         210 Snow Hall         A Turing


The general syntax for a link reference to a file held in a Gopher server is

		pathname@hostname  port_number

where hostname is the IP address of the Gopher server, and port_number is the 
TCP/IP port on which the Gopher server is listening.  The default port number 
for Lynx links of this type is 70 (which is also the default Gopher server port), but 
since this default can be changed by using a Lynx command line option, the port 
should be explicitly specified in these links to assure proper operation no matter 
how Lynx is started.  

The syntax for the Gopher pathname is

		gopher_file_type - gopher_path

where gopher_file_type is the Gopher-defined file type and the gopher_path 
may include the prefix (e.g., "0/") reported by Gopher clients.   The Lynx 
command "=" can be used to display the complete Gopher pathname of files held 
by Gopher servers.  The gopher file type is a one character digit or letter that 
specifies the type of information that will be retrieved.   File type '0' is an ASCII 
file.



Link Display Fields and Target Strings

Aside from specifying files to be displayed, links can also specify the number of 
characters following the link to be highlighted.  In addition, they can include a 
target string that determines which portion of the designated (target) file to 
display first.  For example the link

       <0-0/cs200@ukanaix.cc.ukans.edu:41:CS 200>

specifies that the the first 41 characters following the link should be highlighted, 
and instructs Lynx to search for the string "CS 200" in the target file.

The general syntax for a link pointing to a file to be displayed can be represented 
as:

link_delimiter   pathname@hostname   port_number
	token_delimiter   character_count
		token_delimiter   target_string
			end_link_delimiter

which relates to the example as follows:

	<	0-0/cs200	@ukanaix.cc.ukans.edu	: 	  41	:	CS 200	  >
		|	|	|	|	|	|	|	|
link_delimiter	|	|	|	|	|	|	|
	   pathname	|	|	|	|	|	|
		hostname	|	|	|	|	|
	token_delimiter	|	|	|	|
	character_count	|	|	|
	token_delimiter	|	|
	target_string	|
	end_link_delimiter

In this syntax description the link delimiter must be defined in the lynx file 
preamble.  The end_link_delimiter is a right angle bracket (>) by default, and the 
token_delimiter defaults to a colon (:).  character_count is an integer that 
specifies how many characters following the link end_delimiter are to be 
highlighted.  target_string specifies a string to be searched for in the target file.  
Blanks are allowed in target strings since target strings are delimited by the colon 
and the end_link_delimiter.  Delimiters may be included in target strings by 
escaping them with a backslash (\).  Target string searches are case sensitive, and 
links embedded in target files are not searched for target strings.  

A variation on the earlier example demonstrates one way these new link 
features can be used:


LINK_DELIMITER = <
END_LINK_DELIMITER = >
OWNER = Michael Grobe
OWNER_ADDRESS = grobe@kuhub.cc.ukans.edu
OWNER_INFO = Academic Computing Services,University of Kansas

     The Computer Science Department is offering the
   following classes during the Spring Semester of 1992


<courses:41:CS 200>CS 200   Introduction to Computer Science      
MWF  3:30
         104 Strong Hall       A Lovelace

<courses:40:CS 600>CS 600   Introduction to Data Structures       
TR   2:30
         210 Snow Hall         A Turing


This file assumes that descriptions of each course are collected in a single file 
named courses in the same directory as the timetable file.  When one of the links 
above is activated, the file "courses" will be searched to find the first occurrence 
of the target string.  Then the portion of the target file containing the first 
occurrence will be displayed.

The courses file being used with this timetable file might look like:


OWNER = Michael Grobe
OWNER_ADDRESS = grobe@kuhub.cc.ukans.edu
OWNER_INFO = Academic Computing Services,University of Kansas

CS 200   Introduction to Computer Science

     CS 200 introduces students to the basic concepts of 
computing.  Topics include algorithm development, computer 
organization, and the syntax and semantics of a high-level 
programming language.


CS 600   Introduction to Data Structures

     CS 600 presents data structures and algorithms commonly 
used in computer programming.  Linked lists, arrays, trees, 
and graphs are covered.  Algorithms for creating, filling, 
searching, sorting, traversing these structures are covered.


When activated through the first link, the courses file would appear as follows 
on the screen:


CS 200   Introduction to Computer Science

     CS 200 introduces students to the basic concepts of 
computing.  Topics include algorithm development, computer 
organization, and the syntax and semantics of a high-level 
programming language.


CS 600   Introduction to Data Structures

     CS 600 presents data structures and algorithms commonly 
used in computer programming.  Linked lists, arrays, trees, 
and graphs are covered.  Algorithms for creating, filling, 
searching, sorting, traversing these structures are covered.


Both occurrences of the string "CS 200" would be underlined (or otherwise 
indicated, depending on the video display), since both would be found by the text 
search.

In some cases it might be necessary to move the user to a later occurrence of the 
target string, or to a place in the target document not readily identifiable by a 
string.  To do that it is possible to put hidden targets in Lynx documents.  A 
hidden target is a text string surrounded by target delimiters.  Hidden targets are 
searched during string searches, but are not displayed with the other text in a 
Lynx document.  The following version of the courses file contains hidden 
targets surrounded by specified target delimiters:


TARGET_DELIMITER = [*
END_TARGET_DELIMITER = *]
OWNER = Michael Grobe
OWNER_ADDRESS = grobe@kuhub.cc.ukans.edu
OWNER_INFO = Academic Computing Services,University of Kansas

[*CS200_target*]CS 200   Introduction to Computer Science

     CS 200 introduces students to the basic concepts of 
computing.  Topics include algorithm development, computer 
organization, and the syntax and semantics of a high-level 
programming language.


[*CS600_target*]CS 600   Introduction to Data Structures

     CS 600 presents data structures and algorithms commonly 
used in computer programming.  Linked lists, arrays, trees, 
and graphs are covered.  Algorithms for creating, filling, 
searching, sorting, traversing these structures are covered.


To activate this file, the following links would be used in place of the ones used 
earlier in the timetable file: 

   <courses::CS200_target>CS 200	etc.

   <courses::CS600_target>CS 600	etc.

When activated through the first link, the new courses file would appear as 
follows on the screen:


CS 200   Introduction to Computer Science

     CS 200 introduces students to the basic concepts of 
computing.  Topics include algorithm development, computer 
organization, and the syntax and semantics of a high-level 
programming language.


CS 600   Introduction to Data Structures

     CS 600 presents data structures and algorithms commonly 
used in computer programming.  Linked lists, arrays, trees, 
and graphs are covered.  Algorithms for creating, filling, 
searching, sorting, traversing these structures are covered.


In general, the text in a target file between an activated hidden target and the next 
newline will appear underlined.  Since Lynx searches both text and hidden 
targets when looking for a target string, care must be taken to assure that targets 
are unique to avoid mispositioning.

Note that the default target_delimiter is the two character string left square 
bracket-asterisk ([*), and the default end_target_delimiter is the string asterisk-
right square bracket (*]).  These variables were explicitly defined in this example 
for clarity.  Also, the target_string and character_count entries may be null; 
token delimiters are only required to identify the last non-null parameter in the 
link.

In some cases it is useful to use targets to identify links in a target file.   For 
example, suppose you wish to allow users to move back and forth between the 
timetable information for CS600 to the course description for CS600.  The 
following line could be placed in the timetable file to  move users from the 
timetable information for CS600 to the course description for CS600, and to 
receive transfers from the courses file:

[*CS600_times*]<courses:40:CS600_target>
CS 600   Introduction to Data Structures       TR   2:30

Then the following link could be placed in the courses file to move users from 
the course information for CS 600 to the timetable information for CS 600:

[*CS600_target*]</info/cs/timetable:40:CS600_times>CS 600   
Introduction to Data Structures

If a hidden target is immediately adjacent to an embedded link, the target must 
appear before the link.  



Executing Programs from Links

Lynx can start programs when links are activated.  For example, the link

	<!man -k print :21>Find info on printing

would start man on the local system if activated.  man would operate as usual and 
control would return to Lynx when man terminated.  Users who are preparing 
Lynx documents that do not need to run programs may skip this section and the 
next.

The general syntax for starting programs and scripts on the local system is:

link_delimiter   !   program_path   program_arguments
	token_delimiter   character_count
		end_link_delimiter

or

link_delimiter   !   program_path   program_arguments   \>LYNX
	token_delimiter   character_count
		token_delimiter   target_string
 			end_link_delimiter

In the first case the specified program is started and control reverts to Lynx when 
the program terminates.  In the second case, the program is executed and all 
program output is placed in a temporary file.  (On UN*X systems this file is 
created in /tmp with a unique name based on the PID of the executing program).  
The temporary file is treated as a normal Lynx hypertext file, and may be 
searched for targets specified in the link.  For example, a link like:

	<!man -k print \> LYNX :21:print>Find info on printing

instructs Lynx to execute the command

			man -k print

and capture the resulting output in a temporary file.  Lynx will then display the 
file beginning with the first segment containing the string "print" and underline 
every occurrence of that string.  The temporary file will be deleted when Lynx 
exits. 

Note that any character used by Lynx to delimit link information (e.g., the link 
and target delimiters, the colon, or the at-sign (@) appearing in a command to be 
executed must be preceded by a backslash (\).  This is the reason that >LYNX is 
preceded by a backslash in the example above.

Users creating distributed Lynx documents must exercise caution when executing 
programs within Lynx.  Programs started from Lynx links will execute on the 
same system on which Lynx is running, which is not necessarily the system on 
which the Lynx file is stored.  For instance, the links used as examples in this 
section would probably not execute properly if activated by a Lynx client running 
on a VMS, PC, or Macintosh system (since most of these systems typically do not 
provide a man command).

Users reading distributed documents must also exercise caution.  Suppose, for 
example, and information provider creates a document containing the link

	< !rm * > Click here for a big surprise.

A user activating this link could have files in her current directory deleted.  For 
this reason, local file execution is disabled by default, and users who enable it 
should be careful.

The ability to execute some local commands is so useful, however, that Lynx 
provides several standardized execution link types that start local commands (if 
they exist on the system running the lynx client).  The link types are:
	<!TELNET  host  [port]>
	<!TN3270  host  [port]>
	<!RLOGIN  host  [-user=xxxxx]  [-password=yyyyy]>



Executing Remote Applications

Lynx provides several methods for executing programs running on remote 
servers.   These facilities are provided to help integrate certain kinds of 
information into hypertext documents.  For example, consider providing data 
about campus events through a hypertext document.  Most users will not be 
interested in the entire list of events, nor will they want to list events occurring 
during the same time period.  These conditions make a predefined hypertext 
calendar somewhat unwieldy, and favor (although they do not dictate) an 
interactive database interface.

One way to implement such a system is to define a protocol that Lynx could use 
to request calendar information from a calendar database server.  This approach 
was not taken, mainly because it requires either a single system of considerable 
generality (which would require significant development effort, as well as user 
training), or encourages a proliferation of special purpose protocols for various 
event types and/or administrative units.

Instead, Lynx provides a communications channel to database servers that 
interact directly with the user.  In essence, Lynx makes itself into a conduit 
between the user and a remote server.  (In X windows terms it becomes a display 
server.)  Information providers are then free to develop programs that display 
information in a way that best suits the needs of their clientele.

Lynx employs three standard approaches to remote program execution.  First, 
Lynx provides the RLOGIN local execution link.  An RLOGIN link instructs Lynx 
to open a connection to a remote system and then act as a terminal emulator 
until the remote session is closed.  The syntax for an RLOGIN link is

	<!RLOGIN  host  [-user=xxxxx]  [-password=yyyyy]>

where hostname specifies the remote system housing the program to be 
executed, the -user option is used to specify the account holding the program and 
the -password option specifies a password for the account.  Usually the program 
to be executed will be run as the login shell for the specified account and there 
will be no password required.  Users who login will be able to execute no shell 
commands since the program to be accessed will be started as soon as the user 
logs in, and the session will be terminated as soon as the program is terminated.

To provide a second method to launch a remote application, Lynx supports 
standard TCP/IP socket communications techniques to start and exchange 
information with remote servers.  Each server listens on a defined port on a 
server system until it receives a request to establish a connection from a Lynx 
client process.  Lynx can open connections to programs listening on specific 
TCP/IP ports when processing links like:

link_delimiter   !  port@hostname   end_link_delimiter

When such a link is activated, Lynx makes a connection to the specified port and 
assumes that any text sent through the connection is intended for a VT100 
display.  If Lynx can determine that the user is using a VT100 display device, the 
VT100 commands are simply passed on to the user.  Otherwise, Lynx converts 
VT100 screen control commands to commands suitable for the display device 
actually being used by the user (via calls to the UN*X curses library).

For example, the file below gives users access to a collection of event calendars 
spread across a number of servers:


	  Welcome to the Campus Event Calendar Menu
	Please select an event database from the list below:


	<!4718@ukanaix.cc.ukans.edu>General Campus Events

	<!4377@admin.cc.ukans.edu>Important Academic Dates

	<coll-cal@chomsky.ling.ukans.edu 70>Linguistics Department 
Colloquies

	<!events -display DISPLAY @kurexec.cc.ukans.edu -user 
rexec>City and Regional Calendar


Activating the General Campus Events link would then invoke a screen that 
looks like:

                                             

           Starting search date:  Jul, 17 1992
             Ending search date:  Aug, 17 1992

                       Categories
   * Academic field                   * Museum gallery
   * Academic year                    * Music
   * Athletic                         * Other cultural
   * Ceremonies, recognitions         * Parties
   * Club group meetings              * Recreational
   * Conferences workshops            * Service charitable
   * Film                             * Special academic
   * Holidays                         * Theatre
   * Lecture                          * Training events
   * Local area                       * University governance

            Categories with a '*' are selected.
       Enter 'a' to select all, 'n' to select none.
                  Enter 'q' to exit.


This screen is not a Lynx screen, but is displayed by the event server running on 
ukanaix.cc.ukans.edu.  The user may choose a new date range, or a subset of the 
event categories supported, and then examine the list of events.  When the user 
leaves this program, by typing a "q", control is returned to Lynx.  (Note that Lynx 
commands either will not work, or work differently, while the event program is 
executing.)

Many user programs can be easily set up to communicate with Lynx through this 
interface.  On UN*X systems, a program started by inetd from a script specifying 
VT100 as the display device (using "export TERM=vt100", for example, within a 
ksh script), will have its standard output directed to, and will receive its standard 
input from the (remote) Lynx process.

Lynx itself may be started from inetd in this fashion, and supports a command-
line option (-term=) that can be used to set its terminal type to VT100 under 
these conditions.  For example, the link

		<!lynx  -term=vt100  startfile @ukanaix.cc.ukans.edu>

when executed by a Lynx client could start another version of Lynx running on 
ukanaix that would assume it was talking to a VT100 terminal so that the local 
Lynx client could translate to whatever terminal was actually being used by the 
user.

Programs not started by inetd can be set up to read directly from, and write 
directly to sockets opened in response to Lynx connect requests.  For more 
information on setting programs up to run with inetd, see the man files on 
UN*X systems.

At the present time Lynx does not provide full VT100 emulation for non-VT100 
terminals.  Additional capabilities will be added in later versions.  

Some information providers may have developed, or wish to develop database 
servers that can display their information through the X Windows interface.  To 
support this interface Lynx provides a third method for launching remote 
programs via links of the form


	link_delimiter   !   program_path   program_arguments 
		@hostname   -user   login_name
			token_delimiter   character_count
				end_link_delimiter

When a link of this form is activated, Lynx will essentially login to the account 
login_name on the remote system hostname and execute the program in the file 
program_path.  The arguments specified in program_arguments will be passed 
to the program when it is started.  The address of the user's X windows server 
will be used in place of the variable DISPLAY in a link of this form.  This allows 
a link to pass the X windows server address to the remote program through the 
program's argument list.  The user will then interact with the remote server 
through an X window.

The example Campus Event Calendar Menu file above includes the link:

	<!events -display DISPLAY @kurexec.cc.ukans.edu -user rexec>

which instructs Lynx to login to the account rexec on the system at 
kurexec.cc.ukans.edu and run the events program using the Lynx client's X 
windows address for any X windows displays.

To grant access to all users who may wish to use the database, the account rexec 
would probably be set up to run without a password.  To limit its use, the account 
would also be set up to run a restricted shell that allows only approved 
applications to run within it.  In addition, the account would belong to no 
groups, own no file space and prohibit su access.

Note that any character used by Lynx to delimit link information (e.g., the link 
and target delimiters, the colon, or the at-sign (@) appearing in a command to be 
executed must be preceded by a backslash (\).  



Lynx as a Gopher Client

Lynx utilizes Gopher servers primarily to support distributed hypertext file 
access.  In addition, Lynx can function as a Gopher client itself when it 
encounters links that specify gopher file types according to the general syntax:

	link_delimiter   gopher_file_type - gopher_path@hostname
			token_delimiter   character_count
				token_delimiter   target_string
				end_link_delimiter

For example, the link

   <1-@gopher.micro.umn.edu>Connect to UMN Gopher Server

appearing in a hypertext file allows a user to begin a Gopher session with the 
Gopher server at gopher.micro.umn.edu.  The Lynx interface to Gopher presents 
Gopher files as Lynx hypertext documents.  For example, users can select a file 
from a Gopher directory by using the usual interactive arrow key sequences to 
highlight the desired file. 

The following Gopher file types are recognized by Lynx:

0 	file
1	directory
2 	Computer Services Organization (CSO) directory
4	Macintosh BinHex file
5	PC binary file
7	index file
8	telnet command
G	gif file
I	image file



Creating and Modifying Lynx Hypertext Documents

Lynx files are standard ASCII files, and may be created and modified using any 
ASCII editor.  However, it is also possible to enter an editor while viewing a Lynx 
document, make changes, and return to Lynx to see what effect the changes have 
had.

To enable editing within Lynx, start Lynx with the -editor option, as in the 
command 

		lynx -editor=vi /info/cs/timetable

This command selects vi as the editor to be used in response to the "e" command 
within Lynx.

Two short-cuts exist for the most commonly used UNIX editors, vi and emacs.
"lynx -vi"  and  "lynx -emacs"  will invoke Lynx with the vi, and emacs editors 
respectively.


Lynx as a Hytelnet Engine

Hytelnet is a hypertext database application that provides a large list of telnet sites 
accessible via the Internet.  Hytelnet employs HYPERREZ as a database engine.  
Having evolved partially from a UNIX version of HYPERREZ, Lynx retains the 
ability to process Hytelnet databases with minor modifications (mostly to file 
naming).

To do that, Lynx notices telnet and tn3270 commands embedded in its hypertext 
files, and will present them as links that can be activated by the user if desired.  If 
these links are activated, Lynx will execute the selected telnet command.

By default, Lynx ignores telnet commands if a user is running as a guest process 
and came into the local system from outside the local domain, and also ignores 
telnet commands preceded by a Lynx comment link (so that this feature may be 
selectively disabled).

Users can further disable or restrict Lynx's awareness of telnet commands via 
Lynx command line arguments.  For example, it is possible to restrict Lynx's 
awareness to telnet commands connecting to numeric Internet addresses, or 
disable recognition of telnet commands altogether.

Since Lynx can process distributed hypertext files, it is possible to set up the 
Hytelnet database to run from a Gopher server via Lynx.  Any Lynx client with 
access to the server can then use Hytelnet services.  


The Lynx Command

The basic syntax of the lynx command can be represented as one of the following:

	lynx [options] 
	lynx [options] pathname
	lynx [options] pathname@hostname port_number
	lynx [options] gopher_file_type-gopher_path@hostname port_number

where file is the name of a Lynx hypertext file that enters the hypertext network.  
If no file is specified, Lynx will use a default starting file and base directory 
determined during installation.  If a specified file is local (i.e., no hostname is 
attached) Lynx displays that file and uses the directory in which that file resides 
as the base directory.   If a specified file is not local, the file will be retrieved, and 
only the Gopher server base directory will be relevant to further accesses.

Lynx options can be selected from among the following list, where items 
surrounded by angle brackets (<>) indicate that a substitution must be made (and 
that the angle brackets will not actually appear in the option):

-dir=<base_directory>
	assign a default base directory for Lynx to reference
-telnet 
	disable recognition of embedded telnet commands completely
-name
	disable recognition of embedded telnet commands by Internet name
-number
	disable recognition of embedded telnet commands by Internet 
number
-editor=<editor>
	enable edit mode using the specified editor (vi, ed, emacs, etc.)
-port=<port_number>
	sets the default Gopher port to port_number.  The default port is 70 at 
installation.
-vi
	enable edit mode using the vi editor
-emacs
	enable edit mode using the emacs editor
-term=<terminal_type>
	tell Lynx what terminal type to assume its talking to.   (This may be 
useful for remote execution, when, for example, Lynx connects to a 
remote TCP/IP port that starts a script that, in turn, starts another 
Lynx process.)
-display=DISPLAY 
	set the display variable for X rexeced programs
-exec
	enable local program execution
-noexec
	disable local program execution (default)
-help
	print this usage message
-noprint
	disable print functions
-print
	enable print functions (default)
-verbose
	turns on verbose Gopher information


No options are required, nor is a starting file required.  A space may be 
substituted for any equal sign (=) appearing in the option list above.



Summary of Lynx Interactive Commands

Use the cursor control keys to move around in Lynx. The up and down arrows 
move you from one highlighted link to another.  Use the right arrow (or Return) 
to activate a link, and use the left arrow to return from a link.  The numeric 
keypad, or the numbers mapped to the keypad keys, will also be recognized for 
arrow keys as follows:

	2	down arrow			4	left arrow
	6	right arrow				8	up arrow
	7	go to start of document		1	go to end of document
	9	page up				3	page down

Other commands include:

+ or Space or PgDn or Keypad 3 or Ctrl-F
	Scroll down to the next page

- or b or PgUp or Keypad 9 or Ctrl-B
	Scroll up to the previous page

Home or Keypad 7
	Move to the top of the document

End or Keypad 1
	Move to the end of the document

? or h or Function Key 1

/<string> or s<string>
	Search a selected file for all occurrences of the string "string", and 
display the portion of the  file containing that string.  String 
searches initiated by the user are NOT case sensitive.

Backspace or Delete
	Display a list of links that have already been visited.  The 
displayed links may be selected and activation will result in a new 
display of the previously displayed information.

=
	Display location and ownership information about the file being 
displayed and the currently selected link.

e    
	Enter edit mode using the editor specified on the
	Lynx command line.  This command will not work if editing was 
not enabled via the command line.

i	
	Brings up a local index file containing links that move users 
directly to topics of interest.  Index files are defined by using the 
INDEX environment variable in a Lynx document.  Once defined 
an index file will remain in effect until Lynx terminates or 
another file is defined as Lynx enters another document.

m	
	Return to the main menu (the first screen you see when you start 
Lynx).

n
	Find and display the next occurrence of a search string.

p
	will give users several options for obtaining a copy of the file 
being displayed.  The file may be copied to a file for printing, etc., it 
may be printed (if local installation enabled printing and defined 
printers), and it may be mailed to an address entered by the user.  
If a copy is requested Lynx will query for a local filename, and 
remove all links and targets  prior to copying the document to the 
destination file.   If a full path is not given, Lynx will use the 
directory it was started in.  If that directory is not writeable, Lynx 
will try to copy the file to the user's home directory.

q or Ctrl-D
	Quit Lynx.

r or c
	Send a remark or comment to the designated owner of the file 
being displayed.

Ctrl-R
	Refresh the current display.  This is sometimes useful to remove 
the disruptive effects of error messages.



Summary of Lynx Environment Variables

The following table lists the Lynx environment variables and shows their default 
values when applicable.  Note that Lynx environment variable names actually 
conform to a very loose syntax.  For example, the underscores (_) are not 
necessary, other text may occur between keywords, variable names are case 
insensitive, and the equal signs (=) are not required.


	Lynx Variable	Default Value

	%%LINK_DELIMITER	\0  (null)
	%%END_LINK_DELIMITER	>

	%%TOKEN_DELIMITER	:

	%%TARGET_DELIMITER	[*
	%%END_TARGET_DELIMITER	*]

	%%OWNER	none
	%%OWNER_ADDRESS	defined by system administrator
	%%OWNER_INFO	none

	%%PATH	Set at program installation
	%%TITLE	none
	%%INDEX	none


Lynx environment variables must appear at the beginning of a Lynx document.  
The first line in a document that does not define a Lynx variable terminates the 
list of variable definitions, unless it begins with two consecutive percent signs 
(%%).  Lines beginning with percent signs may contain new variable definitions.  
(This feature was added to allow initial versions of Lynx to read documents 
prepared for future versions of Lynx.)


Summary of the Lynx Link Syntax

This section presents the syntax for links recognized by Lynx.  Under some 
conditions Lynx will ignore links that fit the syntax as it is presented below.  For 
example, if any of the defined data fields (filenames, character counts, or target 
strings) exceed certain limits, Lynx will treat a link as non-link text.

Link to a local file:

	link_delimiter   pathname   token_delimiter   character_count
		token_delimiter   target_string
			end_delimiter

	Example:		<pathname:99:target_string>


Link to a file on a Gopher server:

link_delimiter   gopher_filetype - gopher_path@hostname   		
		gopher_port    token_delimiter   character_count
			token_delimiter   target_string
				end_delimiter

	Example:		<0-pathname@hostname  70:99:target_string>
			<0-0/IBM/COMPARISION@gopher.micro.umn.edu  153>

The default gopher_port is 70, but may be reset on the Lynx command 
line, so it should be explicitly specified.


Comment link:

	link_delimiter   *   comment_text   end_delimiter

	Example:		<*  This file points to files on the database server.  >


Link to execute a local shell command or script:

	link_delimiter   !   program_path   program_arguments
		token_delimiter   character_count
			end_link_delimiter

	Examples:
		<!program_path  arguments:99:target_string>
		<!program_path  arguments  \>LYNX:99:target_string>
		<!program_path  pathname\@hostname :99:target_string>
		<!TELNET  hostname [port]>
		<!TN3270  hostname [port]>
		<!RLOGIN  hostname  [-user=xxxxx] [-password=yyyyy]>

The string LYNX appearing in program_arguments as \>LYNX will be 
replaced with the name of a local temporary file.   Any character used by 
Lynx to delimit link information (e.g., the link and target delimiters, the 
colon, or the at-sign (@) appearing in a command to be executed must be 
preceded by a backslash (\).  The string DISPLAY appearing in 
program_arguments will be replaced with the user's X windows display 
address if it can be determined (usually from the execution environment 
variable DISPLAY on UN*X systems).  


Link to connect to a program listening on a (remote) socket:

	link_delimiter   !  port@hostname   end_delimiter

	Example:	<!7777@ukanaix.cc.ukans.edu:99>


Link to connect to a gopher server:

link_delimiter   1-@hostname
		token_delimiter   character_count
			token_delimiter   target_string
			end_link_delimiter

	Examples:	<1-@ukanaix.cc.ukans.edu  70:99:target_string>

The default value of gopher_port is 70 for these links, but it may be reset 
on the Lynx command line, so the port should be explicitly specified to 
avoid confusion.


Link to execute a remote program (particularly an X Windows client):

	link_delimiter   !   program_path   program_arguments 
		@hostname   -user login_name
			token_delimiter   character_count
				token_delimiter   target_string
					end_link_delimiter

	or

	link_delimiter   !   program_path   program_arguments  
		@hostname   -user login_name   -password   login_password
			token_delimiter   character_count
				token_delimiter   target_string
					end_link_delimiter

	Examples:

		<!program  @lynx.cc.ukans.edu  -user=rexec>
		<!man  print  \>LYNX  @hostname   -user  info:99:target>
			<!events -display DISPLAY @kufacts.ukans.edu -user  info>


The string DISPLAY appearing in program_arguments will be replaced 
with the user's X windows display address if it can be determined (usually 
from the execution environment variable DISPLAY on UN*X systems).  
Likewise, the string LYNX appearing in program_arguments as \>LYNX 
will be replaced with the name of a local temporary file.  Any character 
used by Lynx to delimit link information (e.g., the link and target 
delimiters, the colon, or the at-sign (@) appearing in a command to be 
executed must be preceded by a backslash (\).


Links reserved for future development:

	link_delimiter   #	Text	end_delimiter

	link_delimiter   %	Text	end_delimiter

	Examples:	<#   Reserved for future use.   >
			<%   Reserved for future use.   >



Lynx Development History

Lynx grew out of efforts to build a campus-wide information system (CWIS) at 
The University of Kansas.  Lynx clients provide a user-friendly hypertext 
interface for users on a variety of platforms (UN*X, VMS, and MS-DOS), and 
allow information providers to publish information located on any platform 
that can run a Gopher server (including UN*X, VMS, VM/CMS and Macintosh).  
Providers retain complete control over their information, but may receive 
comments and suggestions from users running Lynx on client systems.  The 
major limitation of using Lynx in this environment is that Lynx currently 
supports only textual information.

At The University of Kansas, Lynx is used in several different ways to give users 
access to a campus-wide information system.  First, it is run on several local 
clients from a script named "kufacts" (or something similar) that points to the 
starting file located on a local server.  Second, it runs whenever a user logs into 
an account called "kufacts" on a server named kufacts.cc.ukans.edu.   Users 
without a local account may use this server to explore Lynx.

Lynx was designed by Lou Montulli, Charles Rezac and Michael Grobe of  
Academic Computing Services at The University of Kansas.  Lynx was 
implemented by Lou Montulli with code contributed by Earl Fogel of Computing 
Services at the University of Saskatchewan, who implemented HYPEREZ in the 
UN*X environment, by the authors of the UN*X Gopher client, and by Vijay 
Kolli, of The University of Kansas, who implemented the VT100 translation to 
curses that is required for remote program execution (by programs started via 
rexec, inetd, or by direct socket connects).  Neal Erdwien, of Kansas State 
University, demonstrated the use of electronic mail to let users communicate 
with information providers in his UNICORN system.

This document was written by Michael Grobe, who may be reached for 
comments at grobe@kuhub.cc.ukans.edu.

December 18, 1992

