SWISH-CONFIG - Configuration File Directives

Swish-e version 2.4.7

OVERVIEW
CONFIGURATION FILE
Document Info

OVERVIEW

This document lists the available configuration directives available in Swish-e.

CONFIGURATION FILE

What files Swish-e indexes and how they are indexed, and where the index is written can be controlled by a configuration file.

The configuration file is a text file composed of comments, blank lines, and configuration directives. The order of the directives is not important. Some directives may be used more than once in the configuration file, while others can only be used once (e.g. additional directives will overwrite preceding directives). Case of the directive is not important -- you may use upper, lower, or mixed case.

Comments are any line that begin with a "#".

    # This is a comment

As of 2.4.3 lines may be continued by placing a backslas as the last character on the line:

    IgnoreWords \
        am \
        the \
        foo

Directives may take more than one parameter. Enclose single parameters that include whitespace in quotes (single or double). Inside of quotes the backslash escapes the next character.

    ReplaceRules append "foo bar"   <- define "foo bar" as a single parameter

If you need to include a quote character in the value either use a backslash to escape it, or enclose it in quotes of the other type.

Backslashes also have special meaning in regular expressions.

    FileFilterMatch pdftotext "'%p' -" /\.pdf$/

This says that the dot is a real dot (instead of matching any character). If you place the regular expression in quotes then you must use double-backslashes.

    FileFilterMatch pdftotext "'%p' -" "/\\.pdf$/"

Swish-e will convert the double backslash into a single backslash before passing the parameter to the regular expression compiler.

Commented example configuration files are included in the conf directory of the Swish-e distribution.

Some command line arguments can override directives specified in the configuration file. Please see also the SWISH-RUN for instructions on running Swish-e, and the SWISH-SEARCH page for information and examples on how to search your index.

The configuration file is specified to Swish-e by the -c switch. For example,

    swish-e -c myconfig.conf

You may also split your directives up into different configuration files. This allows you to have a master configuration file used for many different indexes, and smaller configuration files for each separate index. You can specify the different configuration files when running from the command line with the -c switch (see SWISH-RUN), or you may include other Configuration file with the IncludeConfigFile directive below.

Typically, in a configuration file the directives are grouped together in some logical order -- that is, directives that control the source of the documents would be grouped together first, and directives that control how each document is filtered or its words index in another group of directives. (The directives listed below are grouped in this order).

The configuration file directives are listed below in these groups:

Administrative Headers Directives -- You may add administrative information to the header of the index file.
Document Source Directives -- Directives for selecting the source documents and the location of the index file.
Document Contents Directives -- Directives that control how a document content is indexed.
Directives for the File Access method only -- These directives are only applicable to the File Access indexing method.
Directives for the HTTP Access Method Only -- Likewise, these only apply to the HTTP Access method.
Directives for the prog Access Method Only -- These only apply to the prog Access method.
Document Filter Directives -- This is a special section that describes using document filters with Swish-e.

Alphabetical Listing of Directives

AbsoluteLinks [yes|NO]
BeginCharacters *string of characters*
BumpPositionCounterCharacters *string*
Buzzwords [*list of buzzwords*|File: path]
CompressPositions [yes|NO]
ConvertHTMLEntities [YES|no]
DefaultContents [TXT|HTML|XML|TXT2|HTML2|XML2|TXT*|HTML*|XML*]
Delay *seconds*
DontBumpPositionOnEndTags *list of names*
DontBumpPositionOnStartTags *list of names*
EnableAltSearchSyntax [yes|NO]
EndCharacters *string of characters*
EquivalentServer *server alias*
ExtractPath *metaname* [replace|remove|prepend|append|regex]
FileFilter *suffix* *program* [options]
FileFilterMatch *program* *options* *regex* [*regex* ...]
FileInfoCompression [yes|NO]
FileMatch [contains|is|regex] *regular expression*
FileRules [contains|is|regex] *regular expression*
FuzzyIndexingMode [NONE|Stemming|Soundex|Metaphone|DoubleMetaphone]
FollowSymLinks [yes|NO]
HTMLLinksMetaName *metaname*
IgnoreFirstChar *string of characters*
IgnoreLastChar *string of characters*
IgnoreLimit *integer integer*
IgnoreMetaTags *list of names*
IgnoreNumberChars *list of characters*
IgnoreTotalWordCountWhenRanking [YES|no]
IgnoreWords [*list of stop words*|File: path]
ImageLinksMetaName *metaname*
IncludeConfigFile
IndexAdmin *text*
IndexAltTagMetaName *tagname*|as-text
IndexComments [yes|NO]
IndexContents [TXT|HTML|XML|TXT2|HTML2|XML2|TXT*|HTML*|XML*] *file extensions*
IndexDescription *text*
IndexDir [URL|directories or files]
IndexFile *path*
IndexName *text*
IndexOnly *list of file suffixes*
IndexPointer *text*
IndexReport [0|1|2|3]
MaxDepth *integer*
MaxWordLimit *integer*
MetaNameAlias *meta name* *list of aliases*
MetaNames *list of names*
MinWordLimit *integer*
NoContents *list of file suffixes*
obeyRobotsNoIndex [yes|NO]
ParserWarnLevel [0|1|2|3]
PreSortedIndex *list of property names*
PropCompressionLevel [0-9]
PropertyNameAlias *property name* *list of aliases*
PropertyNames *list of meta names*
PropertyNamesCompareCase *list of meta names*
PropertyNamesIgnoreCase *list of meta names*
PropertyNamesNoStripChars *list of meta names*
PropertyNamesDate *list of meta names*
PropertyNamesNumeric *list of meta names*
PropertyNamesMaxLength integer *list of meta names*
PropertyNamesSortKeyLength integer *list of meta names*
ReplaceRules [replace|remove|prepend|append|regex]
ResultExtFormatName name -x format string
SpiderDirectory *path*
StoreDescription [XML <tag>|HTML <meta>|TXT size]
"SwishProgParameters *list of parameters*
SwishSearchDefaultRule [<AND-WORD>|<or-word>]
TmpDir *path*
TranslateCharacters [*string1 string2*|:ascii7:]
TruncateDocSize *number of characters*
UndefinedMetaTags [error|ignore|INDEX|auto]
UndefinedXMLAttributes [DISABLE|error|ignore|index|auto]
UseStemming [yes|NO]
UseSoundex [yes|NO]
UseWords [*list of words*|File: path]
WordCharacters *string of characters*
XMLClassAttributes *list of XML attribute names*

Directives that Control Swish

These configuration directives control the general behavior of Swish-e.

IncludeConfigFile *path to config file*
This directive can be used to include configuration directives located in another file.
```
    IncludeConfigFile /usr/local/swish/conf/site_config.config
```
IndexReport [0|1|2|3]
This is how detailed you want reporting while indexing. You can specify numbers 0 to 3. 0 is totally silent, 3 is the most verbose. The default is 1.

This may be overridden from the command line via the -v switch (see SWISH-RUN).
ParserWarnLevel [0|1|2|3]
Sets the error level when using the libxml2 parser for XML and HTML. libxml2 will point out structural errors in your documents.
```
    0 = no report
    1 = fatal errors
    2 = errors
    3 = warnings
```
Currently (as of 2.4.4 - early 2005) libxml2 only reports errors at level 2. The default as of 2.4.4 is "2" which should report any errors that might indicate a problem parsing a document.

The exception to this is UTF-8 to Latin-1 conversion errors are reported at level 3 (changed from 1 in 2.4.4). Although these errors indicate a problem indexing text, they are only reported at level 3 because they can be very common.

It is recommended that you index at ParserWarnLevel 3 when first starting out to see what errors and warnings are reported. Then reduce the level when you understand what documents are causing parsing problems and why.
IndexFile *path*
Index file specifies the location of the generated index file. If not specified, Swish-e will create the file index.swish-e in the current directory.
```
    IndexFile /usr/local/swish/site.index
```
obeyRobotsNoIndex [yes|NO]
When enabled, Swish-e will not index any HTML file that contains:
```
    <meta name="robots" content="noindex">
```
The default is to ignore these meta tags and index the document. This tag is described at http://www.robotstxt.org/wc/exclusion.html.

Note: This feature is only available with the libxml2 HTML parser.

Also, if you are using the libxml2 parser (HTML2 and XML2) then you can use the following comments in your documents to prevent indexing:
```
       
       
```
and/or these may be used also:
```
       
       
```
For example, these are very helpful to prevent indexing of common headers, footers, and menus.

NOTE: This following items are currently not available. These items require Swish-e to parse the configuration file while searching.

EnableAltSearchSyntax [yes|NO]
NOTE: This following item is currently not available.

Enable alternate search syntax. Allows the usage of a basic "Altavista(c)", "Lycos(c)", etc. like search syntax. This means a search query can contain "+" and "-" as syntax parameter.

Example:
```
    swish-e -w "+word1 +word2 -word3  word4 word5"
    "+"  = following word has to be in all found documents
    "-"  = following word may not be in any document found
    " "  = following word will be searched in documents
```
SwishSearhOperators <and-word> <or-word> <not-word>
NOTE: This following item is currently not available.

Using this config directive you can change the boolean search operators of Swish-e, e.g. to adapt these to your language. The default is: AND OR NOT

Example (german):
```
    SwishSearchOperators   UND  ODER  NICHT
```
SwishSearchDefaultRule [<AND-WORD>|<or-word>]
NOTE: This following item is currently not available.

SwishSearchDefaultRule defines the default Boolean operator to use if none is specified between words or phrases. The default is AND.

The word you specify must match one of the available SwishSearchOperators.

Example:
```
    SwishSearchOperators   UND  ODER  NICHT
    # Make it act like a web search engine
    SwishSearchDefaultRule ODER
```
ResultExtFormatName name -x format string
NOTE: This following item is currently not available.

The output of Swish-e can be defined by specifying a format string with the -x command line argument. Using ResultExtFormatName you can assign a predefined format string to a name.

Examples:
```
    ResultExtFormatName  moreinfo   "%c|%r|%t|%p|<author>|<publishyear>\n"
```
Then when searching you can specify the format string's name
```
    swish-e   ...  -x moreinfo  ...
```
See the -x switch in SWISH-RUN for more information about output formats.

Administrative Headers Directives

Swish-e stores configuration information in the header of the index file. This information can be retrieved while searching or by functions in the Swish-e C library. There are a number of fields available for your own use. None of these fields are required:

IndexName *text*
IndexDescription *text*
IndexPointer *text*
IndexAdmin *text*
These variables specify information that goes into index files to help users and administrators. IndexName should be the name of your index, like a book title. IndexDescription is a short description of the index or a URL pointing to a more full description. IndexPointer should be a pointer to the original information, most likely a URL. IndexAdmin should be the name of the index maintainer and can include name and email information. These values should not be more than 70 or so characters and should be contained in quotes. Note that the automatically generated date in index files is in D/M/Y and 24-hour format.

Examples:
```
    IndexName "Linux Documentation"
    IndexDescription "This is an index of /usr/doc on our Linux machine." 
    IndexPointer http://localhost/swish/linux/index.html
    IndexAdmin webmaster
```

Document Source Directives

These directives control what documents are indexed and how they are accessed. See also Directives for the File Access method only and Directives for the HTTP Access Method Only for directives that are specific to those access methods.

IndexDir [directories or files|URL|external program]
IndexDir defines the source of the documents for Swish-e. Swish-e currently supports three file access methods: File system, HTTP (also called spidering), and prog for reading files from an external program.

The -S command line argument is used to select the file access method.
```
    swish-e -c swish.config -S fs    - file system
    swish-e -c swish.config -S http  - internal http spider
    swish-e -c swish.config -S prog  - external program of any type
```
For the fs method of access IndexDir is a space-separated list of files and directories to index. Use a forward slash as the path separator in MS Windows.

For the http method the IndexDir setting is a list of space-separated URLs.

For the prog method the IndexDir setting is a list of space-separated programs to run (which generate documents for swish to index).

You may specify more than one IndexDir directive.

Any sub-directories of any listed directory will also be indexed.

Note: While processing directories, Swish-e will ignore any files or directories that begin with a dot ("."). You may index files or directories that begin with a dot by specifying their name with IndexDir or -i.

Examples:
```
    # Index this directory an any subdirectories
    IndexDir /usr/local/home/http

    # Index the docs directory in current directory
    IndexDir ./docs

    # Index these files in the current directory
    IndexDir ./index.html ./page1.html ./page2.html
    # and index this directory, too
    IndexDir ../public_html
```
For the HTTP method of access specify the URL's from which you want the spidering to begin.

Example:
```
    IndexDir http://www.my-site.com/index.html
    IndexDir http://localhost/index.html
```
Obviously, using the HTTP method to index is much slower than indexing local files. Be well aware that some sites do not appreciate spidering and may block your IP address. You may wish to contact the remote site before spidering their web site. More information about spidering can be found in Directives for the HTTP Access Method Only below.

For the prog method of access IndexDir specifies the path to the program(s) to execute. The external program must correctly format the documents being passed back to Swish-e. Examples of external programs are provided in the prog-bin directory.
```
    IndexDir ./myprogram.pl
```
See prog for details.

Note: Not all directives work with all methods.
NoContents *list of file suffixes*
Files with these suffixes will not have their contents indexed, but will have their path name (file name) indexed instead.

If the file's type is HTML or HTML2 (as set by IndexContents or DefaultContents) then the file will be parsed for a HTML title and that title will be indexed. Note that you must set the file's type with IndexContents or DefaultContents: .html and .htm are NOT type HTML by default. For example:
```
   IndexContents HTML* .htm .html
```
If a title is found, it will still be checked for FileRules title, and the file will be skipped if a match is found. See FileRules.

If the file's type is not HTML, or it is HTML and no title is found, then the file's path will be indexed.

For example, this will allow searching by image file name.
```
    NoContents .gif .xbm .au .mov .mpg .pdf .ps
```
Note: Using this directive will not cause files with those suffixes to be indexed. That is, if you use IndexOnly to limit the types of files that are indexed, then you must specify in IndexOnly the same suffixes listed in NoContents.

This does not work:
```
    # Wrong!
    IndexOnly .htm .html
    NoContents .gif .xbm .au .mov .mpg .pdf .ps
```
A -S prog program may set the No-Contents: header to enable this feature for a specific document (although it would be smarter for the -S prog program to simply only send the pathname or title to be indexed.

ReplaceRules [replace|remove|prepend|append|regex]

ReplaceRules allows you to make changes to file pathnames before they're indexed. These changed file names or URLs will be returned in search results.

For example, you may index your files locally (with the File system indexing method), yet return a URL in search results. This directive can be used to map the file names to their respective URLs on your web server.

There are five operations you can specify: replace, append, remove, prepend, and regex They will parse the pathname in the order you've typed these commands.

This directive uses C library regex.h regular expressions.

   replace "the string you want replaced" "what to change it to"
   remove "a string to remove"   
   prepend "a string to add before the result"
   append "a string to add after the result"
   regex  "/search string/replace string/options"

Remember, quotes are needed if an expression contains white space, and backslashes have special meaning.

Regex is an Extended Regular Expression. The first character found is the delimiter (but it's not smart enough to use matched chars such as [], (), and {}).

The replace string may use substitution variables:

    $0      the entire matched (sub)string
    $1-$9   returns patterns captured in "(" ")" pairs
    $`      the string before the matched pattern
    $'      the string after the matched pattern

The options change the behavior of expression:

    i       ignore the case when matching
    g       repeat the substitution for the entire pattern

Examples:

    ReplaceRules replace testdir/ anotherdir/
    ReplaceRules replace [a-z_0-9]*_m.*\.html index.html

    ReplaceRules remove testdir/

    ReplaceRules prepend http://localhost/
    ReplaceRules append .html

    ReplaceRules regex  !^/web/(.+)/!http://$1.domain.com/!
    replaces a file path:
        /web/search/foo/index.html
    with
        http://search.domain.com/foo/index.html

    ReplaceRules regex  #^#http://localhost/www#
    ReplaceRules prepend http://localhost/www  (same thing)

    # Remove all extensions from C source files
    ReplaceRules remove .c     # ERROR! That "." is *any char*
    ReplaceRules remove \.c    # much better...

    ReplaceRules remove "\\.c" # if in quotes you need double-backslash!  
    ReplaceRules remove "\.c"  # ERROR! "\." -> "." and is *any char*

IndexContents [TXT|HTML|XML|TXT2|HTML2|XML2|TXT*|HTML*|XML*] *file extensions*
The IndexContents directive assigns one of Swish-e's document parsers to a document, based on the its extension. Swish-e currently knows how to parse TXT, HTML, and XML documents.

The XML2, HTML2, and TXT2 parsers are currently only available when Swish-e is configured to use libxml2.

You may use XML*, HTML*, and TXT* to select the parser automatically. If libxml2 is installed then it will be used to parse the content. Otherwise, Swish-e's internal parsers will be used.

Documents that are not assigned a parser with IndexContents will, by default, use the HTML2 parser if libxml2 is installed, otherwise will use Swish-e's internal HTML parser. The DefaultContents directive may be used to assign a parser to documents that do not match a file extension defined with the IndexContents directive.

Example:
```
    IndexContents HTML* .htm .html .shtml
    IndexContents TXT*  .txt .log .text
    IndexContents XML*  .xml
```
HTML* is the default type for all files, unless otherwise specified (and this default can be changed by the DefaultContents directive. Swish-e parses titles from HTML files, if available, and keeps track of the context of the text for context searching (see -t in SWISH-RUN).

If using filters (with the FileFilter directive) to convert documents you should include those extensions, too. For example, if using a filter to convert .pdf to .html, you need to tell Swish-e that .pdf should be indexed by the internal HTML parser:
```
    FileFilter  .pdf   pdf2html
    IndexContent  HTML  .pdf
```
See also Document Filter Directives.

Note: Some of this may be changed in the future to use content-types instead of file extensions. See SWISH-3.0
DefaultContents [TXT|HTML|XML|TXT2|HTML2|XML2|TXT*|HTML*|XML*]
This sets the default parser for documents that are not specified in IndexContents. If not specified the default is HTML.

The XML2, HTML2, and TXT2 parsers are currently only available when Swish-e is configured to use libxml2.

You may use XML*, HTML*, and TXT* to select the parser automatically. If libxml2 is installed then it will be used to parse the content. Otherwise, Swish-e's internal parsers will be used.

Example:
```
    DefaultContents HTML
```
The DefaultContents directive should be used when spidering, as HTML files may be returned without a file extension (such as when requesting a directory and the default index.html is returned).
FileInfoCompression [yes|NO]
** This directive is currently not supported **

Setting FileInfoCompression to yes will compress the index file to save disk space. This may result in longer indexing times. The default is no.

Also see the -e switch in SWISH-RUN for saving RAM during indexing.

Document Contents Directives

These directives control what information is extracted from your source documents, and how that information is made available during searching.

ConvertHTMLEntities [YES|no]
ASCII entities can be converted automatically while indexing documents of type HTML (not for HTML2). For performance reasons you may wish to set this to no if your documents do not contain HTML entities. The default is yes.

If ConvertHTMLEntities is set no the entities will be indexed without conversion.

NOTE: Entities within XML files and files parsed with libxml2 (HTML2) are converted regardless of this setting.
MetaNames *list of names*
META names are a way to define "fields" in your XML and HTML documents. You can use the META names in your queries to limit the search to just the words contained in that META name of your document. For example, you might have a META tagged field in your documents called subjects and then you can search your documents for the word "foo" but only return documents where "foo" is within the subjects META tag.
```
    swish-e -w subjects=foo
```
(See also the -t switch in SWISH-RUN for information about context searching in HTML documents.)

The MetaNames directive is a space separated list. For example:
```
    MetaNames meta1 meta2 keywords subjects
```
You may also use UndefinedMetaTags to specify automatic extraction of meta names from your HTML and XML documents, and also to ignore indexing content of meta tags.

META tags can have two formats in your HTML source documents:
```
    <META NAME="meta1" CONTENT="some content">
```
and (if using the HTML2/libxml2 parser)
```
    <meta1>
        some content
    </meta1>
```
But this second version is invalid HTML, and will generate a warning if ParserWarningLevel is set (libxml2 only).

And in XML documents, use the format:
```
    <meta1>
        Some Content
    </meta1>
```
Then you can limit your search to just META meta1 like this:
```
    swish-e -w 'meta1=(apples or oranges)'
```
You may nest the XML and the start/end tag versions:
```
    <keywords>
        <tag1>
            some content
        </tag1>
        <tag2>
            some other content
        </tag2>
    <keywords>
```
Then you can search in both tag2 and tag2 with:
```
    swish-e -w 'keywords=(query words)'
```
Swish-e indexes all text as some metaname. The default is swishdefault, so these two queries are the same:
```
    swish-e -w foo
    swish-e -w swishdefault=foo
```
When indexing HTML Swish-e indexes the HTML title as default text, so when searching Swish-e will find matches in both the HTML body and the HTML title. Swish also, by default, indexes content of meta tags. So:
```
    swish-e -w foo
```
will find "foo" in the body, the title, or any meta tags.

Currently, there's no way to prevent Swish-e from indexing the title contents along with the body contents, but see UndefinedMetaTags for how to control the indexing of meta tags.

If you would like to search just the title text, you may use:
```
    MetaNames swishtitle
```
This will index the title text separately under the built-in swish internal meta name "swishtitle". You may then search like
```
    swish-e -w foo  -- search for "foo" in title, body (and undefined meta tags)
    swish-e -w swishtitle=foo -- search for "foo" in title only
```
In addition to swishtitle, you can limit searches to documents' path with:
```
   MetaNames swishdocpath
```
Then to search for "foo" but also limit searches to documents that include "manual" or "tutorial" in their path:
```
   swish-e -w foo swishdocpath=(manual or tutorial)
```
See also ExtractPath.
MetaNameAlias *meta name* *list of aliases*
MetaNameAlias assigns aliases for a meta name. For example, if your documents contain meta tags "description", "summary", and "overview" that all give a summary of your documents you could do this:
```
    MetaNames summary
    MetaNameAlias summary description overview
```
Then all three tags will get indexed as meta tag "summary". You can then search all the fields as:
```
    -w summary=foo
```
The Alias work at search time, too. So these will also limit the search to the "summary" meta name.
```
    -w description=foo
    -w overview=foo
```
MetaNamesRank integer *list of meta names*
You can assign a bias to metanames that will affect how ranking is calculated. The range of values is from -10 to +10, with zero being no bias.
```
    MetaNamesRank 4 subject
    MetaNamesRank 3 swishdefault
    MetaNamesRank 2 author publisher
    MetaNamesRank -5 wrongwords
```
This feature is still considered experimental. If you use it, please send feedback to the discussion list.
HTMLLinksMetaName *metaname*
Allows indexing of HTML links. Normally, HTML links (href tags) are not indexed by Swish-e. This directive defines a metaname, and links will be indexed under this meta name.

Example:
```
    HTMLLinksMetaName links
```
Now, to limit searches to files with a link to "home.html" do this:
```
    -w links='"home.html"'
```
The double quotes force a phrase search.

To make Swish-e index links as normal text, you may use:
```
    HTMLLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
ImageLinksMetaName *metaname*
Allows indexing of image links under a metaname. Normally, image URLs are not indexed.

Example:
```
    ImagesLinksMetaName images
```
Now, if you would like to find pages that include a nice image of a beach:
```
    -w images='beach'
```
To make Swish-e index links as normal text, you may use:
```
    ImageLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
IndexAltTagMetaName *tagname*|as-text
Allows indexing of images <IMG> ALT tag text. Specify either a tag name which will be used as a metaname, or the special text "as-text" which says to index the ALT text as if it were plain text at the current location.

For example, by specifying a tag name:
```
   IndexAltTagMetaName bar
```
would make this markup:
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
appear like
```
    <foo>
        <bar>Alt text here</bar>
    </foo>
```
Then the normal rules (MetaNames and PropertyNames) apply to how that text is indexed.

If you use the special tag "as-text" then
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
simply becomes
```
    <foo>
        Alt text here
    </foo>
```
This feature is only available when using the libxml2 parser (HTML2 and XML2).
AbsoluteLinks [yes|NO]
If this is set true then Swish-e will attempt to convert relative URIs extracted from HTML documents for use with HTMLLinksMetaName and ImageLinksMetaName into absolute URIs. Swish-e will use any <BASE> tag found in the document, otherwise it will use the file's pathname. The pathname used will be the pathname *after* ReplaceRules has been applied to the document's pathname.

For example, say you wish to index image links under the metaname "images".
```
    ImageLinksMetaName images
```
If an image is located in http://localhost/vacations/france/index.html and AbsoluteLinks is set to no, then a image within that document:
```
     <img src="beach.jpeg">
```
will only index "beach.jpeg".

But, if you want more detail when searching, you can enable AbsoluteLinks and Swish-e will index "http://localhost/vacations/france/beach.jpeg". You can then look for images of beaches, but only in France:
```
    -w images=(beach and france)
```
This also means you can search for any images within France:
```
    -w images=(france)
```
This feature is only available with the libxml2 HTML parser.
UndefinedMetaTags [error|ignore|INDEX|auto]
This directive defines the behavior of Swish-e during indexing when a meta name is found but is not listed in MetaNames. There are four choices:
- error
  If a meta name is found that is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force. This is the default.
- auto
  This method create meta tags automatically for HTML meta names and XML elements. Using this is the same as specifying all the meta names explicitly in a MetaNames directive.
UndefinedXMLAttributes [DISABLE|error|ignore|index|auto]
This is similar to UndefinedMetaTags, but only applies to XML documents (parsed with libxml2). This allows indexing of attribute content, and provides a way to index the content under a metaname. For example, UndefinedXMLAttributes can make
```
    <person age="23">
          John Doe
    </person>
```
look like the following to swish:
```
    <person>
        <person.age>
            23
        </person.age>
        John Doe
    </person>
```
What happens to the text "23" will depend on the setting of UndefinedXMLAttributes:
- disable
  XML attributes are not parsed and not indexed. This is the default.
- error
  If the concatenated meta name (e.g. person.age) is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force.
- auto
  This method will create meta tags from the combined element and attributes (and XML Class name) This options should be used with caution as it can generate a lot of metaname entries.
  
  See also the example below XMLClassAttribues.

XMLClassAttributes *list of XML attribute names*

Combines an XML class name with the element name to make up a metaname. For example:

    XMLClassAttributes class

    <person class="first">
        John
    </person>
    <person class="last">
        Doe
    </person>

Will appear to Swish-e as:

    <person>
        <person.first>
        John
        </person.first>
    </person>
    <person>
        <person.last>
        Doe
        </person.last>
    </person>

How the data is indexed depends on MetaNames and UndefinedMetaTags.

Here's an example using the following configuration which combines the two directives XMLClassAttributes and UndefinedXMLAttributes.

    XMLClassAttributes class
    UndefinedMetaTags auto
    UndefinedXMLAttributes auto
    IndexContents XML2 .xml

The source XML file looks like:

    <xml> <person class="student" phone="555-1212" age="102"> John </person>
    <person greeting="howdy">Bill</person> </xml>

Swish-e parses as:

    ./swish-e -c 2 -i 1.xml -T parsed_tags  parsed_text  -v 0
    Indexing Data Source: "File-System"

    <xml> (MetaName)

        <person> (MetaName)
            <person.student> (MetaName)
                <person.student.phone> (MetaName)
                    555-1212
                </person.student.phone> 
                <person.student.age> (MetaName)
                    102
                </person.student.age> 
                John
        </person> 

        <person> (MetaName)
            <person.greeting> (MetaName)
                howdy
            </person.greeting> 
            Bill
        </person> 

    </xml> 
    Indexing done!

One thing to note is that the first <person> block finds a class name "student" so all metanames that are created from attributes use the combined name "person.student". The second <person> block doesn't contain a "class" so, the attribute name is combined directly with the element name (e.g. "person.greeting").

ExtractPath *metaname* [replace|remove|prepend|append|regex]
This directive can be used to index extracted parts of a document's path. A common use would be to limit searches to specific areas of your file tree.

The extracted string will be indexed under the specified meta name.

See ReplaceRules for a description of the various pattern replacement methods, but you will use the regex method.

For example, say your file system (or web tree) was organized into departments:
```
    /web/sales/foo...
    /web/parts/foo...
    /web/accounting/foo...
```
And you wanted a way to limit searches to just documents under "sales".
```
    ExtractPath department regex !^/web/([^/]+)/.*$!$1!
```
Which says, extract out the department name (as substring $1) and index it as meta name department. Then to limit a search to the sales department:
```
    swish-e -w foo AND department=sales
```
Note that the regex method uses a substitution pattern, so to index only a sub-string match the entire document path in the regular expression, as shown above. Otherwise any part that is not matched will end up in the substitution pattern.

See the ExtractPathDefault option for a way to set a value if not patterns match.

Although unlikely, you may use more than one ExtractPath directive. More than one directive of the same meta name will operate successively (in order listed in the configuration file) on the path. This allows you to use regular expressions on the results of the previous pattern substitution (as if piping the output from one expression to the patter of the next).
```
    ExtractPath foo regex !^(...).+$!$1!
    ExtractPath foo regex !^.+(.)$!$1!
```
So, the third letter is indexed as meta name "foo" if both patterns match.
```
    ExtractPath foo regex !^X(...).+$!$1!
    ExtractPath foo regex !^.+(.)$!$1!
```
Now (not the "X"), if the first pattern doesn't match, the last character of the path name is indexed. You must be clear on this behavior if you are using more than one ExtractPath directive with the same metaname.

The document path operated on is the real path swish used to access the document. That is, the ReplaceRules directive has no effect on the path used with ExtractPath.

The full path is used for each meta name if more than one ExtractPath pre-section"> <META NAME="meta1" CONTENT="some content">
and (if using the HTML2/libxml2 parser)
```
    <meta1>
        some content
    </meta1>
```
But this second version is invalid HTML, and will generate a warning if ParserWarningLevel is set (libxml2 only).

And in XML documents, use the format:
```
    <meta1>
        Some Content
    </meta1>
```
Then you can limit your search to just META meta1 like this:
```
    swish-e -w 'meta1=(apples or oranges)'
```
You may nest the XML and the start/end tag versions:
```
    <keywords>
        <tag1>
            some content
        </tag1>
        <tag2>
            some other content
        </tag2>
    <keywords>
```
Then you can search in both tag2 and tag2 with:
```
    swish-e -w 'keywords=(query words)'
```
Swish-e indexes all text as some metaname. The default is swishdefault, so these two queries are the same:
```
    swish-e -w foo
    swish-e -w swishdefault=foo
```
When indexing HTML Swish-e indexes the HTML title as default text, so when searching Swish-e will find matches in both the HTML body and the HTML title. Swish also, by default, indexes content of meta tags. So:
```
    swish-e -w foo
```
will find "foo" in the body, the title, or any meta tags.

Currently, there's no way to prevent Swish-e from indexing the title contents along with the body contents, but see UndefinedMetaTags for how to control the indexing of meta tags.

If you would like to search just the title text, you may use:
```
    MetaNames swishtitle
```
This will index the title text separately under the built-in swish internal meta name "swishtitle". You may then search like
```
    swish-e -w foo  -- search for "foo" in title, body (and undefined meta tags)
    swish-e -w swishtitle=foo -- search for "foo" in title only
```
In addition to swishtitle, you can limit searches to documents' path with:
```
   MetaNames swishdocpath
```
Then to search for "foo" but also limit searches to documents that include "manual" or "tutorial" in their path:
```
   swish-e -w foo swishdocpath=(manual or tutorial)
```
See also ExtractPath.
MetaNameAlias *meta name* *list of aliases*
MetaNameAlias assigns aliases for a meta name. For example, if your documents contain meta tags "description", "summary", and "overview" that all give a summary of your documents you could do this:
```
    MetaNames summary
    MetaNameAlias summary description overview
```
Then all three tags will get indexed as meta tag "summary". You can then search all the fields as:
```
    -w summary=foo
```
The Alias work at search time, too. So these will also limit the search to the "summary" meta name.
```
    -w description=foo
    -w overview=foo
```
MetaNamesRank integer *list of meta names*
You can assign a bias to metanames that will affect how ranking is calculated. The range of values is from -10 to +10, with zero being no bias.
```
    MetaNamesRank 4 subject
    MetaNamesRank 3 swishdefault
    MetaNamesRank 2 author publisher
    MetaNamesRank -5 wrongwords
```
This feature is still considered experimental. If you use it, please send feedback to the discussion list.
HTMLLinksMetaName *metaname*
Allows indexing of HTML links. Normally, HTML links (href tags) are not indexed by Swish-e. This directive defines a metaname, and links will be indexed under this meta name.

Example:
```
    HTMLLinksMetaName links
```
Now, to limit searches to files with a link to "home.html" do this:
```
    -w links='"home.html"'
```
The double quotes force a phrase search.

To make Swish-e index links as normal text, you may use:
```
    HTMLLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
ImageLinksMetaName *metaname*
Allows indexing of image links under a metaname. Normally, image URLs are not indexed.

Example:
```
    ImagesLinksMetaName images
```
Now, if you would like to find pages that include a nice image of a beach:
```
    -w images='beach'
```
To make Swish-e index links as normal text, you may use:
```
    ImageLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
IndexAltTagMetaName *tagname*|as-text
Allows indexing of images <IMG> ALT tag text. Specify either a tag name which will be used as a metaname, or the special text "as-text" which says to index the ALT text as if it were plain text at the current location.

For example, by specifying a tag name:
```
   IndexAltTagMetaName bar
```
would make this markup:
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
appear like
```
    <foo>
        <bar>Alt text here</bar>
    </foo>
```
Then the normal rules (MetaNames and PropertyNames) apply to how that text is indexed.

If you use the special tag "as-text" then
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
simply becomes
```
    <foo>
        Alt text here
    </foo>
```
This feature is only available when using the libxml2 parser (HTML2 and XML2).
AbsoluteLinks [yes|NO]
If this is set true then Swish-e will attempt to convert relative URIs extracted from HTML documents for use with HTMLLinksMetaName and ImageLinksMetaName into absolute URIs. Swish-e will use any <BASE> tag found in the document, otherwise it will use the file's pathname. The pathname used will be the pathname *after* ReplaceRules has been applied to the document's pathname.

For example, say you wish to index image links under the metaname "images".
```
    ImageLinksMetaName images
```
If an image is located in http://localhost/vacations/france/index.html and AbsoluteLinks is set to no, then a image within that document:
```
     <img src="beach.jpeg">
```
will only index "beach.jpeg".

But, if you want more detail when searching, you can enable AbsoluteLinks and Swish-e will index "http://localhost/vacations/france/beach.jpeg". You can then look for images of beaches, but only in France:
```
    -w images=(beach and france)
```
This also means you can search for any images within France:
```
    -w images=(france)
```
This feature is only available with the libxml2 HTML parser.
UndefinedMetaTags [error|ignore|INDEX|auto]
This directive defines the behavior of Swish-e during indexing when a meta name is found but is not listed in MetaNames. There are four choices:
- error
  If a meta name is found that is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force. This is the default.
- auto
  This method create meta tags automatically for HTML meta names and XML elements. Using this is the same as specifying all the meta names explicitly in a MetaNames directive.
UndefinedXMLAttributes [DISABLE|error|ignore|index|auto]
This is similar to UndefinedMetaTags, but only applies to XML documents (parsed with libxml2). This allows indexing of attribute content, and provides a way to index the content under a metaname. For example, UndefinedXMLAttributes can make
```
    <person age="23">
          John Doe
    </person>
```
look like the following to swish:
```
    <person>
        <person.age>
            23
        </person.age>
        John Doe
    </person>
```
What happens to the text "23" will depend on the setting of UndefinedXMLAttributes:
- disable
  XML attributes are not parsed and not indexed. This is the default.
- error
  If the concatenated meta name (e.g. person.age) is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force.
- auto
  This method will create meta tags from the combined element and attributes (and XML Class name) This options should be used with caution as it can generate a lot of metaname entries.
  
  See also the example below XMLClassAttribues.

XMLClassAttributes *list of XML attribute names*

Combines an XML class name with the element name to make up a metaname. For example:

    XMLClassAttributes class

    <person class="first">
        John
    </person>
    <person class="last">
        Doe
    </person>

Will appear to Swish-e as:

    <person>
        <person.first>
        John
        </person.first>
    </person>
    <person>
        <person.last>
        Doe
        </person.last>
    </person>

How the data is indexed depends on MetaNames and UndefinedMetaTags.

Here's an example using the following configuration which combines the two directives XMLClassAttributes and UndefinedXMLAttributes.

    XMLClassAttributes class
    UndefinedMetaTags auto
    UndefinedXMLAttributes auto
    IndexContents XML2 .xml

The source XML file looks like:

    <xml> <person class="student" phone="555-1212" age="102"> John </person>
    <person greeting="howdy">Bill</person> </xml>

Swish-e parses as:

    ./swish-e -c 2 -i 1.xml -T parsed_tags  parsed_text  -v 0
    Indexing Data Source: "File-System"

    <xml> (MetaName)

        <person> (MetaName)
            <person.student> (MetaName)
                <person.student.phone> (MetaName)
                    555-1212
                </person.student.phone> 
                <person.student.age> (MetaName)
                    102
                </person.student.age> 
                John
        </person> 

        <person> (MetaName)
            <person.greeting> (MetaName)
                howdy
            </person.greeting> 
            Bill
        </person> 

    </xml> 
    Indexing done!

ExtractPath *metaname* [replace|remove|prepend|append|regex]
This directive can be used to index extracted parts of a document's path. A common use would be to limit searches to specific areas of your file tree.

The extracted string will be indexed under the specified meta name.

See ReplaceRules for a description of the various pattern replacement methods, but you will use the regex method.

For example, say your file system (or web tree) was organized into departments:
```
    /web/sales/foo...
    /web/parts/foo...
    /web/accounting/foo...
```
And you wanted a way to limit searches to just documents under "sales".
```
    ExtractPath department regex !^/web/([^/]+)/.*$!$1!
```
Which says, extract out the department name (as substring $1) and index it as meta name department. Then to limit a search to the sales department:
```
    swish-e -w foo AND department=sales
```
Note that the regex method uses a substitution pattern, so to index only a sub-string match the entire document path in the regular expression, as shown above. Otherwise any part that is not matched will end up in the substitution pattern.

See the ExtractPathDefault option for a way to set a value if not patterns match.

Although unlikely, you may use more than one ExtractPath directive. More than one directive of the same meta name will operate successively (in order listed in the configuration file) on the path. This allows you to use regular expressions on the results of the previous pattern substitution (as if piping the output from one expression to the patter of the next).
```
    ExtractPath foo regex !^(...).+$!$1!
    ExtractPath foo regex !^.+(.)$!$1!
```
So, the third letter is indexed as meta name "foo" if both patterns match.
```
    ExtractPath foo regex !^X(...).+$!$1!
    ExtractPath foo regex !^.+(.)$!$1!
```
Now (not the "X"), if the first pattern doesn't match, the last character of the path name is indexed. You must be clear on this behavior if you are using more than one ExtractPath directive with the same metaname.

The document path operated on is the real path swish used to access the document. That is, the ReplaceRules directive has no effect on the path used with ExtractPath.

The full path is used for each meta name if more than one ExtractPath pre-section"> <META NAME="meta1" CONTENT="some content">
and (if using the HTML2/libxml2 parser)
```
    <meta1>
        some content
    </meta1>
```
But this second version is invalid HTML, and will generate a warning if ParserWarningLevel is set (libxml2 only).

And in XML documents, use the format:
```
    <meta1>
        Some Content
    </meta1>
```
Then you can limit your search to just META meta1 like this:
```
    swish-e -w 'meta1=(apples or oranges)'
```
You may nest the XML and the start/end tag versions:
```
    <keywords>
        <tag1>
            some content
        </tag1>
        <tag2>
            some other content
        </tag2>
    <keywords>
```
Then you can search in both tag2 and tag2 with:
```
    swish-e -w 'keywords=(query words)'
```
Swish-e indexes all text as some metaname. The default is swishdefault, so these two queries are the same:
```
    swish-e -w foo
    swish-e -w swishdefault=foo
```
When indexing HTML Swish-e indexes the HTML title as default text, so when searching Swish-e will find matches in both the HTML body and the HTML title. Swish also, by default, indexes content of meta tags. So:
```
    swish-e -w foo
```
will find "foo" in the body, the title, or any meta tags.

Currently, there's no way to prevent Swish-e from indexing the title contents along with the body contents, but see UndefinedMetaTags for how to control the indexing of meta tags.

If you would like to search just the title text, you may use:
```
    MetaNames swishtitle
```
This will index the title text separately under the built-in swish internal meta name "swishtitle". You may then search like
```
    swish-e -w foo  -- search for "foo" in title, body (and undefined meta tags)
    swish-e -w swishtitle=foo -- search for "foo" in title only
```
In addition to swishtitle, you can limit searches to documents' path with:
```
   MetaNames swishdocpath
```
Then to search for "foo" but also limit searches to documents that include "manual" or "tutorial" in their path:
```
   swish-e -w foo swishdocpath=(manual or tutorial)
```
See also ExtractPath.
MetaNameAlias *meta name* *list of aliases*
MetaNameAlias assigns aliases for a meta name. For example, if your documents contain meta tags "description", "summary", and "overview" that all give a summary of your documents you could do this:
```
    MetaNames summary
    MetaNameAlias summary description overview
```
Then all three tags will get indexed as meta tag "summary". You can then search all the fields as:
```
    -w summary=foo
```
The Alias work at search time, too. So these will also limit the search to the "summary" meta name.
```
    -w description=foo
    -w overview=foo
```
MetaNamesRank integer *list of meta names*
You can assign a bias to metanames that will affect how ranking is calculated. The range of values is from -10 to +10, with zero being no bias.
```
    MetaNamesRank 4 subject
    MetaNamesRank 3 swishdefault
    MetaNamesRank 2 author publisher
    MetaNamesRank -5 wrongwords
```
This feature is still considered experimental. If you use it, please send feedback to the discussion list.
HTMLLinksMetaName *metaname*
Allows indexing of HTML links. Normally, HTML links (href tags) are not indexed by Swish-e. This directive defines a metaname, and links will be indexed under this meta name.

Example:
```
    HTMLLinksMetaName links
```
Now, to limit searches to files with a link to "home.html" do this:
```
    -w links='"home.html"'
```
The double quotes force a phrase search.

To make Swish-e index links as normal text, you may use:
```
    HTMLLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
ImageLinksMetaName *metaname*
Allows indexing of image links under a metaname. Normally, image URLs are not indexed.

Example:
```
    ImagesLinksMetaName images
```
Now, if you would like to find pages that include a nice image of a beach:
```
    -w images='beach'
```
To make Swish-e index links as normal text, you may use:
```
    ImageLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
IndexAltTagMetaName *tagname*|as-text
Allows indexing of images <IMG> ALT tag text. Specify either a tag name which will be used as a metaname, or the special text "as-text" which says to index the ALT text as if it were plain text at the current location.

For example, by specifying a tag name:
```
   IndexAltTagMetaName bar
```
would make this markup:
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
appear like
```
    <foo>
        <bar>Alt text here</bar>
    </foo>
```
Then the normal rules (MetaNames and PropertyNames) apply to how that text is indexed.

If you use the special tag "as-text" then
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
simply becomes
```
    <foo>
        Alt text here
    </foo>
```
This feature is only available when using the libxml2 parser (HTML2 and XML2).
AbsoluteLinks [yes|NO]
If this is set true then Swish-e will attempt to convert relative URIs extracted from HTML documents for use with HTMLLinksMetaName and ImageLinksMetaName into absolute URIs. Swish-e will use any <BASE> tag found in the document, otherwise it will use the file's pathname. The pathname used will be the pathname *after* ReplaceRules has been applied to the document's pathname.

For example, say you wish to index image links under the metaname "images".
```
    ImageLinksMetaName images
```
If an image is located in http://localhost/vacations/france/index.html and AbsoluteLinks is set to no, then a image within that document:
```
     <img src="beach.jpeg">
```
will only index "beach.jpeg".

But, if you want more detail when searching, you can enable AbsoluteLinks and Swish-e will index "http://localhost/vacations/france/beach.jpeg". You can then look for images of beaches, but only in France:
```
    -w images=(beach and france)
```
This also means you can search for any images within France:
```
    -w images=(france)
```
This feature is only available with the libxml2 HTML parser.
UndefinedMetaTags [error|ignore|INDEX|auto]
This directive defines the behavior of Swish-e during indexing when a meta name is found but is not listed in MetaNames. There are four choices:
- error
  If a meta name is found that is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force. This is the default.
- auto
  This method create meta tags automatically for HTML meta names and XML elements. Using this is the same as specifying all the meta names explicitly in a MetaNames directive.
UndefinedXMLAttributes [DISABLE|error|ignore|index|auto]
This is similar to UndefinedMetaTags, but only applies to XML documents (parsed with libxml2). This allows indexing of attribute content, and provides a way to index the content under a metaname. For example, UndefinedXMLAttributes can make
```
    <person age="23">
          John Doe
    </person>
```
look like the following to swish:
```
    <person>
        <person.age>
            23
        </person.age>
        John Doe
    </person>
```
What happens to the text "23" will depend on the setting of UndefinedXMLAttributes:
- disable
  XML attributes are not parsed and not indexed. This is the default.
- error
  If the concatenated meta name (e.g. person.age) is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force.
- auto
  This method will create meta tags from the combined element and attributes (and XML Class name) This options should be used with caution as it can generate a lot of metaname entries.
  
  See also the example below XMLClassAttribues.

XMLClassAttributes *list of XML attribute names*

Combines an XML class name with the element name to make up a metaname. For example:

    XMLClassAttributes class

    <person class="first">
        John
    </person>
    <person class="last">
        Doe
    </person>

Will appear to Swish-e as:

    <person>
        <person.first>
        John
        </person.first>
    </person>
    <person>
        <person.last>
        Doe
        </person.last>
    </person>

How the data is indexed depends on MetaNames and UndefinedMetaTags.

Here's an example using the following configuration which combines the two directives XMLClassAttributes and UndefinedXMLAttributes.

    XMLClassAttributes class
    UndefinedMetaTags auto
    UndefinedXMLAttributes auto
    IndexContents XML2 .xml

The source XML file looks like:

    <xml> <person class="student" phone="555-1212" age="102"> John </person>
    <person greeting="howdy">Bill</person> </xml>

Swish-e parses as:

    ./swish-e -c 2 -i 1.xml -T parsed_tags  parsed_text  -v 0
    Indexing Data Source: "File-System"

    <xml> (MetaName)

        <person> (MetaName)
            <person.student> (MetaName)
                <person.student.phone> (MetaName)
                    555-1212
                </person.student.phone> 
                <person.student.age> (MetaName)
                    102
                </person.student.age> 
                John
        </person> 

        <person> (MetaName)
            <person.greeting> (MetaName)
                howdy
            </person.greeting> 
            Bill
        </person> 

    </xml> 
    Indexing done!

ExtractPath *metaname* [replace|remove|prepend|append|regex]
This directive can be used to index extracted parts of a document's path. A common use would be to limit searches to specific areas of your file tree.

The extracted string will be indexed under the specified meta name.

See ReplaceRules for a description of the various pattern replacement methods, but you will use the regex method.

For example, say your file system (or web tree) was organized into departments:
```
    /web/sales/foo...
    /web/parts/foo...
    /web/accounting/foo...
```
And you wanted a way to limit searches to just documents under "sales".
```
    ExtractPath department regex !^/web/([^/]+)/.*$!$1!
```
Which says, extract out the department name (as substring $1) and index it as meta name department. Then to limit a search to the sales department:
```
    swish-e -w foo AND department=sales
```
Note that the regex method uses a substitution pattern, so to index only a sub-string match the entire document path in the regular expression, as shown above. Otherwise any part that is not matched will end up in the substitution pattern.

See the ExtractPathDefault option for a way to set a value if not patterns match.

Although unlikely, you may use more than one ExtractPath directive. More than one directive of the same meta name will operate successively (in order listed in the configuration file) on the path. This allows you to use regular expressions on the results of the previous pattern substitution (as if piping the output from one expression to the patter of the next).
```
    ExtractPath foo regex !^(...).+$!$1!
    ExtractPath foo regex !^.+(.)$!$1!
```
So, the third letter is indexed as meta name "foo" if both patterns match.
```
    ExtractPath foo regex !^X(...).+$!$1!
    ExtractPath foo regex !^.+(.)$!$1!
```
Now (not the "X"), if the first pattern doesn't match, the last character of the path name is indexed. You must be clear on this behavior if you are using more than one ExtractPath directive with the same metaname.

The document path operated on is the real path swish used to access the document. That is, the ReplaceRules directive has no effect on the path used with ExtractPath.

The full path is used for each meta name if more than one ExtractPath pre-section"> <META NAME="meta1" CONTENT="some content">
and (if using the HTML2/libxml2 parser)
```
    <meta1>
        some content
    </meta1>
```
But this second version is invalid HTML, and will generate a warning if ParserWarningLevel is set (libxml2 only).

And in XML documents, use the format:
```
    <meta1>
        Some Content
    </meta1>
```
Then you can limit your search to just META meta1 like this:
```
    swish-e -w 'meta1=(apples or oranges)'
```
You may nest the XML and the start/end tag versions:
```
    <keywords>
        <tag1>
            some content
        </tag1>
        <tag2>
            some other content
        </tag2>
    <keywords>
```
Then you can search in both tag2 and tag2 with:
```
    swish-e -w 'keywords=(query words)'
```
Swish-e indexes all text as some metaname. The default is swishdefault, so these two queries are the same:
```
    swish-e -w foo
    swish-e -w swishdefault=foo
```
When indexing HTML Swish-e indexes the HTML title as default text, so when searching Swish-e will find matches in both the HTML body and the HTML title. Swish also, by default, indexes content of meta tags. So:
```
    swish-e -w foo
```
will find "foo" in the body, the title, or any meta tags.

Currently, there's no way to prevent Swish-e from indexing the title contents along with the body contents, but see UndefinedMetaTags for how to control the indexing of meta tags.

If you would like to search just the title text, you may use:
```
    MetaNames swishtitle
```
This will index the title text separately under the built-in swish internal meta name "swishtitle". You may then search like
```
    swish-e -w foo  -- search for "foo" in title, body (and undefined meta tags)
    swish-e -w swishtitle=foo -- search for "foo" in title only
```
In addition to swishtitle, you can limit searches to documents' path with:
```
   MetaNames swishdocpath
```
Then to search for "foo" but also limit searches to documents that include "manual" or "tutorial" in their path:
```
   swish-e -w foo swishdocpath=(manual or tutorial)
```
See also ExtractPath.
MetaNameAlias *meta name* *list of aliases*
MetaNameAlias assigns aliases for a meta name. For example, if your documents contain meta tags "description", "summary", and "overview" that all give a summary of your documents you could do this:
```
    MetaNames summary
    MetaNameAlias summary description overview
```
Then all three tags will get indexed as meta tag "summary". You can then search all the fields as:
```
    -w summary=foo
```
The Alias work at search time, too. So these will also limit the search to the "summary" meta name.
```
    -w description=foo
    -w overview=foo
```
MetaNamesRank integer *list of meta names*
You can assign a bias to metanames that will affect how ranking is calculated. The range of values is from -10 to +10, with zero being no bias.
```
    MetaNamesRank 4 subject
    MetaNamesRank 3 swishdefault
    MetaNamesRank 2 author publisher
    MetaNamesRank -5 wrongwords
```
This feature is still considered experimental. If you use it, please send feedback to the discussion list.
HTMLLinksMetaName *metaname*
Allows indexing of HTML links. Normally, HTML links (href tags) are not indexed by Swish-e. This directive defines a metaname, and links will be indexed under this meta name.

Example:
```
    HTMLLinksMetaName links
```
Now, to limit searches to files with a link to "home.html" do this:
```
    -w links='"home.html"'
```
The double quotes force a phrase search.

To make Swish-e index links as normal text, you may use:
```
    HTMLLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
ImageLinksMetaName *metaname*
Allows indexing of image links under a metaname. Normally, image URLs are not indexed.

Example:
```
    ImagesLinksMetaName images
```
Now, if you would like to find pages that include a nice image of a beach:
```
    -w images='beach'
```
To make Swish-e index links as normal text, you may use:
```
    ImageLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
IndexAltTagMetaName *tagname*|as-text
Allows indexing of images <IMG> ALT tag text. Specify either a tag name which will be used as a metaname, or the special text "as-text" which says to index the ALT text as if it were plain text at the current location.

For example, by specifying a tag name:
```
   IndexAltTagMetaName bar
```
would make this markup:
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
appear like
```
    <foo>
        <bar>Alt text here</bar>
    </foo>
```
Then the normal rules (MetaNames and PropertyNames) apply to how that text is indexed.

If you use the special tag "as-text" then
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
simply becomes
```
    <foo>
        Alt text here
    </foo>
```
This feature is only available when using the libxml2 parser (HTML2 and XML2).
AbsoluteLinks [yes|NO]
If this is set true then Swish-e will attempt to convert relative URIs extracted from HTML documents for use with HTMLLinksMetaName and ImageLinksMetaName into absolute URIs. Swish-e will use any <BASE> tag found in the document, otherwise it will use the file's pathname. The pathname used will be the pathname *after* ReplaceRules has been applied to the document's pathname.

For example, say you wish to index image links under the metaname "images".
```
    ImageLinksMetaName images
```
If an image is located in http://localhost/vacations/france/index.html and AbsoluteLinks is set to no, then a image within that document:
```
     <img src="beach.jpeg">
```
will only index "beach.jpeg".

But, if you want more detail when searching, you can enable AbsoluteLinks and Swish-e will index "http://localhost/vacations/france/beach.jpeg". You can then look for images of beaches, but only in France:
```
    -w images=(beach and france)
```
This also means you can search for any images within France:
```
    -w images=(france)
```
This feature is only available with the libxml2 HTML parser.
UndefinedMetaTags [error|ignore|INDEX|auto]
This directive defines the behavior of Swish-e during indexing when a meta name is found but is not listed in MetaNames. There are four choices:
- error
  If a meta name is found that is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force. This is the default.
- auto
  This method create meta tags automatically for HTML meta names and XML elements. Using this is the same as specifying all the meta names explicitly in a MetaNames directive.
UndefinedXMLAttributes [DISABLE|error|ignore|index|auto]
This is similar to UndefinedMetaTags, but only applies to XML documents (parsed with libxml2). This allows indexing of attribute content, and provides a way to index the content under a metaname. For example, UndefinedXMLAttributes can make
```
    <person age="23">
          John Doe
    </person>
```
look like the following to swish:
```
    <person>
        <person.age>
            23
        </person.age>
        John Doe
    </person>
```
What happens to the text "23" will depend on the setting of UndefinedXMLAttributes:
- disable
  XML attributes are not parsed and not indexed. This is the default.
- error
  If the concatenated meta name (e.g. person.age) is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force.
- auto
  This method will create meta tags from the combined element and attributes (and XML Class name) This options should be used with caution as it can generate a lot of metaname entries.
  
  See also the example below XMLClassAttribues.

XMLClassAttributes *list of XML attribute names*

Combines an XML class name with the element name to make up a metaname. For example:

    XMLClassAttributes class

    <person class="first">
        John
    </person>
    <person class="last">
        Doe
    </person>

Will appear to Swish-e as:

    <person>
        <person.first>
        John
        </person.first>
    </person>
    <person>
        <person.last>
        Doe
        </person.last>
    </person>

How the data is indexed depends on MetaNames and UndefinedMetaTags.

Here's an example using the following configuration which combines the two directives XMLClassAttributes and UndefinedXMLAttributes.

    XMLClassAttributes class
    UndefinedMetaTags auto
    UndefinedXMLAttributes auto
    IndexContents XML2 .xml

The source XML file looks like:

    <xml> <person class="student" phone="555-1212" age="102"> John </person>
    <person greeting="howdy">Bill</person> </xml>

Swish-e parses as:

    ./swish-e -c 2 -i 1.xml -T parsed_tags  parsed_text  -v 0
    Indexing Data Source: "File-System"

    <xml> (MetaName)

        <person> (MetaName)
            <person.student> (MetaName)
                <person.student.phone> (MetaName)
                    555-1212
                </person.student.phone> 
                <person.student.age> (MetaName)
                    102
                </person.student.age> 
                John
        </person> 

        <person> (MetaName)
            <person.greeting> (MetaName)
                howdy
            </person.greeting> 
            Bill
        </person> 

    </xml> 
    Indexing done!

ExtractPath *metaname* [replace|remove|prepend|append|regex]
This directive can be used to index extracted parts of a document's path. A common use would be to limit searches to specific areas of your file tree.

The extracted string will be indexed under the specified meta name.

See ReplaceRules for a description of the various pattern replacement methods, but you will use the regex method.

For example, say your file system (or web tree) was organized into departments:
```
    /web/sales/foo...
    /web/parts/foo...
    /web/accounting/foo...
```
And you wanted a way to limit searches to just documents under "sales".
```
    ExtractPath department regex !^/web/([^/]+)/.*$!$1!
```
Which says, extract out the department name (as substring $1) and index it as meta name department. Then to limit a search to the sales department:
```
    swish-e -w foo AND department=sales
```
Note that the regex method uses a substitution pattern, so to index only a sub-string match the entire document path in the regular expression, as shown above. Otherwise any part that is not matched will end up in the substitution pattern.

See the ExtractPathDefault option for a way to set a value if not patterns match.

Although unlikely, you may use more than one ExtractPath directive. More than one directive of the same meta name will operate successively (in order listed in the configuration file) on the path. This allows you to use regular expressions on the results of the previous pattern substitution (as if piping the output from one expression to the patter of the next).
```
    ExtractPath foo regex !^(...).+$!$1!
    ExtractPath foo regex !^.+(.)$!$1!
```
So, the third letter is indexed as meta name "foo" if both patterns match.
```
    ExtractPath foo regex !^X(...).+$!$1!
    ExtractPath foo regex !^.+(.)$!$1!
```
Now (not the "X"), if the first pattern doesn't match, the last character of the path name is indexed. You must be clear on this behavior if you are using more than one ExtractPath directive with the same metaname.

The document path operated on is the real path swish used to access the document. That is, the ReplaceRules directive has no effect on the path used with ExtractPath.

The full path is used for each meta name if more than one ExtractPath pre-section"> <META NAME="meta1" CONTENT="some content">
and (if using the HTML2/libxml2 parser)
```
    <meta1>
        some content
    </meta1>
```
But this second version is invalid HTML, and will generate a warning if ParserWarningLevel is set (libxml2 only).

And in XML documents, use the format:
```
    <meta1>
        Some Content
    </meta1>
```
Then you can limit your search to just META meta1 like this:
```
    swish-e -w 'meta1=(apples or oranges)'
```
You may nest the XML and the start/end tag versions:
```
    <keywords>
        <tag1>
            some content
        </tag1>
        <tag2>
            some other content
        </tag2>
    <keywords>
```
Then you can search in both tag2 and tag2 with:
```
    swish-e -w 'keywords=(query words)'
```
Swish-e indexes all text as some metaname. The default is swishdefault, so these two queries are the same:
```
    swish-e -w foo
    swish-e -w swishdefault=foo
```
When indexing HTML Swish-e indexes the HTML title as default text, so when searching Swish-e will find matches in both the HTML body and the HTML title. Swish also, by default, indexes content of meta tags. So:
```
    swish-e -w foo
```
will find "foo" in the body, the title, or any meta tags.

Currently, there's no way to prevent Swish-e from indexing the title contents along with the body contents, but see UndefinedMetaTags for how to control the indexing of meta tags.

If you would like to search just the title text, you may use:
```
    MetaNames swishtitle
```
This will index the title text separately under the built-in swish internal meta name "swishtitle". You may then search like
```
    swish-e -w foo  -- search for "foo" in title, body (and undefined meta tags)
    swish-e -w swishtitle=foo -- search for "foo" in title only
```
In addition to swishtitle, you can limit searches to documents' path with:
```
   MetaNames swishdocpath
```
Then to search for "foo" but also limit searches to documents that include "manual" or "tutorial" in their path:
```
   swish-e -w foo swishdocpath=(manual or tutorial)
```
See also ExtractPath.
MetaNameAlias *meta name* *list of aliases*
MetaNameAlias assigns aliases for a meta name. For example, if your documents contain meta tags "description", "summary", and "overview" that all give a summary of your documents you could do this:
```
    MetaNames summary
    MetaNameAlias summary description overview
```
Then all three tags will get indexed as meta tag "summary". You can then search all the fields as:
```
    -w summary=foo
```
The Alias work at search time, too. So these will also limit the search to the "summary" meta name.
```
    -w description=foo
    -w overview=foo
```
MetaNamesRank integer *list of meta names*
You can assign a bias to metanames that will affect how ranking is calculated. The range of values is from -10 to +10, with zero being no bias.
```
    MetaNamesRank 4 subject
    MetaNamesRank 3 swishdefault
    MetaNamesRank 2 author publisher
    MetaNamesRank -5 wrongwords
```
This feature is still considered experimental. If you use it, please send feedback to the discussion list.
HTMLLinksMetaName *metaname*
Allows indexing of HTML links. Normally, HTML links (href tags) are not indexed by Swish-e. This directive defines a metaname, and links will be indexed under this meta name.

Example:
```
    HTMLLinksMetaName links
```
Now, to limit searches to files with a link to "home.html" do this:
```
    -w links='"home.html"'
```
The double quotes force a phrase search.

To make Swish-e index links as normal text, you may use:
```
    HTMLLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
ImageLinksMetaName *metaname*
Allows indexing of image links under a metaname. Normally, image URLs are not indexed.

Example:
```
    ImagesLinksMetaName images
```
Now, if you would like to find pages that include a nice image of a beach:
```
    -w images='beach'
```
To make Swish-e index links as normal text, you may use:
```
    ImageLinksMetaName swishdefault
```
This feature is only available with the libxml2 HTML parser.
IndexAltTagMetaName *tagname*|as-text
Allows indexing of images <IMG> ALT tag text. Specify either a tag name which will be used as a metaname, or the special text "as-text" which says to index the ALT text as if it were plain text at the current location.

For example, by specifying a tag name:
```
   IndexAltTagMetaName bar
```
would make this markup:
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
appear like
```
    <foo>
        <bar>Alt text here</bar>
    </foo>
```
Then the normal rules (MetaNames and PropertyNames) apply to how that text is indexed.

If you use the special tag "as-text" then
```
    <foo>
        <img src="/someimage.png" alt="Alt text here">
    </foo>
```
simply becomes
```
    <foo>
        Alt text here
    </foo>
```
This feature is only available when using the libxml2 parser (HTML2 and XML2).
AbsoluteLinks [yes|NO]
If this is set true then Swish-e will attempt to convert relative URIs extracted from HTML documents for use with HTMLLinksMetaName and ImageLinksMetaName into absolute URIs. Swish-e will use any <BASE> tag found in the document, otherwise it will use the file's pathname. The pathname used will be the pathname *after* ReplaceRules has been applied to the document's pathname.

For example, say you wish to index image links under the metaname "images".
```
    ImageLinksMetaName images
```
If an image is located in http://localhost/vacations/france/index.html and AbsoluteLinks is set to no, then a image within that document:
```
     <img src="beach.jpeg">
```
will only index "beach.jpeg".

But, if you want more detail when searching, you can enable AbsoluteLinks and Swish-e will index "http://localhost/vacations/france/beach.jpeg". You can then look for images of beaches, but only in France:
```
    -w images=(beach and france)
```
This also means you can search for any images within France:
```
    -w images=(france)
```
This feature is only available with the libxml2 HTML parser.
UndefinedMetaTags [error|ignore|INDEX|auto]
This directive defines the behavior of Swish-e during indexing when a meta name is found but is not listed in MetaNames. There are four choices:
- error
  If a meta name is found that is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force. This is the default.
- auto
  This method create meta tags automatically for HTML meta names and XML elements. Using this is the same as specifying all the meta names explicitly in a MetaNames directive.
UndefinedXMLAttributes [DISABLE|error|ignore|index|auto]
This is similar to UndefinedMetaTags, but only applies to XML documents (parsed with libxml2). This allows indexing of attribute content, and provides a way to index the content under a metaname. For example, UndefinedXMLAttributes can make
```
    <person age="23">
          John Doe
    </person>
```
look like the following to swish:
```
    <person>
        <person.age>
            23
        </person.age>
        John Doe
    </person>
```
What happens to the text "23" will depend on the setting of UndefinedXMLAttributes:
- disable
  XML attributes are not parsed and not indexed. This is the default.
- error
  If the concatenated meta name (e.g. person.age) is not listed in MetaNames then indexing will be halted and an error reported.
- ignore
  The contents of the meta tag are ignored and not indexed unless a metaname has been defined with the MetaNames directive.
- index
  The contents of the meta tag are indexed, but placed in the main index unless there's an enclosing metatag already in force.
- auto
  This method will create meta tags from the combined element and attributes (and XML Class name) This options should be used with caution as it can generate a lot of metaname entries.
  
  See also the example below XMLClassAttribues.

XMLClassAttributes *list of XML attribute names*

Combines an XML class name with the element name to make up a metaname. For example:

    XMLClassAttributes class

    <person class="first">
        John
    </person>
    <person class="last">
        Doe
    </person>

Will appear to Swish-e as:

    <person>
        <person.first>
        John
        </person.first>
    </person>
    <person>
        <person.last>
        Doe
        </person.last>
    </person>

How the data is indexed depends on MetaNames and UndefinedMetaTags.

Here's an example using the following configuration which combines the two directives XMLClassAttributes and UndefinedXMLAttributes.

    XMLClassAttributes class
    UndefinedMetaTags auto
    UndefinedXMLAttributes auto
    IndexContents XML2 .xml

The source XML file looks like:

    <xml> <person class="student" phone="555-1212" age="102"> John </person>
    <person greeting="howdy">Bill</person> </xml>

Swish-e parses as:

    ./swish-e -c 2 -i 1.xml -T parsed_tags  parsed_text  -v 0
    Indexing Data Source: "File-System"

    <xml> (MetaName)

        <person> (MetaName)
            <person.student> (MetaName)
                <person.student.phone> (MetaName)
                    555-1212
                </person.student.phone> 
                <person.student.age> (MetaName)
                    102
                </person.student.age> 
                John
        </person> 

        <person> (MetaName)
            <person.greeting> (MetaName)
                howdy
            </person.greeting> 
            Bill
        </person> 

    </xml> 
    Indexing done!

ExtractPath *metaname* [replace|remove|prepend|append|regex]
This directive can be used to index extracted parts of a document's path. A common use would be to limit searches to specific areas of your file tree.

The extracted string will be indexed under the specified meta name.

See ReplaceRules for a description of the various pattern replacement methods, but you will use the regex method.

For example, say your file system (or web tree) was organized into departments:
```
    /web/sales/foo...
    /web/parts/foo...
    /web/accounting/foo...
```
And you wanted a way to limit searches to just documents under "sales".
```
    ExtractPath department regex !^/web/([^/]+)/.*$!$1!
```
Which says, extract out the department name (as substring $1) and index it as meta name department. Then to limit a search to the sales department:
```
    swish-
```

Swish-e

SWISH-CONFIG - Configuration File Directives

Table of Contents

OVERVIEW

CONFIGURATION FILE

Alphabetical Listing of Directives

Directives that Control Swish

Administrative Headers Directives

Document Source Directives

Document Contents Directives