whois.conf

package: whois

title: whois.conf(5)

text:
# whois.conf(5)

## NAME
whois.conf - alternative WHOIS servers list for whois client

## SYNOPSIS
/etc/whois.conf

## DESCRIPTION
This file contains a list of WHOIS servers which can augment or override the built-in list of the client.

It's a plain text file in ASCII encoding. Each line consists of two fields: a pattern to match WHOIS object identifier and a corresponding WHOIS server domain name.

Fields are separated by non-empty sequence of space or a tabular characters. A line starting with a hash character is a free comment and it's not considered.

The pattern is case-insensitive extended regular expression if whois client has been compiled with POSIX regular expressions support. Otherwise, simple case-insensitive suffix comparison against WHOIS object identifier is used.

Internationalized domain names (IDN) must be specified in ascii-compatible encoding (ACE) format.

## EXAMPLE
\.nz$ nz.whois-servers.net

\# Hangul Korean TLD

\.xn--3e0b707e$ whois.kr

\# Private ASNs

^as645(1[2-9]|2[0-9]|3[0-4])$ whois.example.net

## FILES
/etc/whois.conf

## SEE ALSO
whois(1)

## AUTHOR
This manual page was written by Petr Písař <ppisar@redhat.com> and is licensed under the terms of the GNU General Public License, version 2 or higher.


wildmidi.cfg

package: wildmidi

title: wildmidi.cfg(5)

summary: Config file for libWildMidi

text:
# wildmidi.cfg(5)

## NAME
wildmidi.cfg - Config file for libWildMidi

## LIBRARY
libWildMidi

## DESCRIPTION
Contains the patch configuration for libWildMidi and location of Gravis Ultrasound compatible patch files.

```
dir ~/guspats/
source /etc/wildmidi.cfg
bank 0
0 acpiano.pat amp=110 env_time4=300
1 brpiano.pat amp=100
drumset 0
25 snarerol keep=env amp=225 note=60
26 snap	note=65
```

## SYNTAX
guspat_editor_author_cant_read_so_fix_release_time_for_me

Some patch file editors switch the 4th and 5th envelopes around making the sound play much longer than intended in players that stuck to the Gravis Ultrasound patch standard. Including this option in the config enables a fix that detects this oversight, playing the sound samples as if they were correct.

NOTE: This is a global setting. If it is found to affect good patch samples it will be moved to a per patch setting in a future version.

auto_amp

Forces WildMIDI to amplify samples to their maximum level ignoring the amp=% in the patch lines of the config.

auto_amp_with_amp

Forces WildMIDI to amplify samples to their maximum level then apply the amp=% in the patch lines of the config.

dir dir-name

Change the search path for config and patch files to dir-name. This is specific to the current config file and carried to any included config file unless they have their own dir setting. Any included file that has its own dir setting does not effect the dir setting of the current config file.

source include-confg

Include the settings from include-config. Any patch already set will be over-ridden by the included config file.

bank N

The patches following this setting belong to MIDI instrument bank N.

drumset N

The patches following this setting belong to MIDI drum bank N.

patchno patchfile [amp=volume] [note=miodinte] [keep=loop] [keep=env] [remove=sustain] [remove=clamped] [env_level[0-5]=level] [env_time[0-5]=time]

Example: 0 acpiano.pat amp=110

patchno

This is the MIDI patch number the instrument belongs to.

patchfile

The filename of the Gravis Ultrasound compatible patch file. If the filename is missing the .pat extension, libWildMidi will add .pat when attempting to load the file.

amp=volume

Force the volume of the samples in this patch to volume% prior to using it.

note=midinote

Use note midinote when playing the samples in this patch. NOTE: this is for instruments listed under drumset.

keep=loop

Play the samples in this patch with the loop, when normally we would not for this instrument.

keep=env

Use the envelope data in this patch, when normally we wouldn't for this instrument.

remove=sustain

Do note hold the note after the 3rd envelope until note off, which is what happens if the sustain bit is set in the patch file.

remove=clamped

Do not jump to 6th envelope on note off, which is what happens if the clamped bit is set in the patch file.

env_level[0-5]=level

Set the envelope level to level with 1.0 being maximum, and 0.0 being minimum.

Example: set 5th envelope level to 10% - env_level[0-5]=0.1

env_time[0-5]=time

Set the envelope time to time with a resolution of 1/1000th of a second. This setting is the time it should take for the envelope to reach maximum level.

Example: set 1st envelope time to 1sec - env_time0=1000

Example: set 3rd envelope time to 0.5secs - env_time2=500

reverb_room_width fval

Set the room width for the reverb engine in meters. fval is a float value in meters. Minimum setting is 1.0 meter, maximum setting is 100.0 meters, and default is 15.0 meters.

Example: set room width to 30 meters - reverb_room_width 30

reverb_room_length fval

Set the room length for the reverb engine in meters. fval is a float value in meters. Minimum setting is 1.0 meter, maximum setting is 100.0 meters, and default is 20.0 meters.

Example: set room length to 40 meters - reverb_room_length 40

## SEE ALSO
wildmidi(1)

## AUTHOR
Chris Ison <wildcode@users.sf.net> Bret Curtis <psi29a@gmail.com>

## COPYRIGHT
Copyright (C) Chris Ison 2001-2010 Copyright (C) Bret Curtis 2013-2016

This file is part of WildMIDI.

WildMIDI is free software: you can redistribute and/or modify the player under the terms of the GNU General Public License and you can redistribute and/or modify the library under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the licenses, or(at your option) any later version.

WildMIDI is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License and the GNU Lesser General Public License for more details.

You should have received a copy of the GNU General Public License and the GNU Lesser General Public License along with WildMIDI. If not, see <http://www.gnu.org/licenses/>.

This manpage is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.

branch: sisyphus


wlogout

package: wlogout

title: wlogout(5)

text:
# wlogout(5)

## NAME
wlogout - layout file and options

## LAYOUT
wlogout's buttons can consist of up to six values

•label

•action

•text

•keybind

•height *

•width *

•circular *

* Optional values

Label is the css selector by which the buttons may be referred to in a style.css file, action is the shell command to be executed when the button is clicked, text is the description displayed on the button, keybind is the key mapped to the button (note escape is reserved for exiting the application), height and width are values between 0.0 and 1.0 that control the location of where text is displayed the default width 0.5, height 0.9, and circular is a boolean value that makes a button round.

## FILE
The buttons values are specified in a JSON formatted file, wherein the values are used as keys and one button corresponds to one JSON object for example:

```
{

    "label" : "foo",

    "action" : "echo 'hello world'",

    "text" : "bar",

    "keybind" : "f",

    "height" : 1,

    "width" : 1,

    "circular" : true
}
```

Would create a round button that has a css label of foo, prints "hello world" upon being clicked, displays "bar" on the button, be bound to the key 'f', and "bar" would be shown at the bottom right corner. To create multiple buttons simply create another JSON object.

## AUTHORS
Maintained by Haden Collins <collinshaden@gmail.com> for more information about wlogout, see <https://github.com/ArtsyMacaw/wlogout>.

## SEE ALSO
wlogout(1)


wmapplrc

package: wmappl

title: wmapplrc(5)

summary: configuration file for wmappl

text:
# wmapplrc(5)

## NAME
wmapplrc - configuration file for wmappl

## DESCRIPTION
The format of a wmappl configuration file consists of a number of sections, defined by a section name surrounded in square brakets, for example: "[section]". Each button that should appear in wmappl should have its own section. The lines following the section name specify the icon to use, the command to launch when the button is pressed and an optional tooltip string to be displayed.

An optional [wmappl] section may be specified which specifies configuration options for wmappl. These options have the same names as the long command line options and are entirely optional. Command line arguments will override any specified in the configuration file. There are some options that have no cooresponding command line option.

Anything after a pound sign ('#') is considered a comment and will be ignored. A line may be continued by ending the line in a backslash ('\'). Blank lines and any invalid key=value pairs are ignored.

## BUTTON SECTION OPTIONS
icon=<iconfile>

xpm icon for the button, accepts an absolute path or a path relative to a directory in the iconpath

command=<command>

command to execute when button is pressed, it should end with an to run it in the background

tooltip=<tooltip string>

tooltip that should be displayed over the button when the mouse is hovered over it

## WMAPPL SECTION OPTIONS
iconpath=<path1>:[path2]:...:[pathN]

a colon separated path to search for icons

name=<windowname>

window name (specify different names to run multiple instances)

tooltip_delay=<delay in milliseconds>

delay in milliseconds before appearance of tooltip

window=

run in windowed mode if this option is specified

debug=

run in debug mode if this option is specified

background_color=<color>

specifies the background color of wmappl

background_icon=<iconfile>

xpm icon for the background of wmappl, accepts an absolute path or a path relative to a directory in the iconpath (takes precedence over background_color option)

tooltip_foreground=<color>

foreground (text) color for tooltips

tooltip_background=<color>

background color for tooltips

tooltip_font=<X11 font string>

X11 font string for the font to use for tooltips

## EXAMPLE
The following example defines nine buttons, specifies wmappl options and demonstrates comments, line expansion and blank lines:

[wmappl]

iconpath=/usr/share/icons/wmappl:/usr/share/pixmaps/mini

name=Demo

window=

debug=

tooltip_delay=800 # 800 milliseconds

tooltip_foreground=rgb:ff/ff/ff # white tooltip text

tooltip_background=rgb:ff/00/00 # red tooltip background

tooltip_font=-*-bitstream vera serif-*-*-*-*-*-*-*-*-*-*-*-* # use vera serif font

background_color=rgb:73/7e/df # light blue wmappl background

background_icon=checker.xpm

\# the checkered background will override the light blue background

[info]

icon = info.xpm

command = xmessage "Reports bugs to: \

wmappl.sourceforge.net" &

tooltip = wmappl information

[man wmappl]

icon = wmappl.xpm

command = xterm -fg white -bg black -e man wmappl &

tooltip = open the wmappl man page

[wprefs]

icon = gnustep.xpm

command = /usr/share/GNUstep/WPrefs.app/WPrefs &

[mozilla]

icon = mozilla.xpm

command = mozilla &

[xterm]

icon = glowx.xpm

command = xterm &

[ghostview]

icon = ghost.xpm

command = gv &

[xmms]

icon = xmms.xpm

command = xmms &

tooltip = xmms gets a really really really \

really really really really really \

really really really really really \

long tooltip!

[ssh to work]

icon = ssh.xpm

command = xterm -fg green -bg black \

-e ssh -l user shell.work.com &

## REPORTING BUGS
Report bugs at http://wmappl.sourceforge.net

## WARRANTY
This is free software with ABSOLUTELY NO WARRANTY

## AUTHOR
Casey Harkins <charkins@pobox.com>

## SEE ALSO
wmappl(1)


wofi

package: wofi

title: wofi(5)

summary: configuration file and styling

text:
# wofi(5)

## NAME
wofi - configuration file and styling

## DESCRIPTION
Wofi's configuration format is very simple, consisting of key value pairs in snake case. The majority of the config options are the command line options, there are however a small handful of options only accessible via wofi's config.

Mode specific options for the built-in modes are documented in wofi(7). They are placed in the config file in the format mode-example_opt=val. For example dmenu has an option called parse_action which would be placed in the config as dmenu-parse_action=true.

Anything following a # is considered to be a comment unless the # is prefixed with a \. For this reason in order to put a backslash in the config it must be escaped as well giving \\.

## CONFIG OPTIONS
Most of the options here are the command flags as found in wofi(1) in snake case, however some are unique to the config.

style=PATH

Specifies the CSS file to use as the stylesheet.

stylesheet=PATH

Specifies the CSS file to use as the stylesheet. This option is NOT the same as style. Absolute paths are absolute however relative paths are relative to the wofi config folder location $XDG_CONFIG_HOME/wofi and NOT the current working directory as they are with style. They are also NOT relative to the path as specified by --conf. This option comes from rootbar and is probably more confusing than it's worth. You should probably use style unless you're sure this is what you want.

color=PATH

Specifies the colors file to use.

colors=PATH

Specifies the colors file to use. This option is NOT the same as color. Absolute paths are absolute however relative paths are relative to the wofi config folder location $XDG_CONFIG_HOME/wofi and NOT the current working directory as they are with color. They are also NOT relative to the path as specified by --conf. This option comes from rootbar and is probably more confusing than it's worth. You should probably use color unless you're sure this is what you want.

show=MODE

Specifies the mode to run in. A list of modes can be found in wofi(7).

mode=MODE

Identical to show.

width=WIDTH

Specifies the menu width in pixels or percent of screen size, default is 50%. Pixels are used unless the number ends with a %.

height=HEIGHT

Specifies the menu height in pixels or percent of screen size, default is 40%. Pixels are used unless the number ends with a %.

prompt=PROMPT

Sets the prompt to be display in the search box, default is the name of the mode.

xoffset=OFFSET

Sets the x offset from the location in pixels, default is 0.

x=OFFSET

Identical to xoffset.

yoffset=OFFSET

Sets the y offset from the location in pixels, default is 0.

y=OFFSET

Identical to yoffset.

normal_window=BOOL

If true runs wofi in a normal window instead of using wlr-layer-shell, default is false.

allow_images=BOOL

If true allows image escape sequences to be processed and rendered, default is false.

allow_markup=BOOL

If true allows pango markup to be processed and rendered, default is false.

cache_file=PATH

Specifies the cache file to load/store cache, default is $XDG_CACHE_HOME/wofi-<mode name> where <mode name> is the name of the mode, if $XDG_CACHE_HOME is not specified ~/.cache is used.

term=TERM

Specifies the term to use when running a program in a terminal. This overrides the default terminal run order which is kitty, alacritty, wezterm, foot, termite, gnome-terminal, weston-terminal in that order.

password=CHARACTER

Runs wofi in password mode using the specified character, default is false.

exec_search=BOOL

If true activiating a search with enter will execute the search not the first result, default is false.

no_custom_entry=BOOL

If true only entries will be submitted to modes, never the content of the search box, default is false.

hide_scroll=BOOL

If true hides the scroll bars, default is false.

matching=MODE

Specifies the matching mode, it can be either contains, strict-contains, multi-contains, or fuzzy, default is contains.

insensitive=BOOL

If true enables case insensitive search, default is false.

parse_search=BOOL

If true parses out image escapes and pango preventing them from being used for searching, default is false.

location=LOCATION

Specifies the location. See wofi(7) for more information, default is center.

no_actions=BOOL

If true disables multiple actions for modes that support it, default is false.

lines=LINES

Specifies the height in number of lines instead of pixels.

columns=COLUMNS

Specifies the number of columns to display, default is 1.

sort_order=ORDER

Specifies the default sort order. There are currently two orders, default and alphabetical. See wofi(7) for details.

gtk_dark=BOOL

If true, instructs wofi to use the dark variant of the current GTK theme (if available). Default is false.

search=STRING

Specifies something to search for immediately on opening

monitor=STRING

Sets the monitor to open on

pre_display_cmd=COMMAND

Specifies a printf-like string which is used on the entries prior to displaying them. This command is only used to represent the label widget's string, and won't affect the the output of the selected label.

orientation=ORIENTATION

Specifies the orientation, it can be either horizontal or vertical, default is vertical.

halign=ALIGN

Specifies the horizontal align for the entire scrolled area, it can be any of fill, start, end, or center, default is fill.

content_halign=ALIGN

Specifies the horizontal align for the individual entries, it can be any of fill, start, end, or center, default is fill.

valign=ALIGN

Specifies the vertical align for the entire scrolled area, it can be any of fill, start, end, or center, the default is orientation dependent. If vertical then it defaults to start, if horizontal it defaults to center.

filter_rate=RATE

Specifies the rate at which search results are updated in milliseconds, default is 100.

image_size=SIZE

Specifies the size of images in pixels when images are enabled, default is 32.

key_up=KEY

Specifies the key to use in order to move up. Default is Up(Up arrow). See wofi-keys(7) for the key codes.

key_down=KEY

Specifies the key to use in order to move down. Default is Down(Down arrow). See wofi-keys(7) for the key codes.

key_left=KEY

Specifies the key to use in order to move left. Default is Left(Left arrow). See wofi-keys(7) for the key codes.

key_right=KEY

Specifies the key to use in order to move right. Default is Right(Right arrow). See wofi-keys(7) for the key codes.

key_forward=KEY

Specifies the key to use in order to move forward. Default is Tab. See wofi-keys(7) for the key codes.

key_backward=KEY

Specifies the key to use in order to move backward. Default is Shift-ISO_Left_Tab(Shift+Tab). See wofi-keys(7) for the key codes.

key_submit=KEY

Specifies the key to use in order to submit an action. Default is Return. See wofi-keys(7) for the key codes.

key_exit=KEY

Specifies the key to use in order to exit wofi. Default is Escape. See wofi-keys(7) for the key codes.

key_pgup=KEY

Specifies the key to use in order to move one page up. Default is Page_Up. See wofi-keys(7) for the key codes.

key_pgdn=KEY

Specifies the key to use in order to move one page down. Default is Page_Down. See wofi-keys(7) for the key codes.

key_expand=KEY

Specifies the key to use in order to expand/contract multi-action entires. There is no default. See wofi-keys(7) for the key codes.

key_hide_search=KEY

Specifies the key to use in order to hide/show the search bar. There is no default. See wofi-keys(7) for the key codes.

key_copy=KEY

Specifies the key to use in order to copy the action text for the current entry. The default is Ctrl-c. See wofi-keys(7) for the key codes.

key_custom_(n)=KEY

Allows for configuring custom exit codes. For example setting key_custom_0=Ctrl-0 will make it so if you press Ctrl-0 wofi will set its exit status to 10. This will not cause wofi to exit, it will only set its exit code for when it does. 20 of these keys are configurable numbered 0-19. The exit status used is 10+n where n is the number attached to key_custom_n. There are no defaults for these. See wofi-keys(7) for the key codes.

line_wrap=MODE

Specifies the line wrap mode to use. The options are off, word, char, and word_char. Default is off.

global_coords=BOOL

Specifies whether x and y offsets should be calculated using the global compositor space instead of the current monitor. Default is false. This does not play well with locations and using it with them is not advised.

hide_search=BOOL

Specifies whether the search bar should be hidden. Default is false.

close_on_focus_loss=BOOL

Specifies whether to quit wofi when it loses focus. Default is false.

dynamic_lines=BOOL

Specifies whether wofi should be dynamically shrunk to fit the number of visible lines or if it should always stay the same size. Default is false.

layer=LAYER

Specifies the layer to open on. The options are background, bottom, top, and overlay. Default is top

copy_exec=PATH

Specifies the executable to pipe copy data into. $PATH will be scanned, this is not passed to a shell and must be an executable. Default is wl-copy.

single_click=BOOL

Specifies whether or not actions should be executed on a single click or a double click. Default is false.

pre_display_exec=BOOL

This modifies the behavior of pre_display_cmd and causes the command in question to be directly executed via fork/exec rather than through the shell.

use_search_box=BOOL

Specifies whether or not wofi should use a GtkSearchEntry or a regular GtkEntry. The search entry has a little search icon and a clear text button that the regular entry lacks. Default is true

## CSS SELECTORS
Any GTK widget can be selected by using the name of its CSS node, these however might change with updates and are not guaranteed to stay constant. Wofi also provides certain widgets with names and classes which can be referenced from CSS to give access to the most important widgets easily. wofi(7) contains the current widget layout used by wofi so if you want to get into CSS directly using GTK widget names look there for info.

\#window

The name of the window itself.

\#outer-box

The name of the box that contains everything.

\#input

The name of the search bar.

\#scroll

The name of the scrolled window containing all of the entries.

\#inner-box

The name of the box containing all of the entries.

\#img

The name of all images in entries displayed in image mode.

\#text

The name of all the text in entries.

\#unselected

The name of all entries currently unselected. A better way of doing this is to do #entry and combine that with #entry:selected

\#selected

The name of all entries currently selected. A better way of doing this is to do #entry:selected

.entry

The class attached to all entries. This is attached to the inside property box and is old, you probably want #entry instead

\#entry

The name of all entries.

\#expander-box

The name of all boxes shown when expanding entries with multiple actions

## COLORS
The colors file should be formatted as new line separated hex values. These values should be in the standard HTML format and begin with a hash. These colors will be loaded however wofi doesn't know what color should be used for what so you must reference them from your CSS.

You can reference these from your CSS by doing --wofi-color<n> where <n> is the line number - 1. For example to reference the color on line 1 you would do --wofi-color0.

The colors can also be referenced by doing --wofi-rgb-color<n> where <n> is the line number - 1. The difference between these is the format used to replace the macro.

--wofi-color<n> is replaced with an HTML color code in the format #FFFFFF. --wofi-rgb-color<n> is replaced with comma separated rgb values in the format 255, 255, 255. The correct usage of --wofi-rgb-color<n> is to wrap it in rgb() or rgba(). Note that it does not return an alpha value so combining it with rgba() should be done like so rgba(--wofi-rgb-color0, 0.8). This would set the color to line 1 with an opacity of 80%.


cntlist

package: wordnet-dict

title: cntlist(5)

text:
# cntlist(5)

## NAME
cntlist - file listing number of times each tagged sense occurs in a semantic concordance, sorted most to least frequently tagged

cntlist.rev - file listing number of times each tagged sense occurs in a semantic concordance, sorted by sense key

## DESCRIPTION
A cntlist file for a semantic concordance lists the number of times each semantically tagged sense occurs in the concordance and its sense number in the WordNet database. Each line in the file corresponds to a sense in the WordNet database to which at least one semantic tag points. Only senses that are tagged in a concordance are in the concordance's cntlist file.

### WordNet Database cntlist File
In the WordNet database, words are assigned sense numbers based on frequency of use in semantically tagged corpora. The cntlist file used by grind(1) to build the WordNet database and assign the sense numbers is a union of the cntlist files from the various semantic concordances that were formerly released by Princeton University. This combined cntlist file is provided with the WordNet package and is found in the WNSEARCHDIR directory.

The cntlist.rev file is used at run-time by the WordNet library code and browser interfaces to print in the output display the number of times each sense has been tagged.

### File Format
Each line in a cntlist file contains information for one sense. The file is ordered from most to least frequently tagged sense. The fields are separated by one space, and each line is terminated with a newline character. Senses having the same tag_cnt value are listed in reverse alphabetical order of the lemma field of the sense_key.

Each line in cntlist is of the form:

tag_cnt sense_key sense_number

where tag_cnt is the decimal number of times the sense is tagged in the corresponding semantic concordance. sense_key is a WordNet sense encoding and sense_number is a WordNet sense number as described in

The cntlist.rev file contains the same fields described above, in the following order:

sense_key sense_number tag_cnt

## NOTES
Princeton no longer maintains or releases the Semantic Concordance files. The cntlist file used to order the senses in WordNet 3.0 was generated from the Semantic Concordance files at the point that they were last updated in 2001. In general, the order of senses presented usually reflects what the user would expect, however sense ordering is now less reliable than in prior releases and should not be construed as an accurate indicator of frequency of use.

## 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.

HKEY_CURRENT_USER\SOFTWARE\WordNet\3.0\wnres

User's default browser options.

## FILES
cntlist, cntlist.rev

file of combined semantic concordance cntlist files. Used to assign sense numbers in WordNet database

## SEE ALSO
grind(1), wnintro(5), senseidx(5).


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

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).


xbps.d

package: xbps

title: xbps.d(5)

summary: XBPS configuration directory

text:
# xbps.d(5)

## NAME
xbps.d — XBPS configuration directory

## SYNOPSIS

- /etc/xbps.d/*.conf

- /usr/share/xbps.d/*.conf

## DESCRIPTION
The xbps.d configuration directory sets properties for the XBPS package manager. The configuration directory, by default set to /etc/xbps.d overrides settings from files available in the system configuration directory, by default set to /usr/share/xbps.d.

Files in the configuration directory have preference over files in the system configuration directory.

Only files with the .conf extension will be processed in alphabetical order.

The configuration files can set various keywords, using the syntax `key=value`. No whitespace between the key and its value is allowed, nor trailing whitespaces after its value. Multiple entries are permitted for the ignorepkg, include, noextract, preserve, repository and virtualpkg keywords, but each entry must specify only one value.

## KEYWORDS
architecture=string

Overrides the native machine architecture, as reported by uname(2).

bestmatching=true|false

When this keyword is enabled, a package with the greatest version available in all registered repositories will be chosen. This will be applied to dependencies as well.

cachedir=path

Sets the default cache directory to store downloaded binary packages from remote repositories, as well as its signatures. If path starts with '/' it's an absolute path, otherwise it will be relative to rootdir.

ignorepkg=pkgname

Declares an ignored package. If a package depends on an ignored package the dependency is always satisfied, without installing the ignored package. It does not disable checks for introduced incompatibilities like shared library dependencies.

noextract=pattern

Skip extraction of matching files. Patterns starting with a exclamation mark negate the previous match, a single backslash can be used to escape the exclamation mark. In the following example all files matching the first pattern will not be extracted, but files that also match the second pattern will still be extracted.

noextract=/usr/bin/f*

noextract=!/usr/bin/foo

include=path/file.conf

Imports settings from the specified configuration file. NOTE only one level of nesting is allowed.

preserve=path

If set ignores modifications to the specified files, while unpacking packages. Absolute path to a file and file globbing are supported, example:

preserve=/usr/bin/foo

preserve=/etc/foo/*.conf

keepconf=true|false

If set to false (default), xbps will overwrite configuration files that have not been changed since installation with their new version (if available). If set to true, xbps will not overwrite configuration files that have not been changed since installation. Instead, the new version (if available) is saved next to the configuration file as <name>.new-<version>.

repository=url

Declares a package repository. The url argument accepts local and remote repositories. A complete url or absolute path to the directory that stores the <arch>-repodata archive is expected. Note that remote repositories must be signed using xbps-rindex(1), example:

repository=https://repo-default.voidlinux.org/current

repository=/hostdir/binpkgs

rootdir=path

Sets the default root directory.

staging=true|false

Enables or disables the use of staged packages in remote repositories.

syslog=true|false

Enables or disables syslog logging. Enabled by default.

virtualpkg=[vpkgname|vpkgver]:pkgname

Declares a virtual package. A virtual package declaration is composed by two components delimited by a colon, example:

virtualpkg=cron-daemon:dcron

Any request to the cron-daemon virtual package will be resolved to the dcron real package.

The first component expects a virtual package name and optionally its version component. The second component expects a package name to match the real package.

## ENVIRONMENT
XBPS_ARCH

Overrides uname(2) machine result with this value. Useful to install packages with a fake architecture.

XBPS_TARGET_ARCH

Sets the target architecture to this value. This variable differs from XBPS_ARCH in that it allows you to install packages partially, because configuration phase is skipped (the target binaries might not be compatible with the native architecture).

## FILES
/etc/xbps.d

Default configuration directory.

/usr/share/xbps.d

Default system configuration directory.

/var/db/xbps/.<pkgname>-files.plist

Package files metadata.

/var/db/xbps/pkgdb-0.38.plist

Default package database (0.38 format). Keeps track of installed packages and properties.

/var/cache/xbps

Default cache directory to store downloaded binary packages.

/usr/share/xbps.d/xbps.conf

Annotated sample configuration file.

## SEE ALSO
xbps-alternatives(1), xbps-checkvers(1), xbps-create(1), xbps-dgraph(1), xbps-digest(1), xbps-fbulk(1), xbps-fetch(1), xbps-install(1), xbps-pkgdb(1), xbps-query(1), xbps-reconfigure(1), xbps-remove(1), xbps-rindex(1), xbps-uchroot(1), xbps-uunshare(1)

## AUTHORS
Juan Romero Pardines <xtraeme@gmail.com>

## BUGS
Probably, but I try to make this not happen. Use it under your own responsibility and enjoy your life.

Report bugs at https://github.com/void-linux/xbps/issues


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.

### 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 <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>

- XDG Desktop Entry specification <https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html>

- XDG Association between MIME type and applications specification <https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html>


xdg-desktop-portal-wlr

package: xdg-desktop-portal-wlr

title: xdg-desktop-portal-wlr(5)

text:
# xdg-desktop-portal-wlr(5)

## NAME
xdg-desktop-portal-wlr - an xdg-desktop-portal backend for wlroots

## DESCRIPTION
xdg-desktop-portal-wlr (or xdpw for short) allows applications to request screenshots and screencasts via xdg-desktop-portal in wlroots-based Wayland compositors.

xdpw will try to load the configuration file from these locations:

- $XDG_CONFIG_HOME/xdg-desktop-portal-wlr/$XDG_CURRENT_DESKTOP

- $XDG_CONFIG_HOME/xdg-desktop-portal-wlr/config

- /etc/xdg/xdg-desktop-portal-wlr/$XDG_CURRENT_DESKTOP

- /etc/xdg/xdg-desktop-portal-wlr/config

$XDG_CONFIG_HOME defaults to ~/.config. $XDG_CURRENT_DESKTOP can be a colon separated list. Each element of that list will be tried.

The configuration files use the INI file format. Example:

```
[screencast]
output_name=HDMI-A-1
max_fps=30
exec_before=disable_notifications.sh
exec_after=enable_notifications.sh
chooser_type=simple
chooser_cmd=slurp -f 'Monitor: %o' -or
```

## SCREENCAST OPTIONS
These options need to be placed under the [screencast] section.

output_name = name

Select which output will be screencast. This option is used with chooser_type = none. The list of available outputs can be obtained via wayland-info(1) (under the wl_output section).

max_fps = limit

Limit the number of frames per second to the provided rate. This is useful to reduce CPU usage when capturing frames at the output's refresh rate is unnecessary.

exec_before = command

Execute command before starting a screencast. The command will be executed within sh.

exec_after = command

Execute command after ending all screencasts. The command will be executed within sh.

chooser_cmd = command

Run this command to select an output. For more details see OUTPUT CHOOSER.

chooser_type = type

Specifies the input send to the chooser. The supported types are:

- default: xdpw will try to use the first chooser found in the list of hardcoded choosers (slurp, wmenu, wofi, rofi, bemenu, mew, fuzzel) and will fallback to an arbitrary output if none of those were found.

- none: xdpw will allow screencast either on the output given by output_name, or if empty an arbitrary output without further interaction.

- simple, dmenu: xdpw will launch the chooser given by chooser_cmd. For more details see OUTPUT CHOOSER.

force_mod_linear = bool

Force buffers with implicit modifiers to be linear (experimental) Setting this option to 1 will force xdpw to allocate dma-bufs with implicit modifier as linear. This option shouldn't be required on single gpu setups, but can increase compatibility especially on setups with multiple gpus.

This option is experimental and can be removed or replaced in future versions.

### OUTPUT CHOOSER
The chooser can be any program or script with the following behaviour:

- It returns any error code except 127. The error code 127 is internally used to signal that no command could be found and all output from it will be ignored.

- It returns a string on stdout, which is valid if it matches on of the the following:

- For simple choosers:

- The prefix "Monitor: " followed by the name of a valid output as given by wayland-info(1).

- The prefix "Window: " followed by the ext-foreign-toplevel-list-v1 identifier as given by lswt(1).

- For dmenu choosers: one of the lines provided via stdin.

Everything else will be handled as declined by the user.

- To signal that the user has declined screencast, the chooser should exit without anything on stdout.

Supported types of choosers via the chooser_type option:

- simple: the chooser is just called without anything further on stdin.

- dmenu: the chooser receives a newline separated list (dmenu style) of outputs on stdin.

## SEE ALSO
pipewire(1)


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)


projects

package: xfsprogs

title: projects(5)

summary: persistent project root definition

text:
# projects(5)

## NAME
projects - persistent project root definition

## DESCRIPTION
The /etc/projects file provides a mapping between numeric project identifiers and those directories which are the roots of the quota tree. Its format is simply:

```
# comments are hash-prefixed
# ...
10:/export/cage
42:/var/log
```

The /etc/projects file is optional, instead xfs_quota(8) can be used with the -p argument to specify a project root directly for each operation.

## SEE ALSO
xfs_quota(8), xfsctl(3), projid(5).


projid

title: projid(5)

summary: the project name mapping file

text:
# projid(5)

## NAME
projid - the project name mapping file

## DESCRIPTION
The /etc/projid file provides a mapping between numeric project identifiers and a simple human readable name (similar relationship to the one that exists between usernames and uids). Its format is simply:

```
# comments are hash-prefixed
# ...
cage:10
logfiles:42
```

This file is optional, if a project identifier cannot be mapped to a name, it will be parsed and displayed as a numeric value.

## SEE ALSO
xfs_quota(8), xfsctl(3), projects(5).