diff options
| author | Thomas E. Dickey <dickey@invisible-island.net> | 1996-09-02 19:39:24 -0400 |
|---|---|---|
| committer | Thomas E. Dickey <dickey@invisible-island.net> | 1996-09-02 19:39:24 -0400 |
| commit | e087f6d44e87f489fcb3056e86319ebba4218156 (patch) | |
| tree | d045b58011bfbbf5186d34c4fed9e0dedb363275 /lynx_help/lynx_url_support.html | |
| download | lynx-snapshots-e087f6d44e87f489fcb3056e86319ebba4218156.tar.gz | |
snapshot of project "lynx", label v2_6
Diffstat (limited to 'lynx_help/lynx_url_support.html')
| -rw-r--r-- | lynx_help/lynx_url_support.html | 493 |
1 files changed, 493 insertions, 0 deletions
diff --git a/lynx_help/lynx_url_support.html b/lynx_help/lynx_url_support.html new file mode 100644 index 00000000..8c0ed4f6 --- /dev/null +++ b/lynx_help/lynx_url_support.html @@ -0,0 +1,493 @@ +<!DOCTYPE html public "-//IETF//DTD HTML 3.0//EN"> +<HTML> +<HEAD> +<TITLE>URL Schemes Supported in Lynx</TITLE> +<LINK rev=made href="mailto:lynx-dev@sig.net"> +</HEAD> + +<BODY> +<BANNER> +<em>[</em><a href="#http">http, https</a> <em>|</em> +<a href="#telnet">telnet, tn3270, rlogin</a> <em>|</em> +<a href="#gopher">gopher</a> <em>|</em> +<a href="#file">file</a> <em>|</em> +<a href="#ftp">ftp</a> <em>|</em> +<a href="#wais">wais</a> <em>|</em> +<a href="#news">news, nntp, snews</a> <em>|</em> +<a href="#mailto">mailto</a> <em>|</em> +<a href="#finger">finger</a> <em>|</em> +<a href="#cso">cso</a> <em>|</em> +<a href="#exec">lynxexec, lynxprog</a> <em>|</em> +<a href="#cgi">lynxcgi</a><em>|</em> +<a href="#internal">internal</a><em>]</em> +</BANNER> + +<H1><em>URL Schemes Supported in Lynx</em></H1> + +Lynx handles a number of URL types, that are enumerated below. For +more details about URLs (Uniform Resource Locators) see <em>RFC1738</em>: +<ul plain> +<li><a href="http://www.w3.org/pub/WWW/Addressing/rfc1738.txt" +>http://www.w3.org/pub/WWW/Addressing/rfc1738.txt</a> +<li><a href="ftp://ds.internic.net/rfc/rfc1738.txt" +>ftp://ds.internic.net/rfc/rfc1738.txt</a> +</ul> + +<p>Lynx resolves partial or relative URLs in documents with respect to +the BASE if one was specified, otherwise with respect to the document's +absolute URL, using the rules described in <em>RFC1808</em>: +<ul plain> +<li><a href="http://www.w3.org/pub/WWW/Addressing/rfc1808.txt" +>http://www.w3.org/pub/WWW/Addressing/rfc1808.txt</a> +<li><a href="ftp://ds.internic.net/rfc/rfc1808.txt" +>ftp://ds.internic.net/rfc/rfc1808.txt</a> +</ul> + +<p>When entering a URL on the command line to be used as the +<em>startfile</em>, or at the prompt for a '<em>g</em>'oto entry, a +partial host field can be used and the scheme field can be omitted if +the scheme and fully qualified domain name can be constructed internally +by using the URL_DOMAIN_PREFIXES and URL_DOMAIN_SUFFIXES definitions in +the Lynx configuration file. See the explanation of those definitions +and their use in your <em>lynx.cfg</em>. For example, <em>wfbr</em> will +be treated as <em>http://www.wfbr.edu/</em>, and <em>wfbr/dir/lynx</em> +will be treated as <em>http://www.wfbr.edu/dir/lynx</em>, but +<em>gopher.wfbr.edu/11/_fileserv/_lynx</em> will be treated as +<em>gopher://gopher.wfbr.edu/11/_fileserv/_lynx</em>. For files or +directories on the local host, a tilde (<em>~</em>) is expanded to +the path of the account's login directory, e.g., <em>~/foo</em> will +be expanded to <em>file://localhost/your/login/directory/foo</em>. +The tilde expansion is done homologously on Unix and VMS. On VMS, +Lynx also will expand any file or directory spec recognizable to +DCL into a valid URL, e.g., <em>[]</em> will be expanded to +<em>file://localhost/current/default/directory</em>. These expansions +are <em>SOLELY</em> for <em>startfile</em> or '<em>g</em>'oto entries! +Any partial or relative URLs within HTML documents are resolved +according to the rules specified in RFC1808. +<HR WIDTH="100%"> + +<H2><a name="http">The <em>http</em> and <em>https</em> URLs:</a></H2> + +Lynx handles http URLs exactly as specified in RFC1738. The format +is:<BR> +<tab indent="12"><em>http://host:port/path?searchpart#fragment</em><BR> +where <em>:port</em> is optional and defaults to <em>:80</em>, +<em>/path</em> if present is a slash-separated series of symbolic +elements, and <em>?searchpart</em> if present is the query for an ISINDEX +search or the content of a FORM with METHOD="GET". The <em>#fragment</em> +field if present indicates a location in the document to seek for display, +based on a NAME-ed anchor or an ID attribute within the document, and is +technically an instruction rather than part of the URL. Lynx will treat +ID attributes as NAME-ed anchors for all tags in the BODY of a document +which can correspond to positions in the rendering of the document. + +<p>The https URL has the same format, but the default port is +<em>:443</em>. Patches for support of https URLs and the CONNECT +procedure are available for qualified recipients via links in the +<a href="http://www.nyu.edu/pages/wsn/subir/lynx.html">Lynx Enhanced +Pages</a>. US Export laws and associated red tape pose severe +impediments to inclusion of this support in the general distributions +of freeware WWW clients such as Lynx. Sorry. +<HR WIDTH="100%"> + +<H2><a name="telnet" +>The <em>telnet</em>, <em>tn3270</em>, and <em>rlogin</em> URLs:</a></H2> + +A <em>telnet</em> URL generally results in Lynx spawning a telnet +session. Lynx implements the complete telnet URL scheme, i.e.:<BR> +<tab indent="12"><em>telnet://user:password@host:port</em> + +<p>The <em>user</em> and/or <em>:password</em> fields may be omitted, and +the <em>@</em> should be omitted if neither is present. The port defaults +to <em>:23</em> when omitted in the URL. + +<p>A <em>tn3270</em> or <em>rlogin</em> URL is specified equivalently, +and similarly spawns a tn3270 or rlogin session. The actual behavior +is dependent on the TCP-IP software installed on the local and target +hosts. + +<p>It is unwise to include the <em>:password</em> field except for +URLs which point to anonymous or other public access accounts, and +for most TCP-IP software you will be prompted for a password whether +or not one was included in the URL. +<HR WIDTH="100%"> + +<H2><a name="gopher">The <em>gopher</em> URL:</a></H2> + +The gopher URL takes the form:<BR> +<tab indent="12"><em>gopher://host:port/gopher-path</em><BR> +where <em>:port</em> is optional and defaults to <em>:70</em>, and the +<em>/gopher-path</em> is opaque (not fully equivalent to the +slash-separated series of symbolic elements of http paths) as explained +in RFC1738. Typically, the gopher-path consists of a <em>gophertype</em> +indicating the file or service type (e.g., <em>0</em> or <em>I</em> for +plain text or an image, respectively, <em>7</em> for a search, or <em>1</em> +for a directory), followed by a platform-specific <em>selector</em>. Any +reserved characters in the selector should be hex escaped (<em>%hh</em>), +including slashes, although hex escaping of slashes is not required by Lynx +in gopher URLs. + +<p>Lynx does not overtly support the gopher+ protocol, and does not +represent itself as gopher+ capable when communicating with gopher +servers. Lynx might transmit any (hex-escaped-tab-separated) extended +gopher+ fields in a URL if an author included them in a document, but is +likely to mishandle what the gopher server returns in such cases, and would +not generate and transmit them itself. For pre-formed URLs to submit gopher +searches, it may be better to use a <em>?</em> rather than hex-escaped tab +(<em>%09</em>) as the separator for the <em>searchpart</em> in the +<em>selector</em>, e.g.:<BR> +<em>gopher://gopher.wfbr.edu/77/_shell/search.shell%20/_shell/walker?lynx*</em> +Lynx will handle the <em>%09</em> if you use that instead of <em>?</em>, +but other WWW clients may mishandle it. + +<p>For the <em>gophertype</em> which signifies HTML (<em>h</em>), if the +<em>selector</em> begins with <em>GET%20/</em> Lynx will convert the gopher +URL to an http URL, e.g.:<BR> +<tab indent="12"><em>gopher://www.wfbr.edu:80/hGET%20/</em><BR> +will become:<BR> +<tab indent="12"><em>http://www.wfbr.edu/</em><BR> +The port field will be retained if it is not <em>:80</em>, and will default +to <em>:70</em> if it was defaulted originally. These conventions were +adopted during development of the University of Minnesota gopher software +to facilitate the offering of links to MIME-capable http servers in the +listings returned by gopher servers, but should be considered Lynxisms +and UMN Gopherisms. +<HR WIDTH="100%"> + +<H2><a name="file">The <em>file</em> URL:</a></H2> + +The file URL is used to retrieve files or generate a directory listing +on the local host. The host field can be <em>localhost</em> or a domain +name for the local host:<BR> +<tab indent="12"><em>file://localhost/path</em><BR> +If you do not use <em>localhost</em> or a domain name for the local host, +Lynx will substitute <em>ftp://</em> for <em>file://</em> and treat it +as an ftp URL. + +<p>The <em>/path</em> is treated as originating at the root, unless +you include a tilde (<em>~</em>), e.g.:<BR> +<tab indent="12"><em>file://localhost/~/foo</em> +<tab indent="60">will be converted to:<BR> +<tab indent="12"><em>file://localhost/your/login/directory/foo</em><BR> +The latter feature is a Lynxism, is done homologously on Unix and VMS, +and should be used ONLY in local documents intended for Lynx. + +<p>On VMS, the first element of the path, if not a tilde, is assumed to +be a device, e.g.:<BR> +<tab indent="12" +><em>file://localhost/www_root/directory/filename.suffix</em><BR> +should be used for: <em>www_root:[directory]filename.suffix</em><BR> +If you are unsure how to specify a file URL in local documents on +VMS, invoke Lynx with the desired file or directory as the +<em>startfile</em> using any spec acceptable to DCL, and then +use the <em>showinfo</em> command (<em>=</em>) to see the file +URL which Lynx created for it. +<HR WIDTH="100%"> + +<H2><a name="ftp">The <em>ftp</em> URL:</a></H2> + +The ftp URL has the general format:<BR> +<tab indent="12" +><em>ftp://username:password@host:port/path;type=[D,I, or A]</em><BR> + +<p>The default port is <em>:21</em> and the default <em>username</em> +is <em>anonymous</em>. If <em>username</em> is included but not +<em>:password</em>, Lynx will prompt you for the password. This is +recommended, as otherwise the URL will have it completely unencrypted. +Do not include the <em>@</em> if neither <em>username</em> nor +<em>:password</em> is included. For anonymous ftp, Lynx uses your +<em>personal_mail_address</em> (user@host) as the <em>:password</em> +if it has been defined via the '<em>o</em>'ptions menu. Otherwise, +Lynx uses the dummy password <em>WWWUser</em>. + +<p>The <em>;type=</em> parameter can be used with value <em>D</em>, +<em>I</em>, or <em>A</em> to force handling of the URL as, respectively, +a directory listing, binary file, or ASCII file. The Lynx ftp gateway +normally determines this itself, but the parameter can be used if the +internal procedure draws an incorrect inference about the nature of +the ftp URL. + +<p>The <em>/path</em> is treated according to RFC1738 for VMS +and VM/CMS ftp servers. The lead slash (<em>/</em>) is treated purely +as a separator, not as a designator for the root, and the <em>path</em> +string if present is treated as in or under the login directory. For +VMS ftp servers, if you wish to have the first element treated as a +device rather than file or subdirectory name, begin it with a hex-escaped +slash (<em>%2f</em>), e.g.:<BR> +<tab indent="12"><em>ftp://user@myhost/%2fsys$common/syshlp</em><BR> +can be used for a listing of sys$common:[syshlp]<BR> +Also, on VM/CMS ftp servers, if the <em>path</em> string begins +with <em>vmsysu%3a</em> it receives special handling as an SFS +path, e.g.:<BR> +<tab indent="12"><em>ftp://ubvm.cc.buffalo.edu/vmsysu%3alistserv.webshare</em> + +<p>For Unix and Unix-emulation ftp servers, RFC1738 is not respected +and the lead slash is treated as the root, i.e., the <em>/path</em> is +handled equivalently to that in file URLs. The distinction is +irrelevant for anonymous ftp, but matters when using ftp for +non-anonymous accounts. If you are using ftp with a Unix server and +do wish to get a listing of the login directory or have the <em>path</em> +string treated as a file or path under the login directory, include a +tilde (<em>~</em>) as for <a href="#file">file</a> URLs, e.g.:<BR> +<tab indent="12"><em>ftp://user@myhost/~</em> +<HR WIDTH="100%"> + +<H2><a name="wais">The <em>wais</em> URL:</a></H2> + +The wais URL is used to retrieve resources using the Wide Area Information +System protocol. The format is:<BR> +<tab indent="12"><em>wais://host:port/database</em><BR> +<tab indent="12"><em>wais://host:port/database?wais_query</em><BR> +<tab indent="12"><em>wais://host:port/database/wais_type/wais_path</em><BR> +where <em>:port</em> defaults to <em>:210</em> + +<p>Direct wais support is built into Lynx for VMS, and can be compiled +into Lynx on Unix. If direct wais support is not available, Lynx uses +the W3C wais gateway. + +<p>If only a <em>database</em> is indicated in the URL, Lynx returns +an ISINDEX cover page for searching that <em>database</em>, and will +submit your search with the <em>wais_query</em> appended. Lynx will +convert the server's reply into a hit list with URLs that include the +<em>wais_type</em> and <em>wais_path</em> for retrieving items from +the hit list. +<HR WIDTH="100%"> + +<H2><a name="news" +>The <em>news</em>, <em>nntp</em>, and <em>snews</em> URLs:</a></H2> + +The news and nntp URLs are handled by Lynx as specified in RFC1738, but +for compatibility with other clients, Lynx allows inclusion of host and +port fields in news URLs, which properly should be used <em>only</em> in +nntp URLs. If not included in news URLs, Lynx will use the nntp server +pointed to by the NNTPSERVER environment variable or configuration symbol +(see lynx.cfg), with default port <em>:119</em>. A host field must be +included in nntp URLs, and the port field is optional with the same default. +Patches for support of snews URLs are available to qualified recipients via +links in the <a +href="http://www.nyu.edu/pages/wsn/subir/lynx.html" +>Lynx Enhanced Pages</a> but cannot be included in the general +distribution (sorry, see <a href="#http">http and https</a>). +The formats are:<BR> +<tab indent="12"><em>news:newsgroup</em> <tab +id="ng">(retrieves list of messages in newsgroup)<BR> +<tab indent="12"><em>news:messageID</em> <tab +to="ng">(retrieves the message)<BR> +<tab indent="12"><em>news:*</em> <tab +to="ng">(retrieves list of all available newsgroups)<BR> +<tab indent="12"><em>nntp://host:port/newsgroup</em><BR> +<tab indent="12"><em>nntp://host:port/messageID</em><BR> +<tab indent="12"><em>nntp://host:port/*</em><BR> +(snews same as nntp, but the default port is <em>:563</em>) + +<p>The <em>messageID</em> is the message's unique identifier, consisting +of an identification string and the host of origin for the message +(<em>ident_string@origin_host</em>). + +<p>Lynx also supports wildcarding via an asterisk for listings of news +hierarchies or sub-hierarchies, e.g.:<BR> +<tab indent="12"><em>news:comp.infosystems.*</em><BR> +<tab indent="12"><em>nntp://host:port/comp.infosystems.*</em><BR> +(snews same as nntp, but the default port is <em>:563</em>)<BR> +This is not in RFC1738 and may not be supported by all other clients. + +<p>For news URLs, Lynx allows you both to <em>reply</em> to the author +of a message via email, and, if news posting has been enabled, to send +a <em>followup</em> message to the newsgroup. Only email replies to the +author are permitted via nntp URLs. + +<p>Lynx converts any strings in news messages which appear to be a URL +with a supported scheme into a link for accessing that URL. + +<p>Lynx also supports the newsgroup and message number URL scheme:<BR> +<tab indent="12"><em>news:newsgroup/startNo-endNo</em> <tab +id="ngno">(lists message range in newsgroup)<BR> +<tab indent="12"><em>news:newsgroup/messageNo</em> <tab +to="ngno">(retrieves the message by number)<BR> +<tab indent="12"><em>nntp://host:port/newsgroup/startNo-endNo</em><BR> +<tab indent="12"><em>nntp://host:port/newsgroup/messageNo</em><BR> +(snews same as nntp, but the default port is <em>:563</em>)<BR> +Use of this scheme is not recommended, because the message numbers +are specific to each nntp server, unlike the unique identifiers for +news messages. +<HR WIDTH="100%"> + +<H2><a name="mailto">The <em>mailto</em> URL:</a></H2> + +The mailto URL is used to provide links that when activated can be +used to send a comment or the content of a FORM to an Internet email +address (user@host). The format is:<BR> +<tab indent="12"><em>mailto:user@host</em> + +<p>The description of the mailto URL in RFC1738 has been interpreted by +some as allowing only a single recipient, but Lynx invented the mailto URL, +has always supported a series of user@host addresses as a comma-separated +list, and still does. For compatibility with Explorer, Lynx also accepts +a semi-colon-separated list. + +<p>For compatibility with Netscape, Lynx parses any +<em>?subject=The%20Subject</em> appended to the URL, trims the URL +at the <em>?</em>, and uses the value as the default Subject: for +the message or FORM content mailing. This is not recommended practice. +The preferred way to indicate the default Subject: for a LINK or Anchor +with a mailto HREF, or a FORM with a mailto ACTION, is via a TITLE +attribute with the subject string as its value, e.g.:<BR> +<tab indent="12"><em><LINK <tab id="rev">REV="made"<BR> +<tab to="rev">HREF="mailto:me@myhost,her@herhost" TITLE="The Subject"></em> + +<p><tab indent="12"><em><A +HREF="mailto:user@host" TITLE="The Subject">...</A></em> + +<p><tab indent="12"><em><FORM <tab id="met">METHOD="post" +ENCTYPE="text/plain"<BR> +<tab to="met">ACTION="mailto:WebMaster@host" TITLE="The Subject"><BR> +<tab indent="14">...<BR> +<tab indent="12"></FORM></em> + +<p>Note that a TITLE attribute for FORM has been proposed but not included +in any HTML specifications or drafts, and should be considered a Lynxism +until/unless it is. Some clients use a SUBJECT attribute for this purpose +in FORM tags, and Lynx recognizes that as a synonym for TITLE. + +<p>If <em>ENCTYPE="text/plain"</em> is specified for a FORM with a mailto +ACTION, Lynx will not hex escape the name=value pairs, and will use physical +newlines instead of '<em>&</em>' or '<em>;</em>' to separate the pairs, +so that the content will be readable directly. Otherwise, Lynx will mail +the content with the default:<BR> +<tab indent="12" +><em>ENCTYPE="application/x-www-form-urlencoded"</em> <tab id="enc">('<em +>&</em>' separates pairs)<BR> +or:<BR> +<tab indent="12" +><em>ENCTYPE="application/sgml-form-urlencoded"</em> <tab to="enc">('<em +>;</em>' separates pairs)<BR> +if the latter was indicated. + +<p>Note that when mailing FORM content Lynx wraps any lines longer than 78 +characters, to avoid buffer overflows in mail software and to ensure reliable +transmission across gateways. If the ENCTYPE was not <em>text/plain</em>, +any script which decodes the mailed content should ignore the physical +newlines and recognize only hex escaped newline characters as intended +to be present in the decoded content. +<HR WIDTH="100%"> + +<H2><a name="finger">The <em>finger</em> URL:</a></H2> + +Lynx has full support for the finger protocol, but a format for finger +URLs has not yet been adopted by the IETF. The formats supported by Lynx +therefore include every possibility not inconsistent with RFC1738, +including: + +<pre> + finger://host finger://@host + finger://host/ finger://@host/ + finger://host/%2fw finger://@host/w + finger://host/w finger://host/w/ + finger://host/username[@host] finger://username@host + finger://host/username[@host]/ finger://username@host/ + finger://host/w/username[@host] finger://username@host/w + finger://host/%2fw%20username[@host] finger://host/username[@host]/w + finger://host/w/username +</pre> + +<p>Activating a finger URL will send a request to the finger server via +port 79 on the host specified. You can include <em>:79</em> in the URL, +but no other value is allowed. The <em>/w</em> or <em>/%2fw</em> is used +to request a full report for finger servers which support it, and is not +case sensitive (i.e., can be <em>/W</em> or <em>/%2fW</em>). Any strings +in the report which appear to be a URL with a supported scheme will be +converted into a link for accessing that URL. + +<p>An alternative way to access finger servers is via gopher URLs with +port 79 and the plain text (<em>0</em>) <em>gophertype</em> specified:<BR> +<em>gopher://host:79/0</em><BR> +Lynx will handle such URLs equivalently to overt finger URLs, including +creation of links for any strings which appear to be supported URLs. +<HR WIDTH="100%"> + +<H2><a name="cso">The <em>cso</em> URL:</a></H2> + +The cso URL is intended to provide a gateway to CSO/PH (QI) servers. +The requests are made on port 105 by default (<em>:105</em>), with the +following overt cso URL format:<BR> +<tab indent="12"><em>cso://host</em><BR> + +<p>You also can use a gopher URL format with port 105 and the CSO +(<em>2</em>) <em>gophertype</em> specified:<BR> +<tab indent="12"><em>gopher://host:105/2</em> + +<p>Lynx will parse the stream returned by the server for the above +URLs and create a FORM for submitting additional requests (searches) +to the server. Any strings in the reports returned for these requests +(searches) which appear to be a URL with a supported scheme will be +converted into a link for accessing that URL. +<HR WIDTH="100%"> + +<H2><a name="exec">The <em>lynxexec</em> and <em>lynxprog</em> URLs:</a></H2> + +If execution of spawned commands has been enabled in your Lynx image, the +lynxexec and lynxprog URLs can be used to execute arbitrary system commands +or invoke system utilities. Any system command and associated switches +or qualifiers can be used, with the syntax appropriate for a shell running +Lynx on Unix, or for DCL on VMS, e.g.:<BR> +<tab indent="12"><em>lynxexec:dir/date/size foo:[blah]</em> <tab +id="listing">(VMS)<BR> +<tab indent="12"><em>lynxexec:ls -l /foo/blah</em> <tab +to="listing">(Unix)<BR> +<tab indent="12"><em>lynxprog:news</em><BR> +(Note, however, that restrictions on acceptable commands or utilities +may be imposed by the system administrator.) + +<p>You optionally can include <em>//localhost/</em> in the URL, between the +scheme field and the command, but that is always implied. The lynxexec +and lynxprog URLs differ only in that with lynxexec you are prompted to +enter <em>RETURN</em> before Lynx clears the screen and restores the +previously displayed document, so that you can read any screen output +generated by the spawned command, whereas no such pause is imposed upon exit +from the utility invoked via lynxprog. + +<p>These are Lynxisms and should be used only in local documents intended +solely for Lynx. +<HR WIDTH="100%"> + +<H2><a name="cgi">The <em>lynxcgi</em> URL:</a></H2> + +The lynxcgi URL is implemented only on Unix, can be used as the +ACTION for a FORM, and if enabled in your Lynx image has the format:<BR> +<tab indent="12"><em>ly<tab id="lh"> +nxcgi://localhost/path_to_CGI_script</em><BR> +<tab to="lh">where <em>//localhost/</em> is optional and always implied. +The output of the script must be text/html and is rendered and displayed +by Lynx. (Note that restrictions on acceptable paths can be imposed +by the system administrator.) + +<p>This is a Lynxism and should be used only in local documents intended +solely for Lynx. + +<p>On VMS, you are advised to use the threaded OSU http server, available +from <a href="ftp://osu.edu" +>ftp://osu.edu</a> as freeware, if your site does not already have an http +server. It can be installed as a purely local script server, and is far +more efficient and comprehensive than any code which might be incorporated +within Lynx. +<HR WIDTH="100%"> + +<H2><a name="internal">The <em>LYNXfoo</em> internal URLs:</a></H2> + +Lynx uses a variety of internal URL schemes as structured stream +objects for communication among its display modules. If you discover +what they are, and are tempted to use them externally in documents, +find the self-restraint to <em>resist</em> that temptation!!! + +<p>For example, tempting though it might be, do <em>not</em> use these:<BR> +<tab indent="12" +><em>Return to your <A HREF="LYNXHIST:0">Startfile</A></em><BR> +<tab indent="12" +><em>Review your <A HREF="LYNXKEYMAP:">Keymap</A></em><BR> +(Yes, they'll work. No, they won't do any harm. But...) + +<p>If you <em>must</em> try one, the second is OK from the command line:<BR> +<tab indent="12"><em>lynx LYNXKEYMAP:</em><BR> +But within Lynx, use the '<em>K</em>' keystroke command. +</BODY> +</HTML> |