0

In lynx.cfg, it contains:

.h1 CGI scripts
# These settings control Lynx's ability to execute various types of scripts.

.h2 LOCAL_EXECUTION_LINKS_ALWAYS_ON
.h2 LOCAL_EXECUTION_LINKS_ON_BUT_NOT_REMOTE
# Local execution links and scripts are by default completely disabled,
# unless a change is made to the userdefs.h file to enable them or
# the configure script is used with the corresponding options
# (-enable-exec-links and -enable-exec-scripts).
# See the Lynx source code distribution and the userdefs.h
# file for more detail on enabling execution links and scripts.
#
# If you have enabled execution links or scripts the following
# two variables control Lynx's action when an execution link
# or script is encountered.
#
# If LOCAL_EXECUTION_LINKS_ALWAYS_ON is set to TRUE any execution
# link or script will be executed no matter where it came from.
# This is EXTREMELY dangerous.  Since Lynx can access files from
# anywhere in the world, you may encounter links or scripts that
# will cause damage or compromise the security of your system.
#
# If LOCAL_EXECUTION_LINKS_ON_BUT_NOT_REMOTE is set to TRUE only
# links or scripts that reside on the local machine and are
# referenced with a URL beginning with "file://localhost/" or meet
# TRUSTED_EXEC or ALWAYS_TRUSTED_EXEC rules (see below) will be
# executed.  This is much less dangerous than enabling all execution
# links, but can still be dangerous.
#
#LOCAL_EXECUTION_LINKS_ALWAYS_ON:FALSE
#LOCAL_EXECUTION_LINKS_ON_BUT_NOT_REMOTE:FALSE

.h2 TRUSTED_EXEC
# If LOCAL_EXECUTION_LINK_ON_BUT_NOT_REMOTE is TRUE, and no TRUSTED_EXEC
# rule is defined, it defaults to "file://localhost/" and any lynxexec
# or lynxprog command will be permitted if it was referenced from within
# a document whose URL begins with that string.  If you wish to restrict the
# referencing URLs further, you can extend the string to include a trusted
# path.  You also can specify a trusted directory for http URLs, which will
# then be treated as if they were local rather than remote.  For example:
#
#   TRUSTED_EXEC:file://localhost/trusted/
#   TRUSTED_EXEC:http://www.wfbr.edu/trusted/
#
# If you also wish to restrict the commands which can be executed, create
# a series of rules with the path (Unix) or command name (VMS) following
# the string, separated by a tab.  For example:
#
# Unix:
# ====
#   TRUSTED_EXEC:file://localhost/<tab>/bin/cp
#   TRUSTED_EXEC:file://localhost/<tab>/bin/rm
# VMS:
# ===
#   TRUSTED_EXEC:file://localhost/<tab>copy
#   TRUSTED_EXEC:file://localhost/<tab>delete
#
# Once you specify a TRUSTED_EXEC referencing string, the default is
# replaced, and all the referencing strings you desire must be specified
# as a series.  Similarly, if you associate a command with the referencing
# string, you must specify all of the allowable commands as a series of
# TRUSTED_EXEC rules for that string.  If you specify ALWAYS_TRUSTED_EXEC
# rules below, you need not repeat them as TRUSTED_EXEC rules.
#
# If EXEC_LINKS and JUMPFILE have been defined, any lynxexec or lynxprog
# URLs in that file will be permitted, regardless of other settings.  If
# you also set LOCAL_EXECUTION_LINKS_ON_BUT_NOT_REMOTE:TRUE and a single
# TRUSTED_EXEC rule that will always fail (e.g., "none"), then *ONLY* the
# lynxexec or lynxprog URLs in JUMPFILE (and any ALWAYS_TRUSTED_EXEC rules,
# see below) will be allowed.  Note, however, that if Lynx was compiled with
# CAN_ANONYMOUS_JUMP set to FALSE (default is TRUE), or -restrictions=jump
# is included with the -anonymous switch at run time, then users of an
# anonymous account will not be able to access the jumps file or enter
# 'j'ump shortcuts, and this selective execution feature will be overridden
# as well (i.e., they will only be able to access lynxexec or lynxprog
# URLs which meet any ALWAYS_TRUSTED_EXEC rules).
#
#TRUSTED_EXEC:none

.h2 ALWAYS_TRUSTED_EXEC
# If EXEC_LINKS was defined, any lynxexec or lynxprog URL can be made
# always enabled by an ALWAYS_TRUSTED_EXEC rule for it.  This is useful for
# anonymous accounts in which you have disabled execution links generally,
# and may also have disabled jumps file links, but still want to allow
# execution of particular utility scripts or programs.  The format is
# like that for TRUSTED_EXEC.  For example:
#
# Unix:
# ====
#   ALWAYS_TRUSTED_EXEC:file://localhost/<tab>/usr/local/kinetic/bin/usertime
#   ALWAYS_TRUSTED_EXEC:http://www.more.net/<tab>/usr/local/kinetic/bin/who.sh
# VMS:
# ===
#   ALWAYS_TRUSTED_EXEC:file://localhost/<tab>usertime
#   ALWAYS_TRUSTED_EXEC:http://www.more.net/<tab>show users
#
# The default ALWAYS_TRUSTED_EXEC rule is "none".
#
#ALWAYS_TRUSTED_EXEC:none

.h2 TRUSTED_LYNXCGI
# Unix:
# =====
# TRUSTED_LYNXCGI rules define the permitted sources and/or paths for
# lynxcgi links (if LYNXCGI_LINKS is defined in userdefs.h).  The format
# is the same as for TRUSTED_EXEC rules (see above).  Example rules:
#
#   TRUSTED_LYNXCGI:file://localhost/
#   TRUSTED_LYNXCGI:<tab>/usr/local/etc/httpd/cgi-bin/
#   TRUSTED_LYNXCGI:file://localhost/<tab>/usr/local/www/cgi-bin/
#
# VMS:
# ====
# Do not define this.
#
# The default TRUSTED_LYNXCGI rule is "none".
#
TRUSTED_LYNXCGI:none

.h2 LYNXCGI_ENVIRONMENT
# Unix:
# =====
# LYNXCGI_ENVIRONMENT adds the current value of the specified
# environment variable to the list of environment variables passed on to the
# lynxcgi script.  Useful variables are HOME, USER, etc...  If proxies
# are in use, and the script invokes another copy of lynx (or a program like
# wget) in a subsidiary role, it can be useful to add http_proxy and other
# *_proxy variables.
#
# VMS:
# ====
# Do not define this.
#
#LYNXCGI_ENVIRONMENT:

.h2 LYNXCGI_DOCUMENT_ROOT
# Unix:
# =====
# LYNXCGI_DOCUMENT_ROOT is the value of DOCUMENT_ROOT that will be passed
# to lynxcgi scripts.  If set and the URL has PATH_INFO data, then
# PATH_TRANSLATED will also be generated.  Examples:
#   LYNXCGI_DOCUMENT_ROOT:/usr/local/etc/httpd/htdocs
#   LYNXCGI_DOCUMENT_ROOT:/data/htdocs/
#
# VMS:
# ====
# Do not define this.
#
#LYNXCGI_DOCUMENT_ROOT:

What type of script is Lynx referring to in this context? It doesn't appear to be JavaScript (and several sources indicate that Lynx does not support it).

Aren't CGI scripts primarily executed on the server side?

Why is a web browser like Lynx involved with them?

1 Answer 1

2

From the online documentation:

The lynxcgi URL:

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:

lynxcgi://localhost/path_to_CGI_script

where //localhost is optional and always implied; the full path should be specified, as “~” is not recognized; if the script is in the directory Lynx was started from, the simple file name is adequate. The output of the script should be text/html and is rendered and displayed by Lynx. Restrictions on use of lynxcgi and on acceptable paths can be imposed in userdefs.h and lynx.cfg, qv.

This is a Lynxism and should be used only in local documents intended solely for Lynx, or for limited local testing of CGI scripts without an http server.

Also see the note in the section on Tables:

Lynx recognizes the TABLE element and all of its associated elements as described in RFC 1942 and will process any ID attributes in the start tags for handling as NAME-ed anchors, but does not create actual tables. Instead, it treats the TR start tag as a collapsible BR (line break), and inserts a collapsible space before the content of each TH and TD start tag. [...]

Starting with version 2.8.3, Lynx renders some tables in tabular form. This tabular representation for simple tables (TRST) does not attempt to implement full support for any table model. [...]

For tabular display of more complex tables, Lynx users can make use of external scripts or programs. The normal Lynx distribution currently does not provide such scripts, but they can be written locally or downloaded from several sources. It is suggested to use one of Lynx's facilities for invoking external programs (see DOWNLOADER, PRINTER, EXTERNAL, TRUSTED_LYNXCGI in lynx.cfg and lynxcgi: in Supported URLs for information on various ways for setting this up).

A bit of Googling leads to one such script. I don't think there's any restriction on languages - as long as it's executable and produces HTML output, anything should be fine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .