lexnames

title: lexnames(5)

text:
# lexnames(5)

## NAME
lexnames - List of WordNet lexicographer file names and numbers

## DESCRIPTION
During WordNet development synsets are organized into forty-five lexicographer files based on syntactic category and logical groupings. grind(1) processes these files and produces a database suitable for use with the WordNet library, interface code, and other applications. The format of the lexicographer files is described in wninput(5).

A file number corresponds to each lexicographer file. File numbers are encoded in several parts of the WordNet system as an efficient way to indicate a lexicographer file name. The file lexnames lists the mapping between file names and numbers, and can be used by programs or end users to correlate the two.

### File Format
Each line in lexnames contains 3 tab separated fields, and is terminated with a newline character. The first field is the two digit decimal integer file number. (The first file in the list is numbered 00.) The second field is the name of the lexicographer file that is represented by that number, and the third field is an integer that indicates the syntactic category of the synsets contained in the file. This is simply a shortcut for programs and scripts, since the syntactic category is also part of the lexicographer file's name.

### Syntactic Category
The syntactic category field is encoded as follows:

```
1	NOUN
2	VERB
3	ADJECTIVE
4	ADVERB
```

### Lexicographer Files
The names of the lexicographer files and their corresponding file numbers are listed below along with a brief description each file's contents.

File Number

Name

Contents

00

adj.all

all adjective clusters

01

adj.pert

relational adjectives (pertainyms)

02

adv.all

all adverbs

03

noun.Tops

unique beginner for nouns

04

noun.act

nouns denoting acts or actions

05

noun.animal

nouns denoting animals

06

noun.artifact

nouns denoting man-made objects

07

noun.attribute

nouns denoting attributes of people and objects

08

noun.body

nouns denoting body parts

09

noun.cognition

nouns denoting cognitive processes and contents

10

noun.communication

nouns denoting communicative processes and contents

11

noun.event

nouns denoting natural events

12

noun.feeling

nouns denoting feelings and emotions

13

noun.food

nouns denoting foods and drinks

14

noun.group

nouns denoting groupings of people or objects

15

noun.location

nouns denoting spatial position

16

noun.motive

nouns denoting goals

17

noun.object

nouns denoting natural objects (not man-made)

18

noun.person

nouns denoting people

19

noun.phenomenon

nouns denoting natural phenomena

20

noun.plant

nouns denoting plants

21

noun.possession

nouns denoting possession and transfer of possession

22

noun.process

nouns denoting natural processes

23

noun.quantity

nouns denoting quantities and units of measure

24

noun.relation

nouns denoting relations between people or things or ideas

25

noun.shape

nouns denoting two and three dimensional shapes

26

noun.state

nouns denoting stable states of affairs

27

noun.substance

nouns denoting substances

28

noun.time

nouns denoting time and temporal relations

29

verb.body

verbs of grooming, dressing and bodily care

30

verb.change

verbs of size, temperature change, intensifying, etc.

31

verb.cognition

verbs of thinking, judging, analyzing, doubting

32

verb.communication

verbs of telling, asking, ordering, singing

33

verb.competition

verbs of fighting, athletic activities

34

verb.consumption

verbs of eating and drinking

35

verb.contact

verbs of touching, hitting, tying, digging

36

verb.creation

verbs of sewing, baking, painting, performing

37

verb.emotion

verbs of feeling

38

verb.motion

verbs of walking, flying, swimming

39

verb.perception

verbs of seeing, hearing, feeling

40

verb.possession

verbs of buying, selling, owning

41

verb.social

verbs of political and social activities and events

42

verb.stative

verbs of being, having, spatial relations

43

verb.weather

verbs of raining, snowing, thawing, thundering

44

adj.ppl

participial adjectives

## NOTES
The lexicographer files are not included in the WordNet database package.

## ENVIRONMENT VARIABLES (UNIX)
WNHOME

Base directory for WordNet. Default is /usr/local/WordNet-3.0.

WNSEARCHDIR

Directory in which the WordNet database has been installed. Default is WNHOME/dict.

## REGISTRY (WINDOWS)
HKEY_LOCAL_MACHINE\SOFTWARE\WordNet\3.0\WNHome

Base directory for WordNet. Default is C:\Program Files\WordNet\3.0.

## FILES
lexnames

list of lexicographer file names and numbers

## SEE ALSO
grind(1), wnintro(5), wndb(5), wninput(5).


wndb

package: wordnet-dict

title: wndb(5)

summary: WordNet database files

text:
# wndb(5)

## NAME
index.noun, data.noun, index.verb, data.verb, index.adj, data.adj, index.adv, data.adv - WordNet database files

noun.exc, verb.exc. adj.exc adv.exc - morphology exception lists

sentidx.vrb, sents.vrb - files used by search code to display sentences illustrating the use of some specific verbs

## DESCRIPTION
For each syntactic category, two files are needed to represent the contents of the WordNet database - index.pos and data.pos, where pos is noun, verb, adj and adv. The other auxiliary files are used by the WordNet library's searching functions and are needed to run the various WordNet browsers.

Each index file is an alphabetized list of all the words found in WordNet in the corresponding part of speech. On each line, following the word, is a list of byte offsets (synset_offsets) in the corresponding data file, one for each synset containing the word. Words in the index file are in lower case only, regardless of how they were entered in the lexicographer files. This folds various orthographic representations of the word into one line enabling database searches to be case insensitive. See wninput(5) for a detailed description of the lexicographer files

A data file for a syntactic category contains information corresponding to the synsets that were specified in the lexicographer files, with relational pointers resolved to synset_offsets. Each line corresponds to a synset. Pointers are followed and hierarchies traversed by moving from one synset to another via the synset_offsets.

The exception list files, pos.exc, are used to help the morphological processor find base forms from irregular inflections.

The files sentidx.vrb and sents.vrb contain sentences illustrating the use of specific senses of some verbs. These files are used by the searching software in response to a request for verb sentence frames. Generic sentence frames are displayed when an illustrative sentence is not present.

The various database files are in ASCII formats that are easily read by both humans and machines. All fields, unless otherwise noted, are separated by one space character, and all lines are terminated by a newline character. Fields enclosed in italicized square brackets may not be present.

See wngloss(7) for a glossary of WordNet terminology and a discussion of the database's content and logical organization.

### Index File Format
Each index file begins with several lines containing a copyright notice, version number and license agreement. These lines all begin with two spaces and the line number so they do not interfere with the binary search algorithm that is used to look up entries in the index files. All other lines are in the following format. In the field descriptions, number always refers to a decimal integer unless otherwise defined.

```
lemma  pos  synset_cnt  p_cnt  [ptr_symbol...]  sense_cnt  tagsense_cnt   synset_offset  [synset_offset...]
```

lemma

lower case ASCII text of word or collocation. Collocations are formed by joining individual words with an underscore (_) character.

pos

Syntactic category: n for noun files, v for verb files, a for adjective files, r for adverb files.

All remaining fields are with respect to senses of lemma in pos.

synset_cnt

Number of synsets that lemma is in. This is the number of senses of the word in WordNet. See Sense Numbers below for a discussion of how sense numbers are assigned and the order of synset_offsets in the index files.

p_cnt

Number of different pointers that lemma has in all synsets containing it.

ptr_symbol

A space separated list of p_cnt different types of pointers that lemma has in all synsets containing it. See wninput(5) for a list of pointer_symbols. If all senses of lemma have no pointers, this field is omitted and p_cnt is 0.

sense_cnt

Same as sense_cnt above. This is redundant, but the field was preserved for compatibility reasons.

tagsense_cnt

Number of senses of lemma that are ranked according to their frequency of occurrence in semantic concordance texts.

synset_offset

Byte offset in data.pos file of a synset containing lemma. Each synset_offset in the list corresponds to a different sense of lemma in WordNet. synset_offset is an 8 digit, zero-filled decimal integer that can be used with fseek(3) to read a synset from the data file. When passed to read_synset(3) along with the syntactic category, a data structure containing the parsed synset is returned.

### Data File Format
Each data file begins with several lines containing a copyright notice, version number and license agreement. These lines all begin with two spaces and the line number. All other lines are in the following format. Integer fields are of fixed length, and are zero-filled.

```
synset_offset  lex_filenum  ss_type  w_cnt  word  lex_id  [word  lex_id...]  p_cnt  [ptr...]  [frames...]  |  gloss
```

synset_offset

Current byte offset in the file represented as an 8 digit decimal integer.

lex_filenum

Two digit decimal integer corresponding to the lexicographer file name containing the synset. See lexnames(5) for the list of filenames and their corresponding numbers.

ss_type

One character code indicating the synset type:

```
n	NOUN
v	VERB
a	ADJECTIVE
s	ADJECTIVE SATELLITE
r	ADVERB
```

w_cnt

Two digit hexadecimal integer indicating the number of words in the synset.

word

ASCII form of a word as entered in the synset by the lexicographer, with spaces replaced by underscore characters (_). The text of the word is case sensitive, in contrast to its form in the corresponding index.pos file, that contains only lower-case forms. In data.adj, a word is followed by a syntactic marker if one was specified in the lexicographer file. A syntactic marker is appended, in parentheses, onto word without any intervening spaces. See wninput(5) for a list of the syntactic markers for adjectives.

lex_id

One digit hexadecimal integer that, when appended onto lemma, uniquely identifies a sense within a lexicographer file. lex_id numbers usually start with 0, and are incremented as additional senses of the word are added to the same file, although there is no requirement that the numbers be consecutive or begin with 0. Note that a value of 0 is the default, and therefore is not present in lexicographer files.

p_cnt

Three digit decimal integer indicating the number of pointers from this synset to other synsets. If p_cnt is 000 the synset has no pointers.

ptr

A pointer from this synset to another. ptr is of the form:

```
pointer_symbol  synset_offset  pos  source/target
```

where synset_offset is the byte offset of the target synset in the data file corresponding to pos.

The source/target field distinguishes lexical and semantic pointers. It is a four byte field, containing two two-digit hexadecimal integers. The first two digits indicates the word number in the current (source) synset, the last two digits indicate the word number in the target synset. A value of 0000 means that pointer_symbol represents a semantic relation between the current (source) synset and the target synset indicated by synset_offset.

A lexical relation between two words in different synsets is represented by non-zero values in the source and target word numbers. The first and last two bytes of this field indicate the word numbers in the source and target synsets, respectively, between which the relation holds. Word numbers are assigned to the word fields in a synset, from left to right, beginning with 1.

See wninput(5) for a list of pointer_symbols, and semantic and lexical pointer classifications.

frames

In data.verb only, a list of numbers corresponding to the generic verb sentence frames for words in the synset. frames is of the form:

```
f_cnt   +   f_num  w_num  [ +   f_num  w_num...]
```

where f_cnt a two digit decimal integer indicating the number of generic frames listed, f_num is a two digit decimal integer frame number, and w_num is a two digit hexadecimal integer indicating the word in the synset that the frame applies to. As with pointers, if this number is 00, f_num applies to all words in the synset. If non-zero, it is applicable only to the word indicated. Word numbers are assigned as described for pointers. Each f_num w_num pair is preceded by a +. See wninput(5) for the text of the generic sentence frames.

gloss

Each synset contains a gloss. A gloss is represented as a vertical bar (|), followed by a text string that continues until the end of the line. The gloss may contain a definition, one or more example sentences, or both.

### Sense Numbers
Senses in WordNet are generally ordered from most to least frequently used, with the most common sense numbered 1. Frequency of use is determined by the number of times a sense is tagged in the various semantic concordance texts. Senses that are not semantically tagged follow the ordered senses. The tagsense_cnt field for each entry in the index.pos files indicates how many of the senses in the list have been tagged.

The cntlist(5) file provided with the database lists the number of times each sense is tagged in the semantic concordances. The data from cntlist is used by grind(1) to order the senses of each word. When the index.pos files are generated, the synset_offsets are output in sense number order, with sense 1 first in the list. Senses with the same number of semantic tags are assigned unique but consecutive sense numbers. The WordNet OVERVIEW search displays all senses of the specified word, in all syntactic categories, and indicates which of the senses are represented in the semantically tagged texts.

### Exception List File Format
Exception lists are alphabetized lists of inflected forms of words and their base forms. The first field of each line is an inflected form, followed by a space separated list of one or more base forms of the word. There is one exception list file for each syntactic category.

Note that the noun and verb exception lists were automatically generated from a machine-readable dictionary, and contain many words that are not in WordNet. Also, for many of the inflected forms, base forms could be easily derived using the standard rules of detachment programmed into Morphy (See morph(7)). These anomalies are allowed to remain in the exception list files, as they do no harm.

### Verb Example Sentences
For some verb senses, example sentences illustrating the use of the verb sense can be displayed. Each line of the file sentidx.vrb contains a sense_key followed by a space and a comma separated list of example sentence template numbers, in decimal. The file sents.vrb lists all of the example sentence templates. Each line begins with the template number followed by a space. The rest of the line is the text of a template example sentence, with %s used as a placeholder in the text for the verb. Both files are sorted alphabetically so that the sense_key and template sentence number can be used as indices, via binsrch(3), into the appropriate file.

When a request for FRAMES is made, the WordNet search code looks for the sense in sentidx.vrb. If found, the sentence template(s) listed is retrieved from sents.vrb, and the %s is replaced with the verb. If the sense is not found, the applicable generic sentence frame(s) listed in frames is displayed.

## NOTES
Information in the data.pos and index.pos files represents all of the word senses and synsets in the WordNet database. The word, lex_id, and lex_filenum fields together uniquely identify each word sense in WordNet. These can be encoded in a sense_key as described in senseidx(5). Each synset in the database can be uniquely identified by combining the synset_offset for the synset with a code for the syntactic category (since it is possible for synsets in different data.pos files to have the same synset_offset).

The WordNet system provide both command line and window-based browser interfaces to the database. Both interfaces utilize a common library of search and morphology code. The source code for the library and interfaces is included in the WordNet package. See wnintro(3) for an overview of the WordNet source code.

## ENVIRONMENT VARIABLES (UNIX)
WNHOME

Base directory for WordNet. Default is /usr/local/WordNet-3.0.

WNSEARCHDIR

Directory in which the WordNet database has been installed. Default is WNHOME/dict.

## REGISTRY (WINDOWS)
HKEY_LOCAL_MACHINE\SOFTWARE\WordNet\3.0\WNHome

Base directory for WordNet. Default is C:\Program Files\WordNet\3.0.

## FILES
index.pos

database index files

data.pos

database data files

*.vrb

files of sentences illustrating the use of verbs

pos.exc

morphology exception lists

## SEE ALSO
grind(1), wn(1), wnb(1), wnintro(3), binsrch(3), wnintro(5), cntlist(5), lexnames(5), senseidx(5), wninput(5), morphy(7), wngloss(7), wngroups(7), wnstats(7).


wninput

title: wninput(5)

text:
# wninput(5)

## NAME
noun.suffix, verb.suffix, adj.suffix, adv.suffix - WordNet lexicographer files that are input to grind(1)

## DESCRIPTION
WordNet's source files are written by lexicographers. They are the product of a detailed relational analysis of lexical semantics: a variety of lexical and semantic relations are used to represent the organization of lexical knowledge. Two kinds of building blocks are distinguished in the source files: word forms and word meanings. Word forms are represented in their familiar orthography; word meanings are represented by synonym sets (synsets) - lists of synonymous word forms that are interchangeable in some context. Two kinds of relations are recognized: lexical and semantic. Lexical relations hold between word forms; semantic relations hold between word meanings.

Lexicographer files correspond to the syntactic categories implemented in WordNet - noun, verb, adjective and adverb. All of the synsets in a lexicographer file are in the same syntactic category. Each synset consists of a list of synonymous words or collocations (eg. "fountain pen", "take in"), and pointers that describe the relations between this synset and other synsets. These relations include (but are not limited to) hypernymy/hyponymy, antonymy, entailment, and meronymy/holonymy. A word or collocation may appear in more than one synset, and in more than one part of speech. Each use of a word in a synset represents a sense of that word in the part of speech corresponding to the synset.

Adjectives may be organized into clusters containing head synsets and satellite synsets. Adverbs generally point to the adjectives from which they are derived.

See wngloss(7) for a glossary of WordNet terminology and a discussion of the database's content and logical organization.

### Lexicographer File Names
The names of the lexicographer files are of the form:

pos.suffix

where pos is either noun, verb, adj or adv. suffix may be used to organize groups of synsets into different files, for example noun.animal and noun.plant. See lexnames(5) for a list of lexicographer file names that are used in building WordNet.

### Pointers
Pointers are used to represent the relations between the words in one synset and another. Semantic pointers represent relations between word meanings, and therefore pertain to all of the words in the source and target synsets. Lexical pointers represent relations between word forms, and pertain only to specific words in the source and target synsets. The following pointer types are usually used to indicate lexical relations: Antonym, Pertainym, Participle, Also See, Derivationally Related. The remaining pointer types are generally used to represent semantic relations.

A relation from a source to a target synset is formed by specifying a word from the target synset in the source synset, followed by the pointer_symbol indicating the pointer type. The location of a pointer within a synset defines it as either lexical or semantic. The Lexicographer File Format section describes the syntax for entering a semantic pointer, and Word Syntax describes the syntax for entering a lexical pointer.

Although there are many pointer types, only certain types of relations are permitted between synsets of each syntactic category.

The pointer_symbols for nouns are:

```
! 	Antonym
@	Hypernym
@i	Instance Hypernym
∼	Hyponym
∼i	Instance Hyponym
#m	Member holonym
#s	Substance holonym
#p	Part holonym
%m	Member meronym
%s	Substance meronym
%p	Part meronym
=	Attribute
+	Derivationally related form
;c	Domain of synset - TOPIC
-c	Member of this domain - TOPIC
;r	Domain of synset - REGION
-r	Member of this domain - REGION
;u	Domain of synset - USAGE
-u	Member of this domain - USAGE
```

```

```

The pointer_symbols for verbs are:

```
! 	Antonym
@	Hypernym
∼	Hyponym
*	Entailment
>	Cause
^	Also see
$	Verb Group
+	Derivationally related form
;c	Domain of synset - TOPIC
;r	Domain of synset - REGION
;u	Domain of synset - USAGE
```

The pointer_symbols for adjectives are:

```
!	Antonym
&	Similar to
<	Participle of verb
\	Pertainym (pertains to noun)
=	Attribute
^	Also see
;c	Domain of synset - TOPIC
;r	Domain of synset - REGION
;u	Domain of synset - USAGE
```

The pointer_symbols for adverbs are:

```
!	Antonym
\	Derived from adjective
;c	Domain of synset - TOPIC
;r	Domain of synset - REGION
;u	Domain of synset - USAGE
```

Many pointer types are reflexive, meaning that if a synset contains a pointer to another synset, the other synset should contain a corresponding reflexive pointer. grind(1) automatically inserts missing reflexive pointers for the following pointer types:

Pointer

Reflect

Antonym

Antonym

Hyponym

Hypernym

Hypernym

Hyponym

Instance Hyponym

Instance Hypernym

Instance Hypernym

Instance Hyponym

Holonym

Meronym

Meronym

Holonym

Similar to

Similar to

Attribute

Attribute

Verb Group

Verb Group

Derivationally Related

Derivationally Related

Domain of synset

Member of Doman

### Verb Frames
Each verb synset contains a list of generic sentence frames illustrating the types of simple sentences in which the verbs in the synset can be used. For some verb senses, example sentences illustrating actual uses of the verb are provided. (See Verb Example Sentences in wndb(5).) Whenever there is no example sentence, the generic sentence frames specified by the lexicographer are used. The generic sentence frames are entered in a synset as a comma-separated list of integer frame numbers. The following list is the text of the generic frames, preceded by their frame numbers:

```
1	Something ----s
2	Somebody ----s
3	It is ----ing
4	Something is ----ing PP
5	Something ----s something Adjective/Noun
6	Something ----s Adjective/Noun
7	Somebody ----s Adjective
8	Somebody ----s something
9	Somebody ----s somebody
10	Something ----s somebody
11	Something ----s something
12	Something ----s to somebody
13	Somebody ----s on something
14	Somebody ----s somebody something
15	Somebody ----s something to somebody
16	Somebody ----s something from somebody
17	Somebody ----s somebody with something
18	Somebody ----s somebody of something
19	Somebody ----s something on somebody
20	Somebody ----s somebody PP
21	Somebody ----s something PP
22	Somebody ----s PP
23	Somebody's (body part) ----s
24	Somebody ----s somebody to INFINITIVE
25	Somebody ----s somebody INFINITIVE
26	Somebody ----s that CLAUSE
27	Somebody ----s to somebody
28	Somebody ----s to INFINITIVE
29	Somebody ----s whether INFINITIVE
30	Somebody ----s somebody into V-ing something
31	Somebody ----s something with something
32	Somebody ----s INFINITIVE
33	Somebody ----s VERB-ing
34	It ----s that CLAUSE
35	Something ----s INFINITIVE
```

### Lexicographer File Format
Synsets are entered one per line, and each line is terminated with a newline character. A line containing a synset may be as long as necessary, but no newlines can be entered within a synset. Within a synset, spaces or tabs may be used to separate entities. Items enclosed in italicized square brackets may not be present.

The general synset syntax is:

```
{   words  pointers   (  gloss  )  }
```

Synsets of this form are valid for all syntactic categories except verb, and are referred to as basic synsets. At least one word and a gloss are required to form a valid synset. Pointers entered following all the words in a synset represent semantic relations between all the words in the source and target synsets.

For verbs, the basic synset syntax is defined as follows:

```
{   words  pointers  frames   (  gloss  )  }
```

Adjective may be organized into clusters containing one or more head synsets and optional satellite synsets. Adjective clusters are of the form:

```
[
head synset
[satellite synsets]
[-]
[additional head/satellite synsets]
]
```

Each adjective cluster is enclosed in square brackets, and may have one or more parts. Each part consists of a head synset and optional satellite synsets that are conceptually similar to the head synset's meaning. Parts of a cluster are separated by one or more hyphens (-) on a line by themselves, with the terminating square bracket following the last synset. Head and satellite synsets follow the syntax of basic synsets, however a "Similar to" pointer must be specified in a head synset for each of its satellite synsets. Most adjective clusters contain two antonymous parts. See wngloss(7) for a discussion of adjective clusters, and Special Adjective Syntax for more information on adjective cluster syntax.

Synsets for relational adjectives (pertainyms) and participial adjectives do not adhere to the cluster structure. They use the basic synset syntax.

Comments can be entered in a lexicographer file by enclosing the text of the comment in parentheses. Note that comments cannot appear within a synset, as parentheses within a synset have an entirely different meaning (see Gloss Syntax ). However, entire synsets (or adjective clusters) can be "commented out" by enclosing them in parentheses. This is often used by the lexicographers to verify the syntax of files under development or to leave a note to oneself while working on entries.

### Word Syntax
A synset must have at least one word, and the words of a synset must appear after the opening brace and before any other synset constructs. A word may be entered in either the simple word or word/pointer syntax.

A simple word is of the form:

```
word[ ( marker ) ][lex_id] ,
```

word may be entered in any combination of upper and lower case unless it is in an adjective cluster. A collocation is entered by joining the individual words with an underscore character (_). Numbers (integer or real) may be entered, either by themselves or as part of a word string, by following the number with a double quote (").

See Special Adjective Syntax for a description of adjective clusters and markers.

word may be followed by an integer lex_id from 1 to 15. The lex_id is used to distinguish different senses of the same word within a lexicographer file. The lexicographer assigns lex_id values, usually in ascending order, although there is no requirement that the numbers be consecutive. The default is 0, and does not have to be specified. A lex_id must be used on pointers if the desired sense has a non-zero lex_id in its synset specification.

Word/pointer syntax is of the form:

```
[   word[ ( marker ) ][lex_id] ,   pointers   ]
```

This syntax is used when one or more pointers correspond only to the specific word in the word/pointer set, rather than all the words in the synset, and represents a lexical relation. Note that a word/pointer set appears within a synset, therefore the square brackets used to enclose it are treated differently from those used to define an adjective cluster. Only one word can be specified in each word/pointer set, and any number of pointers may be included. A synset can have any number of word/pointer sets. Each is treated by grind(1) essentially as a word, so they all must appear before any synset pointers representing semantic relations.

For verbs, the word/pointer syntax is extended in the following manner to allow the user to specify generic sentence frames that, like pointers, correspond only to a specific word, rather than all the words in the synset. In this case, pointers are optional.

```
[   word ,   [pointers]  frames   ]
```

### Pointer Syntax
Pointers are optional in synsets. If a pointer is specified outside of a word/pointer set, the relation is applied to all of the words in the synset, including any words specified using the word/pointer syntax. This indicates a semantic relation between the meanings of the words in the synsets. If specified within a word/pointer set, the relation corresponds only to the word in the set and represents a lexical relation.

A pointer is of the form:

```
[lex_filename: ]word[lex_id],pointer_symbol
```

or:

```
[lex_filename: ]word[lex_id]^word[lex_id],pointer_symbol
```

For pointers, word indicates a word in another synset. When the second form of a pointer is used, the first word indicates a word in a head synset, and the second is a word in a satellite of that cluster. word may be followed by a lex_id that is used to match the pointer to the correct target synset. The synset containing word may reside in another lexicographer file. In this case, word is preceded by lex_filename as shown.

See Pointers for a list of pointer_symbols and their meanings.

### Verb Frame List Syntax
Frame numbers corresponding to generic sentence frames must be entered in each verb synset. If a frame list is specified outside of a word/pointer set, the verb frames in the list apply to all of the words in the synset, including any words specified using the word/pointer syntax. If specified within a word/pointer set, the verb frames in the list correspond only to the word in the set.

A frame number list is entered as follows:

frames: f_num[,f_num...]

Where f_num specifies a generic frame number. See Verb Frames for a list of generic sentences and their corresponding frame numbers.

### Gloss Syntax
A gloss is included in all synsets. The lexicographer may enter a text string of any length desired. A gloss is simply a string enclosed in parentheses with no embedded carriage returns. It provides a definition of what the synset represents and/or example sentences.

### Special Adjective Syntax
The syntax for representing antonymous adjective synsets requires several additional conditions.

The first word of a head synset must be entered in upper case, and can be thought of as the head word of the head synset. The word part of a pointer from one head synset to another head synset within the same cluster (usually an antonym) must also be entered in upper case. Usually antonymous adjectives are entered using the word/pointer syntax described in Word Syntax to indicate a lexical relation. There is no restriction on the number of parts that a cluster may have, and some clusters have three parts, representing antonymous triplets, such as solid, liquid, and gas.

A cross-cluster pointer may be specified, allowing a head or satellite synset to point to a head synset in a different cluster. A cross-cluster pointer is indicated by entering the word part of the pointer in upper case.

An adjective may be annotated with a syntactic marker indicating a limitation on the syntactic position the adjective may have in relation to noun that it modifies. If so marked, the marker appears between the word and its following comma. If a lex_id is specified, the marker immediately follows it. The syntactic markers are:

```
(p)	predicate position
(a)	prenominal (attributive) position
(ip)	immediately postnominal position
```

## EXAMPLES
(Note that these are hypothetical examples not found in the WordNet lexicographer files.)

Sample noun synsets:

```
{ canine, [ dog1, cat,! ] pooch, canid,@ }
{ collie, dog1,@ (large multi-colored dog with pointy nose) }
{ hound, hunting_dog, pack,#m dog1,@ }
{ dog, }
```

Sample verb synsets:

```
{ [ confuse, clarify,! frames: 1 ] blur, obscure, frames: 8, 10 }
{ [ clarify, confuse,! ] make_clear, interpret,@ frames: 8 }
{ interpret, construe, understand,@ frames: 8 }
```

Sample adjective clusters:

```
[
{ [ HOT, COLD,! ] lukewarm(a), TEPID,^ (hot to the touch) }
{ warm, }
-
{ [ COLD, HOT,! ] frigid, (cold to the touch) }
{ freezing, }
]
```

Sample adverb synsets:

```
{ [ basically, adj.all:essential^basic,\ ] [ essentially, adj.all:basic^fundamental,\ ] ( by one's very nature )}
{ pointedly, adj.all:pungent^pointed,\ }
{ [ badly, adj.all:bad,\ well,! ] ill, ("He was badly prepared") }
```

## SEE ALSO
grind(1), wnintro(5), lexnames(5), wndb(5), uniqbeg(7), wngloss(7).

Fellbaum, C. (1998), ed. "WordNet: An Electronic Lexical Database". MIT Press, Cambridge, MA.


wnintro

title: wnintro(5)

text:
# wnintro(5)

## NAME
wnintro - introduction to descriptions of WordNet file formats

## SYNOPSIS
cntlist - format of cntlist and cntlist.rev files

lexnames - list of lexicographer file names and numbers

prologdb - description of Prolog database files

senseidx - format of sense index file

sensemap - mapping from senses in WordNet 2.1 to corresponding 3.0 senses

wndb - format of WordNet database files

wninput - format of WordNet lexicographer files

## DESCRIPTION
This section of the WordNet Reference Manual contains manual pages that describe the formats of the various files included in different WordNet 3.0 packages.

## NOMENCLATURE
All files are in ASCII. Fields are generally separated by one space, unless otherwise noted, and each line is terminated with a newline character. In the file format descriptions, terms in italics refer to field names. Characters or strings in boldface represent an actual character or string as it appears in the file. Items enclosed in italicized square brackets ([ ]) may not be present. Since several files contain fields that have the identical meaning, field names are consistently defined. For example, several WordNet files contain one or more synset_offset fields. In each case, the definition of synset_offset is identical.

## SEE ALSO
wnintro(1), wnintro(3), cntlist(5), lexnames(5), prologdb(5), senseidx(5), sensemap(5), wndb(5), wninput(5), wnintro(7), wngloss(7).

Fellbaum, C. (1998), ed. "WordNet: An Electronic Lexical Database". MIT Press, Cambridge, MA.


senseidx

package: wordnet-dict-sense-index

title: senseidx(5)

summary: WordNet's sense index

text:
# senseidx(5)

## NAME
index.sense, sense.idx - WordNet's sense index

## DESCRIPTION
The WordNet sense index provides an alternate method for accessing synsets and word senses in the WordNet database. It is useful to applications that retrieve synsets or other information related to a specific sense in WordNet, rather than all the senses of a word or collocation. It can also be used with tools like grep and Perl to find all senses of a word in one or more parts of speech. A specific WordNet sense, encoded as a sense_key, can be used as an index into this file to obtain its WordNet sense number, the database byte offset of the synset containing the sense, and the number of times it has been tagged in the semantic concordance texts.

Concatenating the lemma and lex_sense fields of a semantically tagged word (represented in a <wf ... > attribute/value pair) in a semantic concordance file, using % as the concatenation character, creates the sense_key for that sense, which can in turn be used to search the sense index file.

A sense_key is the best way to represent a sense in semantic tagging or other systems that refer to WordNet senses. sense_keys are independent of WordNet sense numbers and synset_offsets, which vary between versions of the database. Using the sense index and a sense_key, the corresponding synset (via the synset_offset) and WordNet sense number can easily be obtained. A mapping from noun sense_keys in WordNet 1.6 to corresponding 2.0 sense_keys is provided with version 2.0, and is described in sensemap(5).

See wndb(5) for a thorough discussion of the WordNet database files.

### File Format
The sense index file lists all of the senses in the WordNet database with each line representing one sense. The file is in alphabetical order, fields are separated by one space, and each line is terminated with a newline character.

Each line is of the form:

sense_key synset_offset sense_number tag_cnt

sense_key is an encoding of the word sense. Programs can construct a sense key in this format and use it as a binary search key into the sense index file. The format of a sense_key is described below.

synset_offset is the byte offset that the synset containing the sense is found at in the database "data" file corresponding to the part of speech encoded in the sense_key. synset_offset is an 8 digit, zero-filled decimal integer, and can be used with fseek(3) to read a synset from the data file. When passed to the WordNet library function read_synset() along with the syntactic category, a data structure containing the parsed synset is returned.

sense_number is a decimal integer indicating the sense number of the word, within the part of speech encoded in sense_key, in the WordNet database. See wndb(5) for information about how sense numbers are assigned.

tag_cnt represents the decimal number of times the sense is tagged in various semantic concordance texts. A tag_cnt of 0 indicates that the sense has not been semantically tagged.

### Sense Key Encoding
A sense_key is represented as:

lemma%lex_sense

where lex_sense is encoded as:

ss_type:lex_filenum:lex_id:head_word:head_id

lemma is the ASCII text of the word or collocation as found in the WordNet database index file corresponding to pos. lemma is in lower case, and collocations are formed by joining individual words with an underscore (_) character.

ss_type is a one digit decimal integer representing the synset type for the sense. See Synset Type below for a listing of the numbers corresponding to each synset type.

lex_filenum is a two digit decimal integer representing the name of the lexicographer file containing the synset for the sense. See lexnames(5) for the list of lexicographer file names and their corresponding numbers.

lex_id is a two digit decimal integer that, when appended onto lemma, uniquely identifies a sense within a lexicographer file. lex_id numbers usually start with 00, and are incremented as additional senses of the word are added to the same file, although there is no requirement that the numbers be consecutive or begin with 00. Note that a value of 00 is the default, and therefore is not present in lexicographer files. Only non-default lex_id values must be explicitly assigned in lexicographer files. See wninput(5) for information on the format of lexicographer files.

head_word is only present if the sense is in an adjective satellite synset. It is the lemma of the first word of the satellite's head synset.

head_id is a two digit decimal integer that, when appended onto head_word, uniquely identifies the sense of head_word within a lexicographer file, as described for lex_id. There is a value in this field only if head_word is present.

### Synset Type
The synset type is encoded as follows:

```
1	NOUN
2	VERB
3	ADJECTIVE
4	ADVERB
5	ADJECTIVE SATELLITE
```

## NOTES
For non-satellite senses the head_word and head_id fields have no values, however the field separator character (:) is present.

## ENVIRONMENT VARIABLES (UNIX)
WNHOME

Base directory for WordNet. Default is /usr/local/WordNet-3.0.

WNSEARCHDIR

Directory in which the WordNet database has been installed. Default is WNHOME/dict.

## REGISTRY (WINDOWS)
HKEY_LOCAL_MACHINE\SOFTWARE\WordNet\3.0\WNHome

Base directory for WordNet. Default is C:\Program Files\WordNet\3.0.

## FILES
index.sense

sense index

## SEE ALSO
binsrch(3), wnsearch(3), lexnames(5), wnintro(5), sensemap(5), wndb(5), wninput(5).


title: wpa_supplicant.conf(5)

summary: configuration file for wpa_supplicant

text:
# wpa_supplicant.conf(5)

## NAME
wpa_supplicant.conf - configuration file for wpa_supplicant

## OVERVIEW
wpa_supplicant is configured using a text file that lists all accepted networks and security policies, including pre-shared keys. See the example configuration file, probably in /usr/share/doc/wpa_supplicant/, for detailed information about the configuration format and supported fields.

All file paths in this configuration file should use full (absolute, not relative to working directory) path in order to allow working directory to be changed. This can happen if wpa_supplicant is run in the background.

Changes to configuration file can be reloaded be sending SIGHUP signal to wpa_supplicant ('killall -HUP wpa_supplicant'). Similarly, reloading can be triggered with the wpa_cli reconfigure command.

Configuration file can include one or more network blocks, e.g., one for each used SSID. wpa_supplicant will automatically select the best network based on the order of network blocks in the configuration file, network security level (WPA/WPA2 is preferred), and signal strength.

## QUICK EXAMPLES
1.

WPA-Personal (PSK) as home network and WPA-Enterprise with EAP-TLS as work network.

```
# allow frontend (e.g., wpa_cli) to be used by all users in 'wheel' group
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
#
# home network; allow all valid ciphers
network={
	ssid="home"
	scan_ssid=1
	key_mgmt=WPA-PSK
	psk="very secret passphrase"
}
#
# work network; use EAP-TLS with WPA; allow only CCMP and TKIP ciphers
network={
	ssid="work"
	scan_ssid=1
	key_mgmt=WPA-EAP
	pairwise=CCMP TKIP
	group=CCMP TKIP
	eap=TLS
	identity="user@example.com"
	ca_cert="/etc/cert/ca.pem"
	client_cert="/etc/cert/user.pem"
	private_key="/etc/cert/user.prv"
	private_key_passwd="password"
}
```

2.

WPA-RADIUS/EAP-PEAP/MSCHAPv2 with RADIUS servers that use old peaplabel (e.g., Funk Odyssey and SBR, Meetinghouse Aegis, Interlink RAD-Series)

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
	ssid="example"
	scan_ssid=1
	key_mgmt=WPA-EAP
	eap=PEAP
	identity="user@example.com"
	password="foobar"
	ca_cert="/etc/cert/ca.pem"
	phase1="peaplabel=0"
	phase2="auth=MSCHAPV2"
}
```

3.

EAP-TTLS/EAP-MD5-Challenge configuration with anonymous identity for the unencrypted use. Real identity is sent only within an encrypted TLS tunnel.

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
	ssid="example"
	scan_ssid=1
	key_mgmt=WPA-EAP
	eap=TTLS
	identity="user@example.com"
	anonymous_identity="anonymous@example.com"
	password="foobar"
	ca_cert="/etc/cert/ca.pem"
	phase2="auth=MD5"
}
```

4.

IEEE 802.1X (i.e., no WPA) with dynamic WEP keys (require both unicast and broadcast); use EAP-TLS for authentication

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
	ssid="1x-test"
	scan_ssid=1
	key_mgmt=IEEE8021X
	eap=TLS
	identity="user@example.com"
	ca_cert="/etc/cert/ca.pem"
	client_cert="/etc/cert/user.pem"
	private_key="/etc/cert/user.prv"
	private_key_passwd="password"
	eapol_flags=3
}
```

5.

Catch all example that allows more or less all configuration modes. The configuration options are used based on what security policy is used in the selected SSID. This is mostly for testing and is not recommended for normal use.

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
network={
	ssid="example"
	scan_ssid=1
	key_mgmt=WPA-EAP WPA-PSK IEEE8021X NONE
	pairwise=CCMP TKIP
	group=CCMP TKIP WEP104 WEP40
	psk="very secret passphrase"
	eap=TTLS PEAP TLS
	identity="user@example.com"
	password="foobar"
	ca_cert="/etc/cert/ca.pem"
	client_cert="/etc/cert/user.pem"
	private_key="/etc/cert/user.prv"
	private_key_passwd="password"
	phase1="peaplabel=0"
	ca_cert2="/etc/cert/ca2.pem"
	client_cert2="/etc/cer/user.pem"
	private_key2="/etc/cer/user.prv"
	private_key2_passwd="password"
}
```

6.

Authentication for wired Ethernet. This can be used with wired or roboswitch interface (-Dwired or -Droboswitch on command line).

```
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel
ap_scan=0
network={
	key_mgmt=IEEE8021X
	eap=MD5
	identity="user"
	password="password"
	eapol_flags=0
}
```

## CERTIFICATES
Some EAP authentication methods require use of certificates. EAP-TLS uses both server side and client certificates whereas EAP-PEAP and EAP-TTLS only require the server side certificate. When client certificate is used, a matching private key file has to also be included in configuration. If the private key uses a passphrase, this has to be configured in wpa_supplicant.conf ("private_key_passwd").

wpa_supplicant supports X.509 certificates in PEM and DER formats. User certificate and private key can be included in the same file.

If the user certificate and private key is received in PKCS#12/PFX format, they need to be converted to suitable PEM/DER format for wpa_supplicant. This can be done, e.g., with following commands:

```
# convert client certificate and private key to PEM format
openssl pkcs12 -in example.pfx -out user.pem -clcerts
# convert CA certificate (if included in PFX file) to PEM format
openssl pkcs12 -in example.pfx -out ca.pem -cacerts -nokeys
```

## SEE ALSO
wpa_supplicant(8) openssl(1)


wvdial.conf

package: wvdial

title: wvdial.conf(5)

summary: wvdial configuration file

text:
# wvdial.conf(5)

## NAME
wvdial.conf - wvdial configuration file

## DESCRIPTION
When wvdial starts, it first loads its configuration from /etc/wvdial.conf, which contains basic information about the modem port, speed, and init string, along with information about your Internet Service Provider (ISP), such as the phone number, your username, and your password.

The configuration file /etc/wvdial.conf is in Windows "ini" file format, with sections named in square brackets and a number of variable = value pairs within each section.

Here is a sample configuration file:

[Dialer Defaults]

Modem = /dev/ttyS2

Baud = 57600

Init = ATZ

Init2 = AT S11=50

Phone = 555-4242

Username = apenwarr

Password = my-password [Dialer phone2]

Phone = 555-4243

[Dialer shh]

Init3 = ATM0

[Dialer pulse]

Dial Command = ATDP

The sample configuration file above contains all of the options necessary to run the two sample command lines given above. Here is a complete list of settings that wvdial understands:

Modem

The location of the device that wvdial should use as your modem. The default is /dev/modem.

Baud

The speed at which wvdial will communicate with your modem. The default is 57600 baud.

Init1 ... Init9

wvdial can use up to nine initialization strings to set up your modem. Before dialing, these strings are sent to the modem in numerical order. These are particularly useful when specifying multiple sections. See above for an example that uses Init3 to turn the modem's speaker off. The default is "ATZ" for Init1.

Phone

The phone number you want wvdial to dial. You can add up to 4 other phone numbers that wvdial will dial in order, by adding:

Phone1

Phone2

Phone3

Phone4

Dial Prefix

wvdial will insert this string after the dial command and before the phone number. For example, to disable call waiting (in North America, anyway) set this to "*70,".

Dial Command

wvdial will use this string to tell the modem to dial. The default is "ATDP".

Login

You must set this to the username you use at your ISP.

Login Prompt

If your ISP has an unusual login procedure that wvdial is unable to figure out, you can use this option to specify a login prompt. When this prompt is received from your ISP, wvdial will send the Login string.

Password

You must set this to the password you use at your ISP.

Ask Password

By setting this option wvdial will prompt for your password on every dialin. Thus you don't have to save your password in /etc/wvdial.conf. (Option added by SuSE.)

Password Prompt

If your ISP has an unusual login procedure that wvdial is unable to figure out, you can use this option to specify a password prompt. When this prompt is received from you ISP, wvdial will send the Password string.

PPPD Path

If your system has pppd somewhere other than /usr/sbin/pppd, you will need to set this option.

Auto DNS

Try to get the Domain Nameserver (DNS) from the provider. This option is "on" by default. (Option added by SuSE.)

Check DNS

Check the Domain Nameserver (DNS) after the connection has been set up. This option is "on" by default. (Option added by SuSE.)

DNS Test1

First DNS lookup for DNS check. (Option added by SuSE.)

DNS Test2

Second DNS lookup for DNS check. (Option added by SuSE.)

Check Def Route

Check the default route after the connection has been set up. This option is "on" by default. (Option added by SuSE.)

Force Address

This option only applies if you have a static IP address at your ISP, and even then you probably don't need it. Some ISP's don't send the IP address as part of the PPP negotiation. This option forces pppd to use the address you give it.

Remote Name

If your ISP uses PAP or CHAP authentication, you might need to change this to your ISP's authentication name. In most cases, however, it's safe to use the default value, "*".

Carrier Check

wvdial checks your modem during the connection process to ensure that it is actually online. If you have a weird modem that insists its carrier line is always down, you can disable the carrier check by setting this option to "no".

Stupid Mode

When wvdial is in Stupid Mode, it does not attempt to interpret any prompts from the terminal server. It starts pppd immediately after the modem connects. Apparently there are ISP's that actually give you a login prompt, but work only if you start PPP, rather than logging in. Go figure. Stupid Mode is (naturally) disabled by default.

New PPPD

You need this option if you have pppd version 2.3.0 or newer, to make wvdial create the file /etc/ppp/peers/wvdial. This option is enabled by default, thus if you have older pppd you need to set it to `no' (or upgrade pppd).

Default Reply

When wvdial detects a prompt, and it hasn't seen any clues that indicate what it should send as a response to the prompt, it defaults to sending "ppp". Sometimes this is inadequate. Use this option to override wvdial's default prompt response.

Auto Reconnect

If enabled, wvdial will attempt to automatically reestablish a connection if you are randomly disconnected by the other side. This option is "on" by default.

Idle Seconds

Set the hangup timeout in seconds. If there is inactivity for the given time the connection is shut down. A hangup timeout of 0 disables this feature.

Abort on Busy

If enabled, wvdial will not retry the connection if the modem says that the line is busy. This option is "off" by default.

Abort on No Dialtone

If enabled, wvdial will not retry the connection if the modem says that there is no dialtone. This option is "on" by default.

Dial Attempts

If value is set, wvdial will quit after that many tries .If set to 0, wvdial will happily keep dialling forever.

Dial Timeout

The maximum time in seconds that wvdial will wait for a connection to be made. Default value is 60 seconds.

The wvdialconf(1) program can be used to detect your modem and fill in the Modem, Baud, and Init/Init2 options automatically.

## AUTHORS
Dave Coombs and Avery Pennarun for Net Integration Technologies Inc. Great contributions have been made by many people, including SuSE and RedHat. Thanks guys!

## SEE ALSO
wvdial(1), wvdialconf(1), pppd(8).


title: x2goserver.conf(5)

summary: X2Go Server Main Configuration File

text:
# x2goserver.conf(5)

## NAME
x2goserver.conf - X2Go Server Main Configuration File

## SYNOPSIS

x2goserver.conf

## DESCRIPTION
x2goserver.conf is the main configuration file for X2Go Server and the X2Go::Server Perl API.

## SECTIONS
The x2goserver.conf's configuration file format is an INI-based configuration format. It falls apart into sections and options with their values.

[section1]

sec1option1 = valueA

sec1option2 = valueB

...

[section2]

sec2option1 = valueC

sec2option2 = valueD

...

## SECTION [limit users]
In this section you can list up Posix users known to the system and specify the max. number of allowed simultaneous X2Go sessions in an X2Go Server farm.

## SECTION [limit groups]
In this section you can list up Posix group names known to the system and specify the max. number of allowed simultaneous X2Go sessions in an X2Go Server farm. The session limitation applies to all users in the specified groups.

If individual users are listed in section [limit users] and some of their groups are listed in section [limit groups], then the maximum value of allowed sessions will be chosen.

If a user is a member of several of the specified groups under section [limit groups], then the number of allowed simultaneous X2Go sessions for a certain user will be derived from the group with the most allowed sessions found under this section.

## SECTION [log]
The [log]'s section only option is the loglevel option. Allowed values are:

emerg, alert, crit, err, warning, notice, info, debug.

The loglevel option controls the verbosity of the X2Go::Server Perl functions. The log output appears via LOCAL7 (normally: /var/log/syslog).

## EXAMPLE
The below configuration file is the default after installation of X2Go Server:

[limit users]

\#user-foo=1

[limit groups]

\#bar-group=1

[log]

\# possible levels are:

\# emerg, alert, crit, err, warning, notice, info, debug

loglevel=notice

## AUTHOR
This manual has been written by Mike Gabriel <mike.gabriel@das-netzwerkteam.de> for the X2Go project (https://www.x2go.org).


portals.conf

package: xdg-desktop-portal

title: portals.conf(5)

summary: XDG desktop portal configuration

text:
# portals.conf(5)

## NAME
portals.conf - XDG desktop portal configuration

## SYNOPSIS
$XDG_CONFIG_HOME/xdg-desktop-portal/{*-}portals.conf

$XDG_CONFIG_DIRS/xdg-desktop-portal/{*-}portals.conf

/etc/xdg-desktop-portal/{*-}portals.conf

$XDG_DATA_HOME/xdg-desktop-portal/{*-}portals.conf

$XDG_DATA_DIRS/xdg-desktop-portal/{*-}portals.conf

/usr/share/xdg-desktop-portal/{*-}portals.conf

## DESCRIPTION
xdg-desktop-portal uses a configuration file to determine which portal backend should be used to provide the implementation for the requested interface. This mechanism is very similar to the freedesktop.org specification for "Association between MIME types and applications" (mime-apps).

Desktop environments and OS vendors should provide a default configuration for their chosen portal backends in /usr/share/xdg-desktop-portal/DESKTOP-portals.conf, where DESKTOP is the desktop environment name as it would appear in the XDG_CURRENT_DESKTOP environment variable, after case-folding ASCII upper case to lower case. For example, KDE should provide /usr/share/xdg-desktop-portal/kde-portals.conf.

Users can override those defaults, or provide configuration for an otherwise unsupported desktop environment, by writing a file ~/.config/xdg-desktop-portal/portals.conf. Users of more than one desktop environment can use desktop-specific filenames such as kde-portals.conf which will only be used in the appropriate desktop environment.

Similarly, system administrators can provide a default configuration for all users in /etc/xdg-desktop-portal/DESKTOP-portals.conf or /etc/xdg-desktop-portal/portals.conf.

The following locations are searched for configuration, highest precedence first:

- $XDG_CONFIG_HOME, defaulting to ~/.config

- each directory in $XDG_CONFIG_DIRS, defaulting to /etc/xdg

- the build-time sysconfdir for xdg-desktop-portal, usually /etc

- $XDG_DATA_HOME, defaulting to ~/.local/share (searched only for consistency with other specifications, writing configuration here is not recommended)

- each directory in $XDG_DATA_DIRS, defaulting to /usr/local/share:/usr/share

- the build-time datadir for xdg-desktop-portal, usually /usr/share

In each of those locations, for each desktop environment name listed in the XDG_CURRENT_DESKTOP environment variable, xdg-desktop-portal checks for xdg-desktop-portal/DESKTOP-portals.conf, where DESKTOP is the desktop environment name in lower-case. If a desktop-environment-specific configuration file is not found, a non-desktop-specific file xdg-desktop-portal/portals.conf will be read. For example, if XDG_CURRENT_DESKTOP is set to Budgie:GNOME, then xdg-desktop-portal will look for xdg-desktop-portal/budgie-portals.conf, xdg-desktop-portal/gnome-portals.conf and xdg-desktop-portal/portals.conf in that order.

Only the first configuration file found is read, and lower-precedence configuration files are ignored. All possible configuration files within one directory are tried before moving on to the next directory, so for example ~/.config/xdg-desktop-portal/portals.conf is higher-precedence than /usr/share/xdg-desktop-portal/kde-portals.conf.

### FILE FORMAT
The format of the portals configuration file is the same .ini format used by systemd unit files or application desktop files.

[preferred]

The main configuration group for preferred portals.

The following keys can be present in the preferred group:

default (string)

The default portal backend to use for every interface, unless the interface is listed explicitly.

org.freedesktop.impl.portal.* (string)

One of the valid portal interface implementations exposed by xdg-desktop-portal.

Each key in the group contains a semi-colon separated list of portal backend implementation, to be searched for an implementation of the requested interface, in the same order as specified in the configuration file. Additionally, the special values none and * can be used:

none

Do not provide a portal implementation for this interface.

*

Use the first portal implementation found, in lexicographical order.

### EXAMPLE

```
[preferred]
# Use xdg-desktop-portal-gtk for every portal interface...
default=gtk
# ... except for the Screencast interface
org.freedesktop.impl.portal.Screencast=gnome
```

### ENVIRONMENT
XDG_CURRENT_DESKTOP

A colon-separated list of desktop environments, most specific first, used to choose a desktop-specific portal configuration. The default is an empty list.

XDG_CONFIG_HOME

The per-user portals.conf file is located in this directory. The default is $HOME/.config.

XDG_CONFIG_DIRS

A colon-separated list of system configuration directories and secondary per-user configuration directories. The default is /etc/xdg.

XDG_DATA_HOME

A per-user data directory, searched for consistency with other specifications. The default is $HOME/.local/share.

XDG_DATA_DIRS

A colon-separated list of system data directories and secondary per-user data directories. The default is /usr/local/share:/usr/share.

### SEE ALSO

- XDG Base Directory Specification

- XDG Desktop Entry specification

- XDG Association between MIME type and applications specification


user-dirs.conf

package: xdg-user-dirs

title: user-dirs.conf(5)

summary: configuration for xdg\-user\-dirs\-update

text:
# user-dirs.conf(5)

## NAME
user-dirs.conf - configuration for xdg-user-dirs-update

## DESCRIPTION
The /etc/xdg/user-dirs.conf file is a text file that controls the behavior of the xdg-user-dirs-update command. Users can have their own ~/.config/user-dirs.conf file, which overrides the system-wide configuration.

The following keys are recognised:

enabled=boolean

When set to False, xdg-user-dirs-update will not change the XDG user dirs configuration.

filename_encoding=encoding

This sets the filename encoding to use. encoding can be an explicit encoding name, such as UTF-8, or "locale", which means the encoding of the users locale will be used.

Lines beginning with a # character are ignored.

## ENVIRONMENT
XDG_CONFIG_DIRS

The system-wide user-dirs.conf file is located in this directory. The default is /etc/xdg.

XDG_CONFIG_HOME

The per-user user-dirs.conf file is located in this directory. The default is $HOME/.config.

## SEE ALSO
xdg-user-dirs-update(1)


user-dirs.defaults

title: user-dirs.defaults(5)

summary: default settings for XDG user dirs

text:
# user-dirs.defaults(5)

## NAME
user-dirs.defaults - default settings for XDG user dirs

## DESCRIPTION
The /etc/xdg/user-dirs.defaults file is a text file that contains the default values for the XDG user dirs which are used by the xdg-user-dirs-update command.

This file contains lines of the form

```
NAME=VALUE
```

The following names are recognised:

DESKTOP

DOWNLOAD

TEMPLATES

PUBLICSHARE

DOCUMENTS

MUSIC

PICTURES

VIDEOS

The values are relative pathnames from the home directory and will be translated on a per-path-element basis into the users locale.

Lines beginning with a # character are ignored.

## ENVIRONMENT
XDG_CONFIG_DIRS

The user-dirs.defaults file is located in this directory. The default is /etc/xdg.

## SEE ALSO
xdg-user-dirs-update(1)


user-dirs.dirs

title: user-dirs.dirs(5)

summary: settings for XDG user dirs

text:
# user-dirs.dirs(5)

## NAME
user-dirs.dirs - settings for XDG user dirs

## DESCRIPTION
The $HOME/.config/user-dirs.dirs file is a text file that contains the user-specific values for the XDG user dirs. It is created and updated by the xdg-user-dirs-update command.

This file contains lines of the form

```
XDG_NAME_DIR=VALUE
```

The following names are recognised:

DESKTOP

DOWNLOAD

TEMPLATES

PUBLICSHARE

DOCUMENTS

MUSIC

PICTURES

VIDEOS

VALUE must be of the form "$HOME/Path" or "/Path".

Lines beginning with a # character are ignored.

The format of user-dirs.dirs is designed to allow direct sourcing of this file in shell scripts.

## ENVIRONMENT
XDG_CONFIG_DIRS

The user-dirs.defaults file is located in this directory. The default is /etc/xdg.

## SEE ALSO
xdg-user-dirs-update(1)


xl-disk-configuration

package: xen

title: xl-disk-configuration(5)

summary: XL Disk Configuration Syntax

text:
# xl-disk-configuration(5)

## NAME
xl-disk-configuration - XL Disk Configuration Syntax

## SYNTAX
This document specifies the xl config file format disk configuration option. It has the following form:

```
   disk = [ 'DISKSPEC', 'DISKSPEC', ... ]
```

where each "DISKSPEC" is in this form:

```
   [<key>=<value>|<flag>,]*,
     [<target>, [<format>, [<vdev>, [<access>]]]],
     [<key>=<value>|<flag>,]*
     [target=<target>]
```

For example, these strings are equivalent:

```
    /dev/vg/guest-volume,,hda
    /dev/vg/guest-volume,raw,hda,rw
    format=raw, vdev=hda, access=rw, target=/dev/vg/guest-volume
    raw:/dev/vg/guest-volume,hda,w  (deprecated, see below)
```

As are these:

```
    /root/image.iso,,hdc,cdrom
    /root/image.iso,,hdc,,cdrom
    /root/image.iso,raw,hdc,devtype=cdrom
    format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/root/image.iso
    raw:/root/image.iso,hdc:cdrom,ro   (deprecated, see below)
```

These might be specified in the domain config file like this:

```
    disk = [ '/dev/vg/guest-volume,,hda', '/root/image.iso,,hdc,cdrom' ]
```

More formally, the string is a series of comma-separated keyword/value pairs, flags and positional parameters. Parameters which are not bare keywords and which do not contain "=" symbols are assigned to the so-far-unspecified positional parameters, in the order below. The positional parameters may also be specified explicitly by name.

Each parameter may be specified at most once, either as a positional parameter or a named parameter. Default values apply if the parameter is not specified, or if it is specified with an empty value (whether positionally or explicitly).

Whitespace may appear before each parameter and will be ignored.

## Positional Parameters
target

Description

Block device or image file path. When this is used as a path, /dev will be prepended if the path doesn't start with a '/'.

Supported values

N/A

Deprecated values

N/A

Default value

None. While a path is provided in most cases there is an exception: for a cdrom device, lack of this attribute would imply an empty cdrom drive.

Special syntax

When this parameter is specified by name, ie with the "target=" syntax in the configuration file, it consumes the whole rest of the "DISKSPEC" including trailing whitespaces. Therefore in that case it must come last. This is permissible even if an empty value for the target was already specified as a positional parameter. This is the only way to specify a target string containing metacharacters such as commas and (in some cases) colons, which would otherwise be misinterpreted. Future parameter and flag names will start with an ascii letter and contain only ascii alphanumerics, hyphens and underscores, and will not be legal as vdevs. Targets which might match that syntax should not be specified as positional parameters.

format

Description

Specifies the format of image file.

Supported values

raw, qcow, qcow2, vhd, qed

Deprecated values

None

Default value

raw

vdev

Description

Virtual device as seen by the guest (also referred to as guest drive designation in some specifications). See xen-vbd-interface(7).

Supported values

hd[x], xvd[x], sd[x] etc. Please refer to the above specification for further details.

Deprecated values

None

Default Value

None, this parameter is mandatory.

access

Description

Specified access control information. Whether or not the block device is provided to the guest in read-only or read-write mode depends on this attribute.

Supported values

"ro", "r" (specifies read-only) "rw", "w" (specifies read/write)

Deprecated values

None

Default value

"rw" unless devtype=cdrom, in which case "r"

## Other Parameters And Flags
devtype=DEVTYPE

Description

Qualifies virtual device type.

Supported values

cdrom

Deprecated values

None

Mandatory

No

cdrom

Convenience alias for "devtype=cdrom".

backend=DOMAIN-NAME

Description

Designates a backend domain for the device

Supported values

Valid domain names

Mandatory

No

Specifies the backend domain which this device should attach to. This defaults to domain 0. Specifying another domain requires setting up a driver domain which is outside the scope of this document.

backendtype=TYPE

Description

Specifies the backend implementation to use

Supported values

phy, qdisk

Mandatory

No

Default value

Automatically determine which backend to use.

This does not affect the guest's view of the device. It controls which software implementation of the Xen backend driver is used.

Not all backend drivers support all combinations of other options. For example, "phy" does not support formats other than "raw". Normally this option should not be specified, in which case libxl will automatically determine the most suitable backend.

script=SCRIPT

Specifies that target is not a normal host path, but rather information to be interpreted by the executable program SCRIPT, (looked for in /etc/xen/scripts, if it doesn't contain a slash). These scripts are normally called "block-SCRIPT".

direct-io-safe

Description

Disables non-O_DIRECT workaround

Supported values

absent, present

Mandatory

No

Default value

absent (workaround may be enabled)

There is a memory lifetime bug in some driver domain (dom0) kernels which can cause crashes when using O_DIRECT. The bug occurs due to a mismatch between the backend-visible lifetime of pages used for the Xen PV network protocol and that expected by the backend kernel's networking subsystem. This can cause crashes when using certain backends with certain underlying storage.

See:

<https://lists.xenproject.org/archives/html/xen-devel/2012-12/msg01154.html>

For this reason, (this version of) the Xen libxl toolstack disables O_DIRECT when using the qemu-based Xen PV backend ("qdisk").

However, this workaround has performance and scaling implications, and it is only necessary if the underlying device is a network filesystem. If the underlying device is not, then it is good to disable it; that is what this option is for.

This option simply requests that the workaround be disabled. (However, not all backends versions which use the workaround understand this option, so this is on a best effort basis.)

It's important to note that if you are storing the VM disk on a network filesystem or a network block device (NFS or ISCSI) it might not be safe to use this option. Otherwise specifying it is safe and can give better performances.

If in the future the bug is fixed properly this option will then be silently ignored.

discard / no-discard

Description

Request that backend advertise discard support to frontend

Supported values

discard, no-discard

Mandatory

No

Default value

discard

An advisory setting for the backend driver, specifying whether to advertise discard support (TRIM, UNMAP) to the frontend. The real benefit of this option is to be able to force it off rather than on. It can be used to disable "hole punching" for file based backends which were intentionally created non-sparse to avoid fragmentation of the file.

## COLO Parameters
colo

Enable COLO HA for disk. For better understanding block replication on QEMU, please refer to: <https://wiki.qemu.org/Features/BlockReplication> Note that the COLO configuration settings should be considered unstable. They may change incompatibly in future versions of Xen.

colo-host

Description

Secondary host's address

Mandatory

Yes when COLO enabled

colo-port

Description

Secondary port. We will run a nbd server on secondary host, and the nbd server will listen this port.

Mandatory

Yes when COLO enabled

colo-export

Description

We will run a nbd server on secondary host, exportname is the nbd server's disk export name.

Mandatory

Yes when COLO enabled

active-disk

Description

This is used by secondary. Secondary guest's write will be buffered in this disk.

Mandatory

Yes when COLO enabled

hidden-disk

Description

This is used by secondary. It buffers the original content that is modified by the primary VM.

Mandatory

Yes when COLO enabled

## Deprecated Parameters, Prefixes And Syntaxes
Deprecated forms are acceptable and are intended work compatibly with xend and xl from xen 4.1. In future they may print a warning. Support for deprecated parameters and syntaxes are likely to be dropped in future versions of xl.

There is support for a deprecated old syntax for "DISKSPEC":

```
  [<format>:][<target>],<vdev>[:<devtype>],<access>   (deprecated)
```

This syntax also supports deprecated prefixes, described below. These are found prepended to the format parameter - eg "tap:aio:qcow:".

format

Description

Specifies the format (deprecated)

Supported values

raw: qcow2: vhd:

In xend and old versions of libxl it was necessary to specify the format with a prefix. For compatibility, these three prefixes are recognised as specifying the corresponding format. They are equivalent to "format=FORMAT" or the specification of format (without a colon) as a positional parameter.

script

Description

Specifies the script (deprecated)

Supported values

iscsi: nbd: enbd: drbd:

In xend and old versions of libxl it was necessary to specify the "script" (see above) with a prefix. For compatibility, these four prefixes are recognised as specifying the corresponding script. They are equivalent to "script=block-SCRIPT".

deprecated-prefix

Description

Deprecated prefix, ignored

Supported values

tapdisk: tap2: aio: ioemu: file: phy:

Various prefixes were required by xend and older versions of libxl to make the block devices work. In some cases these options would override the backend type, but in other cases they would be ignored in favour of "making it work"; in yet other cases it would be necessary to specify several of these, for example:

```
  tap:aio:/some/path...
```

All of these prefixes are now stripped and ignored.

### Missing format and empty target
The following syntax is also supported:

```
  ,<vdev>:<devtype>,<access>   (deprecated)
```

This is solely for compatibility with xend's syntax for empty cdroms, which is (for example) ",hdc:cdrom,r".


xl-network-configuration

title: xl-network-configuration(5)

summary: XL Network Configuration Syntax

text:
# xl-network-configuration(5)

## NAME
xl-network-configuration - XL Network Configuration Syntax

## SYNTAX
This document specifies the xl config file format vif configuration option. It has the following form:

```
        vif = [ '<vifspec>', '<vifspec>', ... ]
```

where each vifspec is in this form:

```
        [<key>=<value>|<flag>,]
```

For example:

```
        'mac=00:16:3E:74:3d:76,model=rtl8139,bridge=xenbr0'
        'mac=00:16:3E:74:34:32'
        '' # The empty string
```

These might be specified in the domain config file like this:

```
        vif = [ 'mac=00:16:3E:74:34:32', 'mac=00:16:3e:5f:48:e4,bridge=xenbr1' ]
```

More formally, the string is a series of comma-separated keyword/value pairs. All keywords are optional.

Each device has a "DEVID" which is its index within the vif list, starting from 0.

## Keywords

### mac
If specified then this option specifies the MAC address inside the guest of this VIF device. The value is a 48-bit number represented as six groups of two hexadecimal digits, separated by colons (:).

The default if this keyword is not specified is to be automatically generate a MAC address inside the space assigned to Xen's Organizationally Unique Identifier <https://en.wikipedia.org/wiki/Organizationally_Unique_Identifier> (00:16:3e).

If you are choosing a MAC address then it is strongly recommend to follow one of the following strategies:

- Generate a random sequence of 6 byte, set the locally administered bit (bit 2 of the first byte) and clear the multicast bit (bit 1 of the first byte). In other words the first byte should have the bit pattern xxxxxx10 (where x is a randomly generated bit) and the remaining 5 bytes are randomly generated See [https://en.wikipedia.org/wiki/MAC_address] for more details the structure of a MAC address.

- Allocate an address from within the space defined by your organization's OUI (if you have one) following your organization's procedures for doing so.

- Allocate an address from within the space defined by Xen's OUI (00:16:3e). Taking care not to clash with other users of the physical network segment where this VIF will reside.

If you have an OUI for your own use then that is the preferred strategy. Otherwise in general you should prefer to generate a random MAC and set the locally administered bit since this allows for more bits of randomness than using the Xen OUI.

### bridge
Specifies the name of the network bridge which this VIF should be added to. The default is "xenbr0". The bridge must be configured using your distribution's network configuration tools. See the wiki <https://wiki.xenproject.org/wiki/Network_Configuration_Examples_(Xen_4.1%2B)> for guidance and examples.

### gatewaydev
Specifies the name of the network interface which has an IP and which is in the network the VIF should communicate with. This is used in the host by the vif-route hotplug script. See wiki <https://wiki.xenproject.org/wiki/Vif-route> for guidance and examples.

NOTE: netdev is a deprecated alias of this option.

### type
This keyword is valid for HVM guests only.

Specifies the type of device to valid values are:

- "ioemu" (default) -- this device will be provided as an emulate device to the guest and also as a paravirtualised device which the guest may choose to use instead if it has suitable drivers available.

- "vif" -- this device will be provided as a paravirtualised device only.

### model
This keyword is valid for HVM guest devices with "type=ioemu" only.

Specifies the type device to emulated for this guest. Valid values are:

- "rtl8139" (default) -- Realtek RTL8139

- "e1000" -- Intel E1000

- in principle any device supported by your device model

### vifname
Specifies the backend device name for the virtual device.

If the domain is an HVM domain then the associated emulated (tap) device will have a "-emu" suffice added.

The default name for the virtual device is "vifDOMID.DEVID" where "DOMID" is the guest domain ID and "DEVID" is the device number. Likewise the default tap name is "vifDOMID.DEVID-emu".

### script
Specifies the hotplug script to run to configure this device (e.g. to add it to the relevant bridge). Defaults to "XEN_SCRIPT_DIR/vif-bridge" but can be set to any script. Some example scripts are installed in "XEN_SCRIPT_DIR".

### ip
Specifies the IP address for the device, the default is not to specify an IP address.

What, if any, effect this has depends on the hotplug script which is configured. A typically behaviour (exhibited by the example hotplug scripts) if set might be to configure firewall rules to allow only the specified IP address to be used by the guest (blocking all others).

### backend
Specifies the backend domain which this device should attach to. This defaults to domain 0. Specifying another domain requires setting up a driver domain which is outside the scope of this document.

### rate
Specifies the rate at which the outgoing traffic will be limited to. The default if this keyword is not specified is unlimited.

The rate may be specified as "/s" or optionally "/s@".

•

"RATE" is in bytes and can accept suffixes:

- GB, MB, KB, B for bytes.

- Gb, Mb, Kb, b for bits.

•

"INTERVAL" is in microseconds and can accept suffixes: ms, us, s. It determines the frequency at which the vif transmission credit is replenished. The default is 50ms.

Vif rate limiting is credit-based. It means that for "1MB/s@20ms", the available credit will be equivalent of the traffic you would have done at "1MB/s" during 20ms. This will results in a credit of 20,000 bytes replenished every 20,000 us.

For example:

```
        'rate=10Mb/s' -- meaning up to 10 megabits every second
        'rate=250KB/s' -- meaning up to 250 kilobytes every second
        'rate=1MB/s@20ms' -- meaning 20,000 bytes in every 20 millisecond period
```

NOTE: The actual underlying limits of rate limiting are dependent on the underlying netback implementation.

### devid
Specifies the devid manually instead of letting xl choose the lowest index available.

NOTE: This should not be set unless you have a reason to.