
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.

Lynx provides the software platform for the Campus Wide Information System 
at the University of Kansas.  If you have access to the Internet you can 
experiment with this Lynx application by telnetting to kufacts.cc.ukans.edu and 
loggin into the account "kufacts".  Exposure to this Lynx application should help 
clarify the description of Lynx presented in this document.



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

	gopher_file_type  gopher_pathname@hostname  port_number

where gopher_file_type is the Gopher-defined file type, and gopher_pathname 
is the name used by a Gopher server to specify one of its files.  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.  

The gopher_path may include the prefix (e.g., "0/") reported by Gopher clients, 
and may also be null.  The Gopyer file type and pathname are separated by a 
dash.  The Lynx command "=" can be used to display the complete Gopher 
pathname of files held by Gopher servers.  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.  



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

			<cs200: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 local file to be displayed can be 
represented as:

link_delimiter   pathname
	token_delimiter   character_count
		token_delimiter   target_string
			end_link_delimiter

which relates to the example as follows:

				<	cs200	: 	 41	:	CS 200	>
			|	|	|	|	|	|	|
		link_delimiter	|	|	|	|	|	|
	pathname	|	|	|	|	|
	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; there is no default.  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.  Both 
character_count and the target_string are optional, and token_delimiters may be 
omitted when unnecessary.

A similar link that references a file residing on a Gopher server

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

can be represented by a slightly more detailed syntax:

link_delimiter   gopher_file_type  gopher_pathname
	@hostname   port_number
		token_delimiter   character_count
			token_delimiter   target_string
				end_link_delimiter

where gopher_pathname, port_number, character_count and target_string are 
all optional.

A variation on the earlier example demonstrates one way the character count 
and target string 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, activating the 
link

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

would start man on the local system.  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 to the section titled "Lynx 
as a Gopher Client".

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 standard local file execution links.  These standard links include 
support for telnet, tn3270 and rlogin, and are defined by specifying one of the 
strings "TELNET", "TN3270", or "RLOGIN" as a program_path argument in the 
local execution link syntax presented above.  Such links should look something 
like:

	<!TELNET  hostname  [port_number]>
	<!TN3270  hostname  [port_number]>
	<!RLOGIN  hostname  [-user=xxxxx]   [-password=yyyyy]>

where the square brackets([]) indicate that an argument is optional.  For example, 
the port_number arguments are not necessary (and the square brackets never 
actually appear in a link).



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 becomes 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 command 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 this role, Gopher plays the role of a vendor-independent distributed 
file system.  However, Lynx can function as a general-purpose Gopher client 
itself when it encounters links conforming to the general syntax:

link_delimiter   gopher_file_type  gopher_pathname
	@hostname   port_number
		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 directories as Lynx hypertext documents.  That means users can examine 
a file listed in a Gopher directory by using the usual interactive arrow key 
sequences to select and activate the desired file.

The link

	<1-1/gopher/gopher_protocol@boombox.micro.umn.edu>More on Gopher

appearing in a file to be displayed by Lynx allows a user to begin a Gopher session 
with the Minnesota server starting with the specified directory, and the link

	<8-PUBLIC@catucsuf.csufresno.edu 0>Connect to online catalog.

instructs Lynx to open a Telnet session to the specified system.  In general, this 
capability allows Lynx document designers to integrate Gopher services with 
Lynx hypertext services.

The following Gopher file types are recognized by Lynx operating as a Gopher 
client:

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 recognition of telnet commands via 
Lynx command line arguments.  For example, it is possible to prevent Lynx from 
executing telnet commands connecting to numeric Internet addresses, or disable 
telnet connections 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] gopher_file_typegopher_pathname@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 
various Lynx commands 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.  Note that users are not required to prepare 
Lynx files using an editor started by Lynx; Lynx files may be 
prepared by any ASCII editor, and this command is presented as 
an attempt to approximate WYSIWYG convenience.

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 are case 
insensitive.


	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_pathname
		@hostname   gopher_port    
			token_delimiter   character_count
				token_delimiter   target_string
					end_delimiter

	Examples:	<0-0/cs200@kugopher1 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
			token_delimiter   target_string
				end_link_delimiter

where program_path may be the pathname of a local command or one of 
TELNET, TN3270, or RLOGIN.  If a local command is specified, 
program_arguments will be passed to it.  If one of the standard programs 
is specified, the program_path and program_arguments should look like:

	TELNET  hostname  [port_number]
	TN3270  hostname  [port_number]
	RLOGIN  hostname  [-user=xxxxx]   [-password=yyyyy]

	Examples:
		<!man -k info:16>More Information
		<!man -k fortran  \>LYNX:16:xlf>For Fortran Info
		<!program_path  pathname\@hostname :99:target_string>
		<!TELNET kufacts.cc.ukans.edu>Connect to the KU CWIS!
		<!TN3270 ukanvm>Connect to the KU VM system.
		<!RLOGIN kufacts -user kufacts>Connect to the KU CWIS!

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>KU Gopher server

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:

	<!events  @kurexec.cc.ukans.edu  -user=rexec>
	<!man  print  \>LYNX  @hostname  -user  info::enq>
		<!xevents -display DISPLAY @kurexec.cc.ukans.edu -user rexec>

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 system named kufacts.cc.ukans.edu.   Users 
without a local account may use this system 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.

January 4, 1993

