tags

package: universal-ctags

title: tags(5)

text:
# tags(5)

## NAME
tags - Vi tags file format extended in ctags projects

## DESCRIPTION
The contents of next section is a copy of FORMAT file in exuberant ctags source code in its subversion repository at sourceforge.net.

Exceptions introduced in Universal-ctags are explained inline with "EXCEPTION" marker.

----

## PROPOSAL FOR EXTENDED VI TAGS FILE FORMAT

```
Version: 0.06 DRAFT
Date: 1998 Feb 8
Author: Bram Moolenaar <Bram at vim.org> and Darren Hiebert <dhiebert at users.sourceforge.net>
```

### Introduction
The file format for the "tags" file, as used by Vi and many of its descendants, has limited capabilities.

This additional functionality is desired:

1.

Static or local tags. The scope of these tags is the file where they are defined. The same tag can appear in several files, without really being a duplicate.

2.

Duplicate tags. Allow the same tag to occur more then once. They can be located in a different file and/or have a different command.

3.

Support for C++. A tag is not only specified by its name, but also by the context (the class name).

4.

Future extension. When even more additional functionality is desired, it must be possible to add this later, without breaking programs that don't support it.

### From proposal to standard
To make this proposal into a standard for tags files, it needs to be supported by most people working on versions of Vi, ctags, etc.. Currently this standard is supported by:

Darren Hiebert <dhiebert at users.sourceforge.net>

Exuberant ctags

Bram Moolenaar <Bram at vim.org>

Vim (Vi IMproved)

These have been or will be asked to support this standard:

Nvi

Keith Bostic <bostic at bsdi.com>

Vile

Tom E. Dickey <dickey at clark.net>

NEdit

Mark Edel <edel at ltx.com>

CRiSP

Paul Fox <fox at crisp.demon.co.uk>

Lemmy

James Iuliano <jai at accessone.com>

Zeus

Jussi Jumppanen <jussij at ca.com.au>

Elvis

Steve Kirkendall <kirkenda at cs.pdx.edu>

FTE

Marko Macek <Marko.Macek at snet.fri.uni-lj.si>

### Backwards compatibility
A tags file that is generated in the new format should still be usable by Vi. This makes it possible to distribute tags files that are usable by all versions and descendants of Vi.

This restricts the format to what Vi can handle. The format is:

1.

The tags file is a list of lines, each line in the format:

```
{tagname}<Tab>{tagfile}<Tab>{tagaddress}
```

{tagname}

Any identifier, not containing white space.. EXCEPTION: Universal-ctags violates this item of the proposal; tagname may contain spaces. However, tabs are not allowed.

<Tab>

Exactly one TAB character (although many versions of Vi can handle any amount of white space).

{tagfile}

The name of the file where {tagname} is defined, relative to the current directory (or location of the tags file?).

{tagaddress}

Any Ex command. When executed, it behaves like 'magic' was not set.

2.

The tags file is sorted on {tagname}. This allows for a binary search in the file.

3.

Duplicate tags are allowed, but which one is actually used is unpredictable (because of the binary search).

The best way to add extra text to the line for the new functionality, without breaking it for Vi, is to put a comment in the {tagaddress}. This gives the freedom to use any text, and should work in any traditional Vi implementation.

For example, when the old tags file contains:

```
main    main.c  /^main(argc, argv)$/
DEBUG   defines.c       89
```

The new lines can be:

```
main    main.c  /^main(argc, argv)$/;"any additional text
DEBUG   defines.c       89;"any additional text
```

Note that the ';' is required to put the cursor in the right line, and then the '"' is recognized as the start of a comment.

For Posix compliant Vi versions this will NOT work, since only a line number or a search command is recognized. I hope Posix can be adjusted. Nvi suffers from this.

### Security
Vi allows the use of any Ex command in a tags file. This has the potential of a trojan horse security leak.

The proposal is to allow only Ex commands that position the cursor in a single file. Other commands, like editing another file, quitting the editor, changing a file or writing a file, are not allowed. It is therefore logical to call the command a tagaddress.

Specifically, these two Ex commands are allowed:

•

A decimal line number:

```
89
```

•

A search command. It is a regular expression pattern, as used by Vi, enclosed in // or ??:

```
/^int c;$/
?main()?
```

There are two combinations possible:

•

Concatenation of the above, with ';' in between. The meaning is that the first line number or search command is used, the cursor is positioned in that line, and then the second search command is used (a line number would not be useful). This can be done multiple times. This is useful when the information in a single line is not unique, and the search needs to start in a specified line.

```
/struct xyz {/;/int count;/
389;/struct foo/;/char *s;/
```

•

A trailing comment can be added, starting with ';"' (two characters: semi-colon and double-quote). This is used below.

```
89;" foo bar
```

This might be extended in the future. What is currently missing is a way to position the cursor in a certain column.

### Goals
Now the usage of the comment text has to be defined. The following is aimed at:

1.

Keep the text short, because:

- The line length that Vi can handle is limited to 512 characters.

- Tags files can contain thousands of tags. I have seen tags files of several Mbytes.

- More text makes searching slower.

2.

Keep the text readable, because:

- It is often necessary to check the output of a new ctags program.

- Be able to edit the file by hand.

- Make it easier to write a program to produce or parse the file.

3.

Don't use special characters, because:

•

It should be possible to treat a tags file like any normal text file.

### Proposal
Use a comment after the {tagaddress} field. The format would be:

```
{tagname}<Tab>{tagfile}<Tab>{tagaddress}[;"<Tab>{tagfield}..]
```

{tagname}

Any identifier, not containing white space.. EXCEPTION: Universal-ctags violates this item of the proposal; name may contain spaces. However, tabs are not allowed. Conversion, for some characters including <Tab> in the "value", explained in the last of this section is applied.

<Tab>

Exactly one TAB character (although many versions of Vi can handle any amount of white space).

{tagfile}

The name of the file where {tagname} is defined, relative to the current directory (or location of the tags file?).

{tagaddress}

Any Ex command. When executed, it behaves like 'magic' was not set. It may be restricted to a line number or a search pattern (Posix).

Optionally:

;"

semicolon + doublequote: Ends the tagaddress in way that looks like the start of a comment to Vi.

{tagfield}

See below.

A tagfield has a name, a colon, and a value: "name:value".

- The name consist only out of alphabetical characters. Upper and lower case are allowed. Lower case is recommended. Case matters ("kind:" and "Kind: are different tagfields). EXCEPTION: Universal-ctags allows users to use a numerical character in the name other than its initial letter.

- The value may be empty. It cannot contain a <Tab>.

- When a value contains a \t, this stands for a <Tab>.

- When a value contains a \r, this stands for a <CR>.

- When a value contains a \n, this stands for a <NL>.

- When a value contains a \\, this stands for a single \ character.

Other use of the backslash character is reserved for future expansion. Warning: When a tagfield value holds an MS-DOS file name, the backslashes must be doubled!

EXCEPTION: Universal-ctags introduces more conversion rules.

- When a value contains a \a, this stands for a <BEL> (0x07).

- When a value contains a \b, this stands for a <BS> (0x08).

- When a value contains a \v, this stands for a <VT> (0x0b).

- When a value contains a \f, this stands for a <FF> (0x0c).

- The characters in range 0x01 to 0x1F included, and 0x7F are converted to \x prefixed hexadecimal number if the characters are not handled in the above "value" rules.

- The leading space (0x20) and ! (0x21) in {tagname} are converted to \x prefixed hexadecimal number (\x20 and \x21) if the tag is not a pseudo-tag. As described later, a pseudo-tag starts with !. These rules are for distinguishing pseudo-tags and non pseudo-tags (regular tags) when tags lines in a tag file are sorted.

Proposed tagfield names:

FIELD-NAME

DESCRIPTION

arity

Number of arguments for a function tag.

class

Name of the class for which this tag is a member or method.

enum

Name of the enumeration in which this tag is an enumerator.

file

Static (local) tag, with a scope of the specified file. When the value is empty, {tagfile} is used.

function

Function in which this tag is defined. Useful for local variables (and functions). When functions nest (e.g., in Pascal), the function names are concatenated, separated with '/', so it looks like a path.

kind

Kind of tag. The value depends on the language. For C and C++ these kinds are recommended: 0.0 c class name d define (from #define XXX) e enumerator f function or method name F file name g enumeration name m member (of structure or class data) p function prototype s structure name t typedef u union name v variable 168u When this field is omitted, the kind of tag is undefined.

struct

Name of the struct in which this tag is a member.

union

Name of the union in which this tag is a member.

Note that these are mostly for C and C++. When tags programs are written for other languages, this list should be extended to include the used field names. This will help users to be independent of the tags program used.

Examples:

```
asdf    sub.cc  /^asdf()$/;"    new_field:some\svalue   file:
foo_t   sub.h   /^typedef foo_t$/;"     kind:t
func3   sub.p   /^func3()$/;"   function:/func1/func2   file:
getflag sub.c   /^getflag(arg)$/;"      kind:f  file:
inc     sub.cc  /^inc()$/;"     file: class:PipeBuf
```

The name of the "kind:" field can be omitted. This is to reduce the size of the tags file by about 15%. A program reading the tags file can recognize the "kind:" field by the missing ':'. Examples:

```
foo_t   sub.h   /^typedef foo_t$/;"     t
getflag sub.c   /^getflag(arg)$/;"      f       file:
```

Additional remarks:

•

When a tagfield appears twice in a tag line, only the last one is used.

Note about line separators:

Vi traditionally runs on Unix systems, where the line separator is a single linefeed character <NL>. On MS-DOS and compatible systems <CR><NL> is the standard line separator. To increase portability, this line separator is also supported.

On the Macintosh a single <CR> is used for line separator. Supporting this on Unix systems causes problems, because most fgets() implementation don't see the <CR> as a line separator. Therefore the support for a <CR> as line separator is limited to the Macintosh.

Summary:

line separator

generated on

accepted on

<LF>

Unix

Unix, MS-DOS, Macintosh

<CR>

Macintosh

Macintosh

<CR><LF>

MS-DOS

Unix, MS-DOS, Macintosh

The characters <CR> and <LF> cannot be used inside a tag line. This is not mentioned elsewhere (because it's obvious).

Note about white space:

Vi allowed any white space to separate the tagname from the tagfile, and the filename from the tagaddress. This would need to be allowed for backwards compatibility. However, all known programs that generate tags use a single <Tab> to separate fields.

There is a problem for using file names with embedded white space in the tagfile field. To work around this, the same special characters could be used as in the new fields, for example \s. But, unfortunately, in MS-DOS the backslash character is used to separate file names. The file name c:\vim\sap contains \s, but this is not a <Space>. The number of backslashes could be doubled, but that will add a lot of characters, and make parsing the tags file slower and clumsy.

To avoid these problems, we will only allow a <Tab> to separate fields, and not support a file name or tagname that contains a <Tab> character. This means that we are not 100% Vi compatible. However, there is no known tags program that uses something else than a <Tab> to separate the fields. Only when a user typed the tags file himself, or made his own program to generate a tags file, we could run into problems. To solve this, the tags file should be filtered, to replace the arbitrary white space with a single <Tab>. This Vi command can be used:

```
:%s/^\([^ ^I]*\)[ ^I]*\([^ ^I]*\)[ ^I]*/\1^I\2^I/
```

(replace ^I with a real <Tab>).

TAG FILE INFORMATION:

Pseudo-tag lines can be used to encode information into the tag file regarding details about its content (e.g. have the tags been sorted?, are the optional tagfields present?), and regarding the program used to generate the tag file. This information can be used both to optimize use of the tag file (e.g. enable/disable binary searching) and provide general information (what version of the generator was used).

The names of the tags used in these lines may be suitably chosen to ensure that when sorted, they will always be located near the first lines of the tag file. The use of "!_TAG_" is recommended. Note that a rare tag like "!" can sort to before these lines. The program reading the tags file should be smart enough to skip over these tags.

The lines described below have been chosen to convey a select set of information.

Tag lines providing information about the content of the tag file:

```
!_TAG_FILE_FORMAT   {version-number}        /optional comment/
!_TAG_FILE_SORTED   {0|1}                   /0=unsorted, 1=sorted/
```

The {version-number} used in the tag file format line reserves the value of "1" for tag files complying with the original UNIX vi/ctags format, and reserves the value "2" for tag files complying with this proposal. This value may be used to determine if the extended features described in this proposal are present.

Tag lines providing information about the program used to generate the tag file, and provided solely for documentation purposes:

```
!_TAG_PROGRAM_AUTHOR        {author-name}   /{email-address}/
!_TAG_PROGRAM_NAME  {program-name}  /optional comment/
!_TAG_PROGRAM_URL   {URL}   /optional comment/
!_TAG_PROGRAM_VERSION       {version-id}    /optional comment/
```

EXCEPTION: Universal-ctags introduces more kinds of pseudo-tags. See ctags-client-tools(7) about them.

----

## EXCEPTIONS IN UNIVERSAL-CTAGS
Universal-ctags supports this proposal with some exceptions.

### Exceptions
1.

{tagname} in tags file generated by Universal-ctags may contain spaces and several escape sequences. Parsers for documents like Tex and reStructuredText, or liberal languages such as JavaScript need these exceptions. See {tagname} of Proposal section for more detail about the conversion.

2.

"name" part of {tagfield} in a tag generated by Universal-ctags may contain numeric characters, but the first character of the "name" must be alphabetic.

### Compatible output and weakness
Default behavior (--output-format=u-ctags option) has the exceptions. In other hand, with --output-format=e-ctags option ctags has no exception; Universal-ctags command may use the same file format as Exuberant-ctags. However, --output-format=e-ctags throws away a tag entry which name includes a space or a tab character. TAG_OUTPUT_MODE pseudo-tag tells which format is used when ctags generating tags file.

## SEE ALSO
ctags(1), ctags-client-tools(7), ctags-incompatibilities(7), readtags(1)


odbc.ini

package: unixODBC

title: odbc.ini(5)

text:
# odbc.ini(5)

## NAME
/etc/odbc.ini, $HOME/.odbc.ini - unixODBC data sources configuration

## DESCRIPTION
/etc/odbc.ini is text configuration file for the system wide ODBC data sources (i. e. database connections). $HOME/.odbc.ini contains the configuration for user-specific data sources.

## SEE ALSO
odbcinst(1), isql(1), odbcinst.ini(5)

## AUTHORS
The authors of unixODBC are Peter Harvey <pharvey@codebydesign.com> and Nick Gorham <nick@lurcher.org>. For the full list of contributors see the AUTHORS file.

## COPYRIGHT
unixODBC is licensed under the GNU Lesser General Public License. For details about the license, see the COPYING file.


odbcinst.ini

title: odbcinst.ini(5)

text:
# odbcinst.ini(5)

## NAME
/etc/odbcinst.ini - An unixODBC drivers configuration

## DESCRIPTION
/etc/odbcinst.ini is a text configuration file for unixODBC drivers. It can be edited by hand, but the recommended way to update this file is to use the odbcinst(1) utility.

## FILE FORMAT
The general .ini file format is:

```
[SectionName1]
key1 = value1
key2 = value2
...
[SectionName2]
key1 = value1
key2 = value2
...
```

Each ODBC driver has its own section and can be referred to by the name of its section. Recognized configuration keys are:

Description

A text string briefly describing the driver.

Driver

A filesystem path to the actual driver library.

Setup

A filesystem path to the driver setup library.

FileUsage

odbcinst(1) entry, if you edit the configuration file by hand, you have to supply it yourself.

### TEMPLATE FILES
The recommended way to manage the drivers is using the odbcinst(1) utility. You can install the drivers by supplying it with template file, which has the same format as this file.

## EXAMPLES
An example of the actual PostgreSQL driver:

```
[PostgreSQL]
Description = PostgreSQL driver for GNU/Linux
Driver      = /usr/lib/psqlodbcw.so
Setup       = /usr/lib/libodbcpsqlS.so
FileUsage   = 1
```

By specifying the driver like that, you can then reference it in the odbc.ini(5) as follows:

```
Driver = PostgreSQL
```

The recommended way to add that driver is by creating a template file containing:

```
[PostgreSQL]
Description = PostgreSQL driver for GNU/Linux
Driver      = /usr/lib/psqlodbcw.so
Setup       = /usr/lib/libodbcpsqlS.so
```

and call the odbcinst(1):

\# odbcinst -i -d -f template.ini

## SEE ALSO
odbcinst(1), odbc.ini(5)

## AUTHORS
The authors of unixODBC are Peter Harvey <pharvey@codebydesign.com> and Nick Gorham <nick@lurcher.org>. For the full list of contributors see the AUTHORS file.

## COPYRIGHT
unixODBC is licensed under the GNU Lesser General Public License. For details about the license, see the COPYING file.


utftpd.conf

package: utftpd

title: utftpd.conf(5)

summary: rules for utftpd

text:
# utftpd.conf(5)

## NAME
utftpd.conf - rules for utftpd

## DESCRIPTION
utftpd.conf containes rules for utftpd. It cannot be used by utftpd directly, but needs to be converted through use of utftpd_make(8).

## FORMAT
Empty lines in the input are ignored, as are lines which start with a hash sign (#). All other lines may either be V1 format definitions (compatability to versions <0.2.1, see below), class definitions or client definitions.

V1 and V2 format may be intermixed, although i suspect that this will not look too beautiful.

V1 is described in an own section. All other sections deal with the V2 format.

## CLASS DEFINITION
Classes (which other people may or may not call templates) allow to define defaults variable assignments:

```
      class read_ok {

      	read="/tmp"

      }
```

Classes may inherit from other classes:

```
      class write_ok { write="/tmp" }

      # a class which only inherits:

      class readwrite_ok: read_ok,write_ok;

      class readwrite_ok2: read_ok {write="/tmp";}
```

The second and third class are identical.

It's possible to assign more than one variable to a class:

```
      class rcs { rcs-co=/bin/co; rcs-ci=/bin/ci }
```

Here is something which doesn't work:

```
      class base {read="123";}

      class c1:base { read+="456" }

      class c2: { read="789" }
	  class conflict:c1,c2;
```

`c1' and `c2' conflict: both define `read'. There is no simple and clean solution to this problem.

## CLIENT DEFINITION
A client definition consists of an address specification, optional class defintions, and variable assignments. An example:

```
      class base {

        base="/tftpboot";

        images="${base}/images/";

        config="${base}/config/"

      }

      # allow read access to the own config file and the images directory.

      class read_ok { read="${config}${name}:${images}"; }

      # allow write access to the own config file.

      class readwrite_ok:read_ok { write="${config}${name}"; }

      # also allow read access to /etc. Don't do that in real life, every user can

      # use tftp clients ...

      class etc_ok { read+=":/etc/"; }

      client 127.0.0.1: readwrite_ok { name="localhost"}

      client 194.245.80.2:readwrite_ok,etc_ok { name="tirka"}
```

## STRING REPLACEMENTS
The ${base} thing you can see above will be replaced by the value of the variable base. It's an error if that variable is undefined, utftpd_make will stop.

String replacements are done before the strings get written to the configuration database, not in the daemon. Therefore there is no chance to replace something by a client IP address.

## VARIABLE ASSIGNMENT
There are three forms of variable assignments:

### Simple 'var = value' assignments
utftpd_make will stop if the variable is already defined.

### 'override var = value' assignments
utftpd_make will override a old value (if any) with the new one, otherwise it will create the variable.

### 'var += value' assignments
utftpd_make will append the new value to an old one (if the variable is not already defined it will be created, `+=' then is equal to a `=' assignment.

## ADDRESSES
Adresses may be spefified as follows:

```
      127.0.0.1

127.

      194.245.80.2

      194.245.80.2/28

      194.245.80.2-5

      194.245.0.0/16

      194.176.0-31.

      default
```

Be careful with the / masks: The slash makes utftpd_make create on entry in the database file for every ip address matches. 194.245.0.0/16 stands for 65536 addresses, and is certainly a waste of disk space.

The dash also creates one entry for each match, but 194.176.0-31. only creates 32 entries.

Please note that only the first entry in configuration file which matches a given IP address is used. This does not work (but will silently fail, not lead to an error message):

```
      # 194.245.80.2 may write

      client 194.245.80.2 {write="/"; }

      # allow the whole 194.245.80.* to read

      client 194.245.80. {read="/";}
```

194.245.80.2 will only be able to write, _not_ to read. I consider this a feature: TFTP knows no security at all, so i force you to tell the daemon exactly what to allow. Please note that you should never give read or write access to your root directory.

utftpd_make dislikes duplicate addresses.

## RECOGNIZED VARIABLES
utftpd recognizes the following variables in the configuration file:

chroot change working and root directory to the value. Note that utftpd needs to have to necessary rights to do so (this probably means it has still run under root. Use the uid feature to change that. You should not let utftpd run as root.)

dir change working directory. This just changes the way utftpd interprets relative file names (those starting without a /) it receives from clients. Note that you have to specify full paths for the access configuration variables (below) anyway: utftpd uses full qualified file names internally.

uid change user/group ID to the value (which may be a name or a number. Note that, in case of a global chroot, see the utftpd manual page, the system passwd may not be available anymore).

read specifies a list of directories or the daemon may read. Entries are separated by colons (as in $PATH). This may use wildcards.

write specifies a list of directories or files the daemon may overwrite. This may use wildcards.

create specifies a list of directories the daemon may create files in, or files the daemon may create. Note that the create list does not include the write list (or vice versa). This may use wildcards.

sccs-get contains the path to the get command of the SCCS system.

sccs-delta contains the path to the delta command of the SCCS system. If both are given and a SCCS version of a requested file exists then utftpd will try to use SCCS.

sccs-unget contains the path to the unget command of the SCCS system. If this and sccs-clean are missing then utftpd will check in unchanged files. In other words: If one or both of those options are given utftpd will try to not check in unchanged files under SCCS control. This can be an important feature if, for examples, your routers automatically save their configuration to a tftp server every night.

sccs-clean contains the path to the clean command of the SCCS system (this seems to be non-standard). See sccs-unget for a description.

rcs-ci contains the path to the ci command of the RCS system.

rcs-co contains the path to the co command of the RCS system. If both are given and a RCS version of a requested file exists in a RCS subdirectory (meaning RCS/file,v) then utftpd will try to use RCS.

SCCS will be preferred over RCS if both are found. A good place to set the revision control variables is the default target.

## RESOLVING
When utftpd looks for a configuration variable it will first look for that variable in a cdb entry for 1.2.3.4 (e.g., the IP address of the client), then in an entry for 1.2.3., then 1.2., then 1., and then default.

Only the first occurance of a variable will be honored.

Given the following example:

```
      client 194.245.80.2 {

        dir="/ohse.de/tirka" ;

        read=${dir}; write=${dir}; create=${dir};

      }

      client 194.245.80. {

        read="/ohse.de" ;

      }

      client default { read="/tmp" }
```

The machine 194.245.80.2 may read, write or create the file /ohse.de/tirka or may read, write or create files in a directory with the same name (if that directory exists, of course). It will not be able to read a file /ohse.de/serak, which all other machines of the 194.245.80.* range are able to do. Everyone else except the 194.245.80.* range may read from /tmp.

## V1 FORMAT
V1 format is deprecated. It may vanish some day, and is left just for compatibility with versions of utftpd prior to 0.2.1.

V1 format definitions end at the end of the line. They consist of an address specification (identical to the format used now), a colon, and one or many variable assignments.

Each assignment consists of a list of variables, each separated with a comma, which are followed by a pair of parenthesis containing the value to be assigned (to each of that "list of variables") between them, after which other variable names may follow:

```
address-specification: VAR11[,VAR12[,VAR13 ...]] ( value ) [VAR21[,VAR22[,VAR23 ...]] ( next value ) ...]
```

(really all on one line, please).

## SEE ALSO
utftpd(8), utftpd_make(8)


terminal-colors.d

package: util-linux

title: terminal-colors.d(5)

text:
# terminal-colors.d(5)

## NAME
terminal-colors.d - configure output colorization for various utilities

## SYNOPSIS
/etc/terminal-colors.d/[[name][@term].][type]

## DESCRIPTION
Files in this directory determine the default behavior for utilities when coloring output.

The name is a utility name. The name is optional and when none is specified then the file is used for all unspecified utilities.

The term is a terminal identifier (the TERM environment variable). The terminal identifier is optional and when none is specified then the file is used for all unspecified terminals.

The type is a file type. Supported file types are:

disable

Turns off output colorization for all compatible utilities.

enable

Turns on output colorization; any matching disable files are ignored.

scheme

Specifies colors used for output. The file format may be specific to the utility, the default format is described below.

If there are more files that match for a utility, then the file with the more specific filename wins. For example, the filename "@xterm.scheme" has less priority than "dmesg@xterm.scheme". The lowest priority are those files without a utility name and terminal identifier (e.g., "disable").

The user-specific $XDG_CONFIG_HOME/terminal-colors.d or $HOME/.config/terminal-colors.d overrides the global setting.

## DEFAULT SCHEME FILES FORMAT
The following statement is recognized:

name color-sequence

The name is a logical name of color sequence (for example "error"). The names are specific to the utilities. For more details always see the COLORS section in the man page for the utility.

The color-sequence is a color name, ASCII color sequences or escape sequences.

### Color names
black, blink, blue, bold, brown, cyan, darkgray, gray, green, halfbright, lightblue, lightcyan, lightgray, lightgreen, lightmagenta, lightred, magenta, red, reset, reverse, and yellow.

### ANSI color sequences
The color sequences are composed of sequences of numbers separated by semicolons. The most common codes are:

0

to restore default color

1

for brighter colors

4

for underlined text

5

for flashing text

30

for black foreground

31

for red foreground

32

for green foreground

33

for yellow (or brown) foreground

34

for blue foreground

35

for purple foreground

36

for cyan foreground

37

for white (or gray) foreground

40

for black background

41

for red background

42

for green background

43

for yellow (or brown) background

44

for blue background

45

for purple background

46

for cyan background

47

for white (or gray) background

### Escape sequences
To specify control or blank characters in the color sequences, C-style \-escaped notation can be used:

\a

Bell (ASCII 7)

\b

Backspace (ASCII 8)

\e

Escape (ASCII 27)

\f

Form feed (ASCII 12)

\n

Newline (ASCII 10)

\r

Carriage Return (ASCII 13)

\t

Tab (ASCII 9)

\v

Vertical Tab (ASCII 11)

\?

Delete (ASCII 127)

\_

Space

\\

Backslash (\)

\^

Caret (^)

\#

Hash mark (#)

Please note that escapes are necessary to enter a space, backslash, caret, or any control character anywhere in the string, as well as a hash mark as the first character.

For example, to use a red background for alert messages in the output of dmesg(1), use:

echo 'alert 37;41' >> /etc/terminal-colors.d/dmesg.scheme

### Comments
Lines where the first non-blank character is a # (hash) are ignored. Any other use of the hash character is not interpreted as introducing a comment.

## ENVIRONMENT
TERMINAL_COLORS_DEBUG=all

enables debug output.

## FILES
$XDG_CONFIG_HOME/terminal-colors.d

$HOME/.config/terminal-colors.d

/etc/terminal-colors.d

## EXAMPLE
Disable colors for all compatible utilities:

touch /etc/terminal-colors.d/disable

Disable colors for all compatible utils on a vt100 terminal:

touch /etc/terminal-colors.d/@vt100.disable

Disable colors for all compatible utils except dmesg(1):

touch /etc/terminal-colors.d/disable

touch /etc/terminal-colors.d/dmesg.enable

## COMPATIBILITY
The terminal-colors.d functionality is currently supported by all util-linux utilities which provides colorized output. For more details always see the COLORS section in the man page for the utility.

## REPORTING BUGS
For bug reports, use the issue tracker at <https://github.com/util-linux/util-linux/issues>.

## AVAILABILITY
terminal-colors.d is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.


utoprc

package: utop

title: utoprc(5)

summary: Configuration file of utop

text:
# utoprc(5)

## NAME
utoprc - Configuration file of utop

## SYNOPSIS
~/.utoprc

## DESCRIPTION
This manual page describes the format of the ~/.utoprc file. This is a text file which contains the configuration of utop. Comments start with a '!' and empty lines are ignored. Configuration lines are of the form:

<wildcard>: <value>

<wildcard> may contains the '*' star character. In that case any key which match the pattern is given the value after the colon.

The boolean key autoload can be set to false to disable the autoloading of files in $OCAML_TOPLEVEL_PATH/autoload at startup.

The key external-editor can be set to a command line. It is used to edit the input when pressing C-x C-e. It defaults to the contents of the EDITOR environment variable.

The key profile may have the value dark or light. This is the same as calling UTop.set_profile in ~/.config/utop/init.ml.

The following style keys are used by utop:

* identifier

* module

* comment

* doc

* constant

* keyword

* symbol

* string

* char

* quotation

* error

* directive

* parenthesis

* blanks

For each of these keys, the following sub-keys are used:

* key.foreground

* key.background

* key.bold

* key.underline

* key.reverse

* key.blink

key.foreground and key.background are colors, and the others are booleans. Colors may be one of the standard terminal colors:

* black

* red

* green

* yellow

* blue

* magenta

* cyan

* white

* light-black

* light-red

* light-green

* light-yellow

* light-blue

* light-magenta

* light-cyan

* light-white

or X11 colors, prefixed with "x-". For example:

identifier.foreground: x-goldenrod

Colors can also be given by their RGB components, written #RRGGBB. For example:

identifier.foreground: #5fbf7f

utop will choose the nearest color of the terminal when specifying a X11 color or a color given by its RGB components. If you are using gnome-terminal or konsole, you can enable 256 colors by setting the environment variable TERM to "xterm-256color".

## FILES
~/.utoprc

## EXAMPLE
profile: dark

identifier.foreground: none

comment.foreground: x-chocolate1

doc.foreground: x-light-salmon

constant.foreground: x-aquamarine

keyword.foreground: x-cyan1

symbol.foreground: x-cyan1

string.foreground: x-light-salmon

char.foreground: x-light-salmon

quotation.foreground: x-purple

error.foreground: x-red

parenthesis.background: blue

## AUTHOR
Jérémie Dimino <jeremie@dimino.org>

## SEE ALSO
utop(1).


vdr

package: vdr

title: vdr(5)

summary: the Video Disk Recorder Files

text:
# vdr(5)

## NAME
vdr_files - the Video Disk Recorder Files

## DESCRIPTION
This page describes the formats of the various files vdr uses to store configuration data and recordings.

## SYNTAX

### CHANNELS
The file channels.conf contains the channel configuration. Each line defines either a group delimiter or a channel.

A group delimiter is a line starting with a ':' as the very first character, followed by arbitrary text. Example:

:First group

Group delimiters may also be used to specify the number of the next channel. To do this, the character '@' and a number must immediately follow the ':', as in

:@201 First group

The given number must be larger than the number of any previous channel (otherwise it is silently ignored).

A group delimiter can also be used to just set the next channel's number, without an explicit delimiter text, as in

:@201

Such a delimiter will not appear in the Channels menu.

A channel definition is a line with channel data, where the fields are separated by ':' characters. Example:

RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0

The line number of a channel definition (not counting group separators, and based on a possible previous '@...' parameter) defines the channel's number in OSD menus and the timers.conf file.

The fields in a channel definition have the following meaning (from left to right):

Name

The channel's name (if the name originally contains a ':' character it has to be replaced by '|'). Some TV stations provide a way of deriving a "short name" from the channel name, which can be used in situations where there is not much space for displaying a long name. If a short name is available for this channel, it follows the full name and is delimited by a comma, as in RTL Television,RTL:...

If the short name itself would contain a comma, it is replaced with a '.'. Note that some long channel names may contain a comma, so the delimiting comma is always the rightmost one.

If present, the name of the service provider or "bouquet" is appended to the channel name, separated by a semicolon, as in

RTL Television,RTL;RTL World:...

Frequency

The transponder frequency (as an integer). For DVB-S this value is in MHz. For DVB-C and DVB-T it can be given either in MHz, kHz or Hz (the actual value given will be multiplied by 1000 until it is larger than 1000000).

Parameters

Various parameters, depending on whether this is a DVB-S, DVB-C or DVB-T channel. Each parameter consist of a key character, followed by an integer number that represents the actual setting of that parameter. The valid key characters, their meaning (and allowed values) are B

Bandwidth (1712, 5, 6, 7, 8, 10)

C

Code rate high priority (0, 12, 23, 34, 35, 45, 56, 67, 78, 89, 910)

D

coDe rate low priority (0, 12, 23, 34, 35, 45, 56, 67, 78, 89, 910)

G

Guard interval (4, 8, 16, 32, 128, 19128, 19256)

H

Horizontal polarization

I

Inversion (0, 1)

L

Left circular polarization

M

Modulation (2, 5, 6, 7, 10, 11, 12, 16, 32, 64, 128, 256, 999)

N

pilot mode (0, 1, 999)

O

rollOff (0, 20, 25, 35)

P

stream id (0-255)

Q

t2 system id (0-65535)

R

Right circular polarization

S

delivery System (0, 1)

T

Transmission mode (1, 2, 4, 8, 16, 32)

V

Vertical polarization

X

siso/miso mode (0, 1)

Y

hierarchY (0, 1, 2, 4)

Bandwidth: The bandwidth of the channel in MHz (1712 in kHz): (DVB-T/DVB-T2 only).

Code rate high priority: Forward Error Correction (FEC) of the high priority stream (DVB-T/DVB-T2). For DVB-S/DVB-S2 this parameter specifies the inner FEC scheme. 12 = 1/2, 23 = 2/3, 34 = 3/4, ...

Code rate low priority: Forward Error Correction (FEC) of the low priority stream (DVB-T/DVB-T2 only). If no hierarchy is used, set to 0.

Guard interval: The guard interval value (DVB-T only): 4 = 1/4, 8 = 1/8, 16 = 1/16, 32 = 1/32, 128 = 1/128, 19128 = 19/128, 19256 = 19/256.

Inversion: Specifies whether the DVB frontend needs spectral inversion (DVB-T and DVB-C only). This is frontend specific, if in doubt, omit.

Modulation: Specifies the modulation/constellation of the channel as follows:

2

QPSK (DVB-S, DVB-S2, DVB-T, DVB-T2, ISDB-T)

5

8PSK (DVB-S, DVB-S2)

6

16APSK (DVB-S2)

7

32APSK (DVB-S2)

10

VSB8 (ATSC aerial)

11

VSB16 (ATSC aerial)

12

DQPSK (ISDB-T)

16

QAM16 (DVB-T, DVB-T2, ISDB-T)

32

QAM32

64

QAM64 (DVB-C, DVB-T, DVB-T2, ISDB-T)

128

QAM128 (DVB-C)

256

QAM256 (DVB-C, DVB-T2)

Pilot mode: The pilot mode (0 = "off", 1 = "on", 999 = "auto") for DVB-S2 multiplex (DVB-S2 only).

Rolloff: The Nyquist filter rolloff factor for DVB-S (35) and DVB-S2 (35, 25, 20), 35 = 0.35, 25 = 0.25, 20 = 0.20, DVB-S/DVB-S2 default value is 0.35

Stream id: Input Stream Identifier (ISI) (0-255) for DVB-S2 multiplex or Physical Layer Pipe (PLP) id (0-255) for DVB-T2 multiplex (DVB-S2/DVB-T2 only, with devices that support "multi streaming").

T2 System id: Unique identifier (0-65535) of T2 system within the DVB network (DVB-T2).

Transmission mode: Number of DVB-T OFDM carriers, 32 = 32k, 16 = 16k, 8 = 8k, 4 = 4k, 2 = 2k, 1 = 1k. If in doubt, try 8k.

SISO/MISO mode: Specifies the Single-Input/Multiple-Input Single-Output mode (0 = SISO, 1 = MISO) (DVB-T2).

Hierarchy: If set to 1, this transponder uses two streams, high priority and low priority. If in doubt, try 0 (off). (DVB-T/DVB-T2 only).

Delivery System: The delivery system (0 = "first generation" (DVB-S/DVB-T), 1 = "second generation" (DVB-S2/DVB-T2).

Polarization: Satellite antenna polarization. H = horizontal, V = vertical, R = circular right, L = circular left.

The polarization parameters have no integer numbers following them. This is for compatibility with files from older versions and also to keep the DVB-S entries as simple as possible.

The special value 999 is used for "automatic", which means the driver will automatically determine the proper value (if possible).

An example of a parameter field for a DVB-T channel might look like this: B8C23D12G8M16T8Y0S0

An example of a parameter field for a DVB-T2 channel might look like this: B8C23D12G8M16T8Y0P0S1

An example of a parameter field for a DVB-C channel might look like this: C0M64

An example of a parameter field for a DVB-S channel might look like this: HC56M2O35S0

An example of a parameter field for a DVB-S2 channel might look like this: HC910M2O35S1

Plugins that implement devices that need their own set of parameters may store those in the parameters string in arbitrary format (not necessarily the "character/number" format listed above). The only condition is that the string may not contain colons (':') or newline characters.

Source

The signal source of this channel, as defined in the file sources.conf.

Srate

The symbol rate of this channel (DVB-S and DVB-C only).

VPID

The video PID (set to '0' for radio channels). If this channel uses a separate PCR PID, it follows the VPID, separated by a plus sign, as in ...:164+17:...

If this channel has a video mode other than 0, the mode follows the pids, separated by an '=' sign, as in

...:164+17=27:...

APID

The audio PID (either one number, or several, separated by commas). If this channel also carries Dolby Digital sound, the Dolby PIDs follow the audio PIDs, separated by a semicolon, as in ...:101,102;103,104:...

If certain audio PIDs broadcast in specific languages, the language codes for these can be appended to the individual audio or Dolby PID, separated by an '=' sign, as in

...:101=deu,102=eng;103=deu,104=eng:...

Some channels broadcast two different languages in the two stereo channels, which can be indicated by adding a second language code, delimited by a '+' sign, as in

...:101=deu,102=eng+spa;103=deu,104=eng:...

The audio type is appended with a separating '@' character, as in

...:101=deu@4,102=eng+spa@4,105=@4:...

Note that if there is no language code, there still is the separating '=' if there is an audio type.

TPID

The teletext PID. If this channel also carries DVB subtitles, the DVB subtitling PIDs follow the teletext PID, separated by a semicolon, as in ...:201;2001,2002:...

If certain subtitling PIDs broadcast in specific languages, the language codes for these can be appended to the individual subtitling PID, separated by an '=' sign, as in

...:201;2001=deu,2002=eng:...

Manual teletext subtitling pages can be defined separated by a '+' sign. The pages (separated by commas) can contain language codes, delimited by a '=' sign, as in

...:201+150=deu,151=fin;2001,2002:...

Conditional access

A hexadecimal integer defining how this channel can be accessed: 0000

Free To Air

0001...000F

explicitly requires the device with the given number

0010...00FF

reserved for user defined assignments

0100...FFFF

specific decryption methods as broadcast in the data stream

Values in the range 0001...00FF will not be overwritten, all other values will be automatically replaced by the actual CA system identifiers received from the data stream. If there is more than one CA system id broadcast, they will be separated by commas, as in ...:1702,1722,1801:...

The values are in hex because that's the way they are defined in the "ETR 162" document. Leading zeros may be omitted.

SID

The Service ID of this channel.

NID

The Network ID of this channel.

TID

The Transport stream ID of this channel.

RID

The Radio ID of this channel (typically 0, may be used to distinguish channels where NID, TID and SID are all equal).

A particular channel can be uniquely identified by its channel ID, which is a string that looks like this:

S19.2E-1-1089-12003-0

The components of this string are the Source (S19.2E), NID (1), TID (1089), SID (12003) and RID (0) as defined above. The last part can be omitted if it is 0, so the above example could also be written as S19.2E-1-1089-12003).

The channel ID is used in the timers.conf and epg.data files to properly identify the channels.

If a channel has both NID and TID set to 0, the channel ID will use the Frequency instead of the TID. For satellite channels an additional offset of 100000, 200000, 300000 or 400000 is added to that number, depending on the Polarization (H, V, L or R, respectively). This is necessary because on some satellites the same frequency is used for two different transponders, with opposite polarization.

### TIMERS
The file timers.conf contains the timer setup. Each line contains one timer definition, with individual fields separated by ':' characters. Example:

1:10:-T-----:2058:2150:50:5:Quarks & Co:

The fields in a timer definition have the following meaning (from left to right):

Flags

The individual bits in this field have the following meaning: 1

the timer is active (and will record if it hits)

2

this is an instant recording timer

4

this timer uses VPS

8

this timer is currently recording (may only be up-to-date with SVDRP)

All other bits are reserved for future use.

Channel

The channel to record from. This is either the channel number as shown in the on-screen menus, or a complete channel ID. When reading timers.conf any channel numbers will be mapped to the respective channel ids and when the file is written again, there will only be channel ids. Channel numbers are accepted as input in order to allow easier creation of timers when manually editing timers.conf. Also, when timers are listed via SVDRP commands, the channels are given as numbers.

Day

The day when this timer shall record. If this is a `single-shot' timer, this is the date on which this timer shall record, given in ISO notation (YYYY-MM-DD), as in:

2005-03-19

For compatibility with earlier versions of VDR this may also be just the day of month on which this timer shall record (must be in the range 1...31).

In case of a `repeating' timer this is a string consisting of exactly seven characters, where each character position corresponds to one day of the week (with Monday being the first day). The character '-' at a certain position means that the timer shall not record on that day. Any other character will cause the timer to record on that day. Example:

MTWTF--

will define a timer that records on Monday through Friday and does not record on weekends. Note that only letters may be used here, no digits. For compatibility with timers created with earlier versions of VDR, the same result could be achieved with ABCDE-- (which was used to allow setting the days with language specific characters). Since version 1.5.3 VDR can use UTF-8 characters to present data to the user, but the weekday encoding in the timers.conf file always uses single byte characters.

The day definition of a `repeating' timer may be followed by the date when that timer shall hit for the first time. The format for this is @YYYY-MM-DD, so a complete definition could look like this:

MTWTF--@2002-02-18

which would implement a timer that records Monday through Friday, and will hit for the first time on or after February 18, 2002. This first day feature can be used to disable a repeating timer for a couple of days, or for instance to define a new Mon...Fri timer on Wednesday, which actually starts "Monday next week". The first day date given need not be that of a day when the timer would actually hit.

Start

A four digit integer defining when this timer shall start recording. The format is hhmm, so 1430 would mean "half past two" in the afternoon.

Stop

A four digit integer defining when this timer shall stop recording. The format is the same as for the start time.

Priority

An integer in the range 0...99, defining the priority of this timer and of recordings created by this timer. 0 represents the lowest value, 99 the highest. The priority is used to decide which timer shall be started in case there are two or more timers with the exact same start time. The first timer in the list with the highest priority will be used. This value is also stored with the recording and is later used to decide which recording to remove from disk in order to free space for a new recording. If the disk runs full and a new recording needs more space, an existing recording with the lowest priority (and which has exceeded its guaranteed lifetime) will be removed.

If all available DVB cards are currently occupied, a timer with a higher priority will interrupt the timer with the lowest priority in order to start recording.

Lifetime

The guaranteed lifetime (in days) of a recording created by this timer. 0 means that this recording may be automatically deleted at any time by a new recording with higher priority. 99 means that this recording will never be automatically deleted. Any number in the range 1...98 means that this recording may not be automatically deleted in favour of a new recording, until the given number of days since the start time of the recording has passed by.

File

The file name this timer will give to a recording. If the name contains any ':' characters, these have to be replaced by '|'. If the name shall contain subdirectories, these have to be delimited by '~' (since the '/' character may be part of a regular programme name). The special keywords TITLE and EPISODE, if present, will be replaced by the title and episode information from the EPG data at the time of recording (if that data is available). If at the time of recording either of these cannot be determined, TITLE will default to the channel name, and EPISODE will default to a blank.

Auxiliary data

An arbitrary string that can be used by external applications to store any kind of data related to this timer. The string must not contain any newline characters. If this field is not empty, its contents will be written into the info file of the recording with the '@' tag.

### SOURCES
The file sources.conf defines the codes to be used in the Source field of channels in channels.conf and assigns descriptive texts to them. Example:

S19.2E Astra 1

Anything after (and including) a '#' character is comment.

The first character of the code must be one of

A

ATSC

C

Cable

S

Satellite

T

Terrestrial

and is followed by further data pertaining to that particular source. In case of Satellite this is the orbital position in degrees, followed by E for east or W for west. Plugins may define additional sources, using other characters in the range 'A'...'Z'.

### DISEQC
The file diseqc.conf defines the DiSEqC control sequences to be sent to the DVB-S card in order to access a given satellite position and/or band. Example:

S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t

Anything after (and including) a '#' character is comment.

The first word in a parameter line must be one of the codes defined in the file sources.conf and tells which satellite this line applies to.

Following is the "switch frequency" of the LNB (slof), which is the transponder frequency up to which this entry shall be used; the first entry with an slof greater than the actual transponder frequency will be used. Typically there is only one slof per LNB, but the syntax allows any number of frequency ranges to be defined. Note that there should be a last entry with the value 99999 for each satellite, which covers the upper frequency range.

The third parameter defines the polarization to which this entry applies. It can be either H for horizontal, V for vertical, L for circular left or R for circular right.

The fourth parameter specifies the "local oscillator frequency" (lof) of the LNB to use for the given frequency range. This number will be subtracted from the actual transponder frequency when tuning to the channel.

The rest of the line holds the actual sequence of DiSEqC actions to be taken. The code letters used here are

t

22kHz tone off

T

22kHz tone on

v

voltage low (13V)

V

voltage high (18V)

A

mini A

B

mini B

Pn

use positioner to move dish to satellite position n (or to the satellite's orbital position, if no position number is given)

Sn

Satellite channel routing code sequence for bank n follows

Wnn

wait nn milliseconds (nn may be any positive integer number)

[xx ...]

hex code sequence (max. 6)

There can be any number of actions in a line, including none at all - in which case the entry would be used only to set the LOF to use for the given frequency range and polarization. By default it is assumed that every DVB-S device can receive every satellite. If this is not the case in a particular setup, lines of the form

1 2 4:

may be inserted in the diseqc.conf file, defining the devices that are able to receive the satellites following thereafter. In this case, only the devices 1, 2 and 4 would be able to receive any satellites following this line and up to the next such line, or the end of the file. Devices may be listed more than once.

### SATELLITE CHANNEL ROUTING (SCR)
The file scr.conf contains the channel definitions of the SCR device in use. The format is

channel frequency [pin]

where channel is the SCR device's channel index (0-7), frequency is the user band frequency of the given channel, and pin is an optional pin number (0-255). The actual values are device specific and can be found in the SCR device's manual.

Examples:

0 1284

1 1400

2 1516

3 1632

4 1748

5 1864

6 1980

7 2096

By default it is assumed that the SCR configurations apply to all devices, and each device will pick one. If you have several SCR sat cables connected to one VDR machine, or if you want to explicitly assign the SCR channels to your devices, lines of the form

1 2 4:

may be inserted in the scr.conf file, defining the devices that are allowed to use the SCR channels thereafter. In this case, only the devices 1, 2 and 4 would be allowed to use the SCR channels following this line and up to the next such line, or the end of the file. If a device is listed more than once, only its first appearance counts.

### REMOTE CONTROL KEYS
The file remote.conf contains the key assignments for all remote control units. Each line consists of one key assignment in the following format:

name.key code

where name is the name of the remote control (for instance KBD for the PC keyboard, or LIRC for the "Linux Infrared Remote Control"), key is the name of the key that is defined (like Up, Down, Menu etc.), and code is a character string that this remote control delivers when the given key is pressed.

### KEY MACROS
The file keymacros.conf contains user defined macros that will be executed whenever the given key is pressed. The format is

macrokey [@plugin] key1 key2 key3...

where macrokey is the key that shall initiate execution of this macro and can be one of Up, Down, Ok, Back, Left, Right, Red, Green, Yellow, Blue, 0...9 or User1...User9. The rest of the line consists of a set of keys, which will be executed just as if they had been pressed in the given sequence. The optional @plugin can be used to automatically select the given plugin. plugin is the name of the plugin, exactly as given in the -P option when starting VDR. There can be only one @plugin per key macro. For instance

User1 @abc Down Down Ok

would call the main menu function of the "abc" plugin and execute two "Down" key presses, followed by "Ok".

Note that the color keys will only execute their macro function in "normal viewing" mode (i.e. when no other menu or player is active). The User1...User9 keys will always execute their macro function. There may be up to 15 keys in such a key sequence.

### FOLDERS
The file folders.conf contains the definitions of folders that can be used in the "Edit timer" menu. Each line contains one folder definition. Leading whitespace and everything after and including a '#' is ignored. A line ending with '{' defines a sub folder (i.e. a folder that contains other folders), and a line consisting of only '}' ends the definition of a sub folder.

Example:

Daily {

News

Soaps

}

Archive {

Movies

Sports

Sci-Fi {

Star Trek

U.F.O.

}

}

Comedy

Science

Note that these folder definitions are only used to set the file name under which a timer will store its recording. Changing these definitions in any way has no effect on existing timers or recordings.

### COMMANDS
The file commands.conf contains the definitions of commands that can be executed from the vdr main menu's "Commands" option. Each line contains one command definition in the following format:

title : command

where title is the string that will be displayed in the "Commands" menu, and command is the actual command string that will be executed when this option is selected. The delimiting ':' may be surrounded by any number of white space characters. If title ends with the character '?', there will be a confirmation prompt before actually executing the command. This can be used for commands that might have serious results (like deleting files etc) to make sure they are not executed inadvertently.

Everything following (and including) a '#' character is considered to be comment.

You can have nested layers of command menus by surrounding a sequence of commands with '{'...'}' and giving it a title, as in

My Commands {

First list {

Do something: some command

Do something else: another command

}

Second list {

Even more: yet another command

So much more: and yet another one

}

}

Command lists can be nested to any depth.

By default the menu entries in the "Commands" menu will be numbered '1'...'9' to make them selectable by pressing the corresponding number key. If you want to use your own numbering scheme (maybe to skip certain numbers), just precede the titles with the numbers of your choice. vdr will suppress its automatic numbering if the first entry in commands.conf starts with a digit in the range '1'...'9', followed by a blank.

In order to avoid error messages to the console, every command should have stderr redirected to stdout. Everything the command prints to stdout will be displayed in a result window, with title as its title.

Examples:

Check for new mail?: /usr/local/bin/checkmail 2>&1

CPU status: /usr/local/bin/cpustatus 2>&1

Disk space: df -h | grep '/video' | awk '{ print 100 - $5 "% free"; }'

Calendar: date;echo;cal

Note that the commands 'checkmail' and 'cpustatus' are only examples! Don't send emails to the author asking where to find these ;-)

The '?' at the end of the "Check for new mail?" entry will prompt the user whether this command shall really be executed.

### RECORDING COMMANDS
The file reccmds.conf can be used to define commands that can be applied to the currently highlighted recording in the "Recordings" menu. The syntax is exactly the same as described for the file commands.conf. When executing a command, the directory name of the recording will be appended to the command string, separated by a blank and enclosed in single quotes.

### SVDRP HOSTS
The file svdrphosts.conf contains the IP numbers of all hosts that are allowed to access the SVDRP port. Each line contains one IP number in the format

IP-Address[/Netmask]

where IP-Address is the address of a host or a network in the usual dot separated notation (as in 192.168.100.1). If the optional Netmask is given only the given number of bits of IP-Address are taken into account. This allows you to grant SVDRP access to all hosts of an entire network. Netmask can be any integer from 1 to 32. The special value of 0 is only accepted if the IP-Address is 0.0.0.0, because this will give access to any host (USE THIS WITH CARE!).

Everything following (and including) a '#' character is considered to be comment.

Examples:

127.0.0.1 # always accept localhost

192.168.100.0/24 # any host on the local net

204.152.189.113 # a specific host

0.0.0.0/0 # any host on any net (USE WITH CARE!)

### SETUP
The file setup.conf contains the basic configuration options for vdr. Each line contains one option in the format "Name = Value". See the MANUAL file for a description of the available options.

### THEMES
The files themes/<skin>-<theme>.theme in the config directory contain the color theme definitions for the various skins. In the actual file names <skin> will be replaced by the name if the skin this theme belongs to, and <theme> will be the name of this theme. Each line in a theme file contains one option in the format "Name = Value". Anything after (and including) a '#' character is comment.

The definitions in a theme file are either colors or a description.

Colors are in the form

clrTitle = FF123456

where the name (clrTitle) is one of the names defined in the source code of the skin that uses this theme, through the THEME_CLR() macro. The value (FF123456) is an eight digit hex number that consist of four bytes, representing alpha (transparency), red, green and blue component of the color. An alpha value of 00 means the color will be completely transparent, while FF means it will be opaque. An RGB value of 000000 results in black, while FFFFFF is white.

A description can be given as

Description = Shades of blue

and will be used in the Setup/OSD menu to select a theme for a given skin. The description should give the user an idea what this theme will be like (for instance, in the given example it would use various shades of blue), and shouldn't be too long to make sure it fits on the Setup screen. The default description always should be given in English. If you want, you can provide language specific descriptions as

Description.eng = Shades of blue

Description.ger = Blautöne

where the language code is added to the keyword "Description", separated by a dot. You can enter as many language specific descriptions as you like, but only those that have a corresponding locale messages file will be actually used. If a theme file doesn't contain a Description, the name of the theme (as given in the theme's file name) will be used.

### AUDIO/VIDEO DATA
The files 00001.ts...65535.ts are the actual recorded data files. In order to keep the size of an individual file below a given limit, a recording may be split into several files. The contents of these files is Transport Stream (TS) and contains data packets that are each 188 byte long and start with 0x47. Data is stored exactly as it is broadcast, with a generated PAT/PMT inserted right before every independent frame.

### INDEX
The file index (if present in a recording directory) contains the (binary) index data into each of the the recording files 00001.ts...65535.ts. It is used during replay to determine the current position within the recording, and to implement skipping and fast forward/back functions. See the definition of the cIndexFile class for details about the actual contents of this file.

### INFO
The file info (if present in a recording directory) contains a description of the recording, derived from the EPG data at recording time (if such data was available). The Aux field of the corresponding timer (if given) is copied into this file, using the '@' tag. This is a plain ASCII file and contains tagged lines like the EPG DATA file (see the description of the epg.data file). Note that the lowercase tags ('c' and 'e') will not appear in an info file. Lines tagged with '#' are ignored and can be used by external tools to store arbitrary information.

In addition to the tags used in the epg.data file, the following tag characters are defined:

F

<frame rate>

L

<lifetime>

P

<priority>

@

<auxiliary data>

### RESUME
The file resume (if present in a recording directory) contains the position within the recording where the last replay session left off. The file consists of tagged lines that describe the various parameters necessary to pick up replay where it left off.

The following tag characters are defined:

I

<offset into the file index>

### MARKS
The file marks (if present in a recording directory) contains the editing marks defined for this recording. Each line contains the definition of one mark in the following format:

hh:mm:ss.ff comment

where hh:mm:ss.ff is a frame position within the recording, given as "hours, minutes, seconds and (optional) frame number". comment can be any string and may be used to describe this mark. If present, comment must be separated from the frame position by at least one blank.

The lines in this file need not necessarily appear in the correct temporal sequence, they will be automatically sorted by time index.

If a frame position doesn't point to an I-frame of the corresponding recording, it will be shifted towards the next I-frame (either up or down, whichever is closer).

CURRENT RESTRICTIONS:

- the comment is currently not used by VDR

### EPG DATA
The file epg.data contains the EPG data in an easily parsable format. The first character of each line defines what kind of data this line contains.

The following tag characters are defined:

C

<channel id> <channel name>

E

<event id> <start time> <duration> <table id> <version>

T

<title>

S

<short text>

D

<description>

G

<genre> <genre>...

R

<parental rating>

X

<stream> <type> <language> <descr>

V

<vps time>

e

c

Lowercase characters mark the end of a sequence that was started by the corresponding uppercase character. The outer frame consists of a sequence of one or more C...c (Channel) entries. Inside these any number of E...e (Event) entries are allowed. All other tags are optional (although every event should at least have a T entry).

There may be several X tags, depending on the number of tracks (video, audio etc.) the event provides.

<channel id>

is the "channel ID", made up from the parameters defined in 'channels.conf'

<channel name>

is the "name" as in 'channels.conf' (for information only, may be left out)

<event id>

is a 32 bit unsigned int, uniquely identifying this event

<start time>

is the time (as a time_t integer) in UTC when this event starts

<duration>

is the time (in seconds) that this event will take

<table id>

is a hex number that indicates the table this event is contained in (if this is left empty it will be set to 0x00; and value less than 0x4E it will be treated as if it were 0x4E)

<version>

is a hex number that indicates the event's version number inside its table (optional, ignored when reading EPG data)

<title>

is the title of the event

<short text>

is the short text of the event (typically the name of the episode etc.)

<description>

is the description of the event (any '|' characters will be interpreted as newlines)

<genre>

is a two digit hex code, as defined in ETSI EN 300 468, table 28 (up to 4 genre codes are supported)

<parental rating>

is the minimum age of the intended audience

<stream>

is the stream content (1 = MPEG2 video, 2 = MP2 audio, 3 = subtitles, 4 = AC3 audio, 5 = H.264 video, 6 = HEAAC audio)

<type>

is the stream type according to ETSI EN 300 468

<language>

is the three letter language code (optionally two codes, separated by '+')

<descr>

is the description of this stream component

<vps time>

is the Video Programming Service time of this event

This file will be read at program startup in order to restore the results of previous EPG scans.

Note that the event id that comes from the DVB data stream is actually just 16 bit wide. The internal representation in VDR allows for 32 bit to be used, so that external tools can generate EPG data that is guaranteed not to collide with the ids of existing data.

### COMMANDLINE OPTIONS
If started without any options, vdr tries to read any files in the directory /etc/vdr/conf.d with names that do not begin with a '.' and that end with '.conf'. These files are read in alphabetical order. The format of these files is

\# comment

[name]

-a

-b 123

--long

--longarg=123

Any lines that begin with '#' as the first non-whitespace character are considered comments and are ignored. A command line option file consists of one or more sections, indicated by '[name]', where 'name' is either the fixed word 'vdr' (if this section contains options for the main VDR program) or the name of the plugin this section applies to. Each option must be written on a separate line, including the leading '-' (for a short option) or '--' (for a long option). If the option has additional arguments, they have to be written on the same line as the option itself, separated from the option with a blank (short option) or equal sign (long option).

## SEE ALSO
vdr(1)

## AUTHOR
Written by Klaus Schmidinger.

## REPORTING BUGS
Report bugs to <vdr-bugs@tvdr.de>.

## COPYRIGHT
Copyright © 2013 Klaus Schmidinger.

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


crontab

package: vixie-cron

title: crontab(5)

summary: tables for driving cron

text:
# crontab(5)

## NAME
crontab — tables for driving cron

## DESCRIPTION
A crontab file contains instructions to the cron(8) daemon of the general form: “at these times on these dates run this command”. There may be a system crontab (/etc/crontab) and each user may have their own crontab (/var/spool/cron/<user>). Commands in any given crontab will be executed either as the user who owns the crontab or, in the case of the system crontab, as the user specified in the command line. Uucp and News will usually each have their own crontab, eliminating the need for explicitly running su(1) as part of a cron(8) command.

While a crontab is a text file, it is not intended to be directly edited. Creation, modification, and removal of a crontab should be done using crontab(1).

Blank lines, leading spaces, and tabs are ignored. Lines whose first non-space character is a pound sign (‘#’) are comments, and are ignored. Note that comments are not allowed on the same line as cron(8) commands, since they will be taken to be part of the command. Similarly, comments are not allowed on the same line as environment variable settings.

An active line in a crontab is either an environment variable setting or a cron(8) command.

Environment Variable Settings

Environment variable settings create the environment any command in the crontab is run in. An environment variable setting is of the form:

name = value

where the spaces around the equal-sign (‘=’) are optional, and any subsequent non-leading spaces in value will be part of the value assigned to name. The value string may be placed in quotes (single or double, but matching) to preserve leading or trailing blanks.

Several environment variables are set automatically by the cron(8) daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab's owner. HOME and SHELL may be overridden by settings in the crontab; LOGNAME may not.

Note: on BSD systems the LOGNAME variable is sometimes called USER. On OpenBSD, cron(8) will set both USER and LOGNAME to the same value.

In addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if it has any reason to send mail as a result of running commands in “this” crontab. If MAILTO is defined (and non-empty), mail is sent to the user so named. If MAILTO is defined but empty (MAILTO = ‘’), no mail will be sent. Otherwise mail is sent to the owner of the crontab. This option is useful for pseudo-users that lack an alias that would otherwise redirect the mail to a real person.

The MLS_LEVEL environment variable provides support for multiple per-job SELinux security contexts in the same crontab. By default, cron jobs execute with the default SELinux security context of the user that created the crontab file. When using multiple security levels and roles, this may not be sufficient, because the same user may be running in a different role or at a different security level. For more about roles and SELinux MLS/MCS see selinux(8) and undermentioned crontab example. You can set MLS_LEVEL to the SELinux security context string specifying the SELinux security context in which you want the job to run, and crond will set the execution context of the or jobs to which the setting applies to the specified context. See also the crontab(1) -s option.

cron Commands

The format of a cron(8) command is very much the V7 standard, with a number of upward-compatible extensions. Lines in the system crontab have six fixed fields plus a command in the form:

minute hour day-of-month month day-of-week user command

While lines in a user crontab have five fixed fields plus a command in the form:

minute hour day-of-month month day-of-week command

Fields are separated by blanks or tabs. The command may be one or more fields long. The allowed values for the fields are:

field

allowed values

-----

--------------

minute

* or 0-59

hour

* or 0-23

day-of-month

* or 1-31

month

* or 1-12 or a name (see below)

day-of-week

* or 0-7 or a name (0 or 7 is Sunday)

user

a valid username

command

text

Lists are allowed. A list is a set of numbers (or ranges) separated by commas. Examples: “1,2,5,9”,“0-4,8-12”.

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. The specified range is inclusive. For example, 8-11 for an hour entry specifies execution at hours 8, 9, 10 and 11.

Step values can be used in conjunction with ranges. Following a range with /number specifies skips of number through the range. For example, “0-23/2” can be used in the hour field to specify command execution every other hour (the alternative in the V7 standard is “0,2,4,6,8,10,12,14,16,18,20,22”). Steps are also permitted after an asterisk, so if you want to say “every two hours”, just use “*/2”.

An asterisk (‘*’) is short form for a range of all allowed values.

Names can be used in the month and day-of-week fields. Use the first three letters of the particular day or month (case doesn't matter). Ranges or lists of names are not allowed.

The command field (the rest of the line) is the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by /bin/sh or by the shell specified in the SHELL variable of the crontab. Percent signs (‘%’) in the command, unless escaped with a backslash (‘\’), will be changed into newline characters, and all data after the first ‘%’ will be sent to the command as standard input.

Commands are executed by cron(8) when the minute, hour, and month fields match the current time, and when at least one of the two day fields (day-of-month or day-of-week, see Note below) match the current time. cron(8) examines crontab entries once every minute.

Note: The day of a command's execution can be specified by two fields — day-of-month and day-of-week. If both fields are restricted (i.e., aren't *), the command will be run when either field matches the current time. For example,

30 4 1,15 * 5

would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.

Instead of the first five fields, one of eight special strings may appear:

string

meaning

------

-------

@reboot

Run once, at cron(8) startup.

@yearly

Run every January 1, "0 0 1 1 *".

@annually

(same as @yearly).

@monthly

Run the first day of every month, "0 0 1 * *".

@weekly

Run every Sunday, "0 0 * * 0".

@daily

Run every midnight, "0 0 * * *".

@midnight

(same as @daily).

@hourly

Run every hour, on the hour, "0 * * * *".

## EXAMPLES

```
# use /bin/sh to run commands, no matter what /etc/passwd says
SHELL=/bin/sh
# mail any output to `paul', no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * *       $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
# run at 2:15pm on the first of every month -- output mailed to paul
15 14 1 * *     $HOME/bin/monthly
# run at 10 pm on weekdays, annoy Joe
0 22 * * 1-5	mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
5 4 * * sun     echo "run at 5 after 4 every sunday"
```

## SELinux with multi level security (MLS)
In crontab is important specified security level by crontab -s or specifying the required level on the first line of the crontab. Each level is specified in /etc/selinux/targeted/seusers. For using crontab in MLS mode is really important:

- check/change actual role,

- set correct role for directory, which is used for input/output.

## EXAMPLE FOR SELINUX MLS

```
# login as root
newrole -r sysadm_r
mkdir /tmp/SystemHigh
chcon -l SystemHigh /tmp/SystemHigh
crontab -e
# write in crontab file
MLS_LEVEL=SystemHigh
0-59 * * * * id -Z > /tmp/SystemHigh/crontest
When I log in as a normal user, it can't work, because /tmp/SystemHigh is
higher than my level.
```

## SEE ALSO
crontab(1), cron(8)

## EXTENSIONS
When specifying day-of-week, both day 0 and day 7 will be considered Sunday. BSD and ATT seem to disagree about this.

Lists and ranges are allowed to coexist in the same field. “1-3,7-9” would be rejected by ATT or BSD cron — they want to see “1-3” or “7,8,9” only.

Ranges can include “steps”, so “1-9/2” is the same as “1,3,5,7,9”.

Months or days of the week can be specified by name.

Environment variables can be set in the crontab. In BSD or ATT, the environment handed to child processes is basically the one from /etc/rc.

Command output is mailed to the crontab owner (BSD can't do this), can be mailed to a person other than the crontab owner (SysV can't do this), or the feature can be turned off and no mail will be sent at all (SysV can't do this either).

All of the ‘@’ commands that can appear in place of the first five fields are extensions.

## AUTHORS
Paul Vixie ⟨vixie@isc.org⟩


vnstat.conf

package: vnstat

title: vnstat.conf(5)

summary: vnStat configuration file

text:
# vnstat.conf(5)

## NAME
vnstat.conf - vnStat configuration file

## SYNOPSIS
/etc/vnstat.conf

## DESCRIPTION
vnstat(1), vnstati(1) and vnstatd(8) all use the same configuration file for configuration related settings. Some of the settings are common for all three programs. The file consists of keyword-argument pairs, one per line. Empty lines and lines starting with '#' are interpreted as comments and not processed. Arguments may optionally be enclosed in double quotes (") in order to represent arguments containing spaces. Arguments can be padded with spaces or tabulator characters. A hardcoded default value will be used if a keyword can't be found from the configuration file or if the configured value cannot be parsed or is outside supported value range.

The configuration file is divided into three sections based on the usage of each keyword. The first section contains keywords that are considered common for all commands, the second section is for daemon related keywords and the last section is for image output.

## COMMON KEYWORDS
DatabaseDir

Specifies the directory where the database is to be stored. A full path must be given and a leading '/' isn't required.

DayFormat, MonthFormat, TopFormat

Formatting of date in available outputs. Uses the same format as date(1). (vnstat and vnstati only)

DefaultDecimals

Number of decimals to use in outputs. Value range: 0..2 (vnstat and vnstati only)

EstimateBarVisible

Show a visual representation of the traffic estimation if OutputStyle has been configured with a value of 1 or 2 to make the bar column visible. 1 = enabled, 0 = disabled. (vnstat only, see EstimateStyle for vnstati)

HourlyDecimals

Number of decimals to use in hourly graph output. Value range: 0..2 (vnstat only)

HourlySectionStyle

Select what kind of spacer is used for separating the numerical sections of the hourly graph output. 0 = none, 1 = '|', 2 = '][', 3 = '[ ]'. (vnstat only)

Interface

Default interface used when no other interface is specified on the command line. Leave empty for automatic selection. The automatic selection will prioritize the interface with most traffic for outputs doing database queries. Queries not using the database will first check if the database is available and select the interface with most traffic out those that are currently visible in the system. If no database can be read then the first available interface will be used. (vnstat and vnstati only)

List5Mins, ListHours, ListDays, ListMonths, ListYears, ListTop

Number of entries to show in list outputs unless overridden from the command line. Set to 0 to show all entries available in the database. (vnstat and vnstati)

Locale

Locale setting to be used for prints. This replaces the LC_ALL environment variable. Set to "-" or leave empty in order to use the system default value. (vnstat and vnstati only)

OutputStyle

Modify the content and style of text outputs. 0 = minimal and narrow output for terminal with limited width, 1 = normal output with bar column visible, 2 = same as 1 except rate is visible in summary output, 3 = rate column is visible in all outputs where it is supported. (vnstat and vnstati only)

QueryMode

Default query mode when no parameters are given. 0 = normal, 1 = days, 2 = months, 3 = top, 5 = short, 6 = years, 7 = hours graph, 8 = xml, 9 = one line, 10 = json, 11 = hours and 12 = 5 minute. (vnstat only)

RateUnit

Select which unit is used when traffic rate is visible. 0 = bytes, 1 = bits. (vnstat and vnstati only)

RateUnitMode

Select used prefix when traffic rate is shown in bits per second. IEC binary prefixes are calculated with powers of 1024. SI decimal prefixes are calculated with powers of 1000. 0 = IEC binary prefixes (Kibit/s...), 1 = SI decimal prefixes (kbit/s...). (vnstat and vnstati only)

RXCharacter, TXCharacter

Character used for representing the percentual share of received and transmitted traffic in list mode outputs. (vnstat only)

RXHourCharacter, TXHourCharacter

Character used for representing the percentual share of received and transmitted traffic in hourly graph output. (vnstat only)

Sampletime

Defines how many seconds the -tr option will sample traffic. Value range: 2..600 (vnstat only)

UnitMode

Select how units are prefixed. IEC and JEDEC binary prefixes are calculated with powers of 1024. SI decimal prefixes are calculated with powers of 1000. 0 = IEC standard prefixes (B/KiB/MiB/GiB...), 1 = old style (JEDEC) binary prefixes (B/KB/MB/GB...), 2 = SI decimals prefixes (B/kB/MB/GB...) (vnstat and vnstati only)

## DAEMON RELATED KEYWORDS
5MinuteHours

Data retention duration for the 5 minute resolution entries. The configuration defines for how many past hours entries will be stored. Set to -1 for unlimited entries or to 0 to disable the data collection of this resolution.

64bitInterfaceCounters

Select interface counter handling. Set to 1 for defining that all interfaces use 64-bit counters on the kernel side and 0 for defining 32-bit counter. Set to -1 for using the old style logic used in earlier versions where counter values within 32-bits are assumed to be 32-bit and anything larger is assumed to be a 64-bit counter. This may produce false results if a 64-bit counter is reset within the 32-bits. Set to -2 for using automatic detection based on available kernel datastructures.

BandwidthDetection

Try to automatically detect MaxBandwidth value for each monitored interface. Mostly only ethernet interfaces support this feature. MaxBandwidth or interface specific MaxBW will be used as fallback value if detection fails. 1 = enabled, 0 = disabled.

BandwidthDetectionInterval

How often in minutes interface specific detection of MaxBandwidth is done for detecting possible changes when BandwidthDetection is enabled. Can be disabled by setting to 0. Value range: 0..30

BootVariation

Time in seconds how much the boot time reported by system kernel can variate between updates. Value range: 0..300

CheckDiskSpace

Enable or disable the availability check of at least some free disk space before a database write. 1 = enabled, 0 = disabled.

CreateDirs

Enable or disable the creation of directories when a configured path doesn't exist. This includes DatabaseDir , LogFile and PidFile directories. The LogFile directory will be created only when UseLogging has been set to 1. The PidFile directory will be created only if the daemon is started as a background process. The daemon process will try to create the directory using permissions of the user used to start the process.

DaemonGroup

Specify the group to which the daemon process should switch during startup. The group can either be the name of the group or a numerical group id. Leave empty to disable group switching. This option can only be used when the process is started as root.

DaemonUser

Specify the user to which the daemon process should switch during startup. The user can either be the login of the user or a numerical user id. Leave empty to disable user switching. This option can only be used when the process is started as root.

DailyDays

Data retention duration for the one day resolution entries. The configuration defines for how many past days entries will be stored. Set to -1 for unlimited entries or to 0 to disable the data collection of this resolution.

DatabaseSynchronous

Change the setting of the SQLite "synchronous" flag which controls how much care is taken to ensure disk writes have fully completed when writing data to the database before continuing other actions. Higher values take extra steps to ensure data safety at the cost of slower performance. A value of 0 will result in all handling being left to the filesystem itself. Set to -1 to select the default value according to database mode controlled by DatabaseWriteAheadLogging setting. See SQLite documentation for more details regarding values from 1 to 3. Value range: -1..3

DatabaseWriteAheadLogging

Enable or disable SQLite Write-Ahead Logging mode for the database. See SQLite documentation for more details and note that support for read-only operations isn't available in older SQLite versions. 1 = enabled, 0 = disabled.

HourlyDays

Data retention duration for the one hour resolution entries. The configuration defines for how many past days entries will be stored. Set to -1 for unlimited entries or to 0 to disable the data collection of this resolution.

LogFile

Specify log file path and name to be used if UseLogging is set to 1.

MaxBandwidth

Maximum bandwidth for all interfaces. If the interface specific traffic exceeds the given value then the data is assumed to be invalid and rejected. Set to 0 in order to disable the feature. Value range: 0..50000

MaxBW

Same as MaxBandwidth but can be used for setting individual limits for selected interfaces. The name of the interface is specified directly after the MaxBW keyword without spaces. For example MaxBWeth0 for eth0 and MaxBWppp0 for ppp0. Value range: 0..50000

MonthlyMonths

Data retention duration for the one month resolution entries. The configuration defines for how many past months entries will be stored. Set to -1 for unlimited entries or to 0 to disable the data collection of this resolution.

MonthRotate

Day of month that months are expected to change. Usually set to 1 but can be set to alternative values for example for tracking monthly billed traffic where the billing period doesn't start on the first day. For example, if set to 7, days of February up to and including the 6th will count for January. Changing this option will not cause existing data to be recalculated. Value range: 1..28

MonthRotateAffectsYears

Enable or disable MonthRotate also affecting yearly data. Applicable only when MonthRotate has a value greater than one. 1 = enabled, 0 = disabled.

OfflineSaveInterval

How often in minutes cached interface data is saved to file when all monitored interfaces are offline. Value range: SaveInterval..60

PidFile

Specify pid file path and name to be used. The file is created only if the daemon is started as a background process.

PollInterval

How often in seconds interfaces are checked for status changes. Value range: 2..60

SaveInterval

How often in minutes cached interface data is saved to file. Value range: ( UpdateInterval / 60 )..60

SaveOnStatusChange

Enable or disable the additional saving to file of cached interface data when the availability of an interface changes, i.e., when an interface goes offline or comes online. 1 = enabled, 0 = disabled.

TimeSyncWait

How many minutes to wait during daemon startup for system clock to sync if most recent database update appears to be in the future. This may be needed in systems without a real-time clock (RTC) which require some time after boot to query and set the correct time. 0 = wait disabled. Value range: 0..60

TopDayEntries

Data retention duration for the top day entries. The configuration defines how many of the past top day entries will be stored. Set to -1 for unlimited entries or to 0 to disable the data collection of this resolution.

TrafficlessEntries

Create database entries even when there is no traffic during the entry's time period. 1 = enabled, 0 = disabled.

UpdateFileOwner

Enable or disable the update of file ownership during daemon process startup. During daemon startup, only database, log and pid files will be modified if the user or group change feature ( DaemonUser or DaemonGroup ) is enabled and the files don't match the requested user or group. During manual database creation, this option will cause file ownership to be inherited from the database directory if the directory already exists. This option only has effect when the process is started as root or via sudo.

UpdateInterval

How often in seconds the interface data is updated. Value range: PollInterval..300

UseLogging

Enable or disable logging. 0 = disabled, 1 = logfile and 2 = syslog.

YearlyYears

Data retention duration for the one year resolution entries. The configuration defines for how many past years entries will be stored. Set to -1 for unlimited entries or to 0 to disable the data collection of this resolution.

## IMAGE OUTPUT RELATED KEYWORDS
5MinuteGraphResultCount

Number of 5 minute periods to be included in the 5 minute resolution graph. The value affects the width of the graph. Value range: 288..5MinuteHours*12

5MinuteGraphHeight

Height of 5 minute resolution graph in pixels. Value range: 150..2000

BarColumnShowsRate

The bar column represents traffic rate in list outputs when enabled. Requires also that OutputStyle has been configured to show the traffic rate column by using the value 3. Enabling this option will automatically cause EstimateStyle to have the value 0. Visually this option affects only the color legend text and the last line on the list if that line represents the currently ongoing time period. 1 = enabled, 0 = disabled.

CBackground

Background color.

CEdge

Edge color, if visible.

CHeader

Header background color.

CHeaderTitle

Header title text color.

CHeaderDate

Header date text color.

CLine

Line color.

CLineL

Lighter version of line color. Set to '-' in order to use a calculated value based on CLine.

CRx

Color for received data.

CRxD

Darker version of received data color. Set to '-' in order to use a calculated value based on CRx.

CText

Common text color.

CTx

Color for transmitted data.

CTxD

Darker version of transmitted data color. Set to '-' in order to use a calculated value based on CTx.

EstimateStyle

Show a visual representation of the traffic estimation. 0 = not shown, 1 = continuation of existing bar, 2 = separate bar.

HeaderFormat

Formatting of date in header. Uses the same format as date(1).

HourlyRate

Show hours with rate instead of transferred amount. 1 = enabled, 0 = disabled.

ImageScale

Scale output to given percent. Value range: 50..500

LargeFonts

Increase the size of used fonts. 1 = enabled, 0 = disabled.

LineSpacingAdjustment

Adjust line spacing in list format outputs. Positive values increase the space between lines while negative values reduce it. Value range: -5..10

SummaryGraph

Select which graph style output is shown next to the summary data in the horizontal and vertical summary outputs. 0 = hours, 1 = 5 minutes.

SummaryRate

Show rate in summary output if available. 1 = enabled, 0 = disabled.

TransparentBg

Set background color as transparent. 1 = enabled, 0 = disabled.

## FILES
/etc/vnstat.conf

Config file that will be used unless $HOME/.vnstatrc exists or alternative value is given as command line parameter.

## RESTRICTIONS
Using long date output formats may cause misalignment in shown columns if the length of the date exceeds the fixed size allocation.

## AUTHOR
Teemu Toivola <tst at iki dot fi>

## SEE ALSO
vnstat(1), vnstati(1), vnstatd(8), units(7)


vomsdir

package: voms-clients-java

title: vomsdir(5)

text:
# vomsdir(5)

## NAME
vomsdir - The structure of the vomsdir VOMS server trust anchor directory

## SYNOPSIS
/etc/grid-security/vomsdir

## DESCRIPTION
This manual page describes the structure of the vomsdir VOMS server trust anchor directory. The function of this directory is to keep local information about trusted VOMS servers which is used to verify the signatures on the attributes issued by VOMS servers.

The vomsdir directory is structured as follows:

```
<vomsdir>

   |

   |--vo1

   |

   |--vo2

   |

   |--vo3

   |
```

A subdirectory is created for each of the trusted VOs. Inside each VO directory two types of files can be found:

• LSC files An LSC file contains a description of the certificate chain of the certificate used by a VOMS server to sign VOMS attributes.

• X509 certificates The certificate used by a VOMS server to sign attributes.

These files are commonly named using the following pattern:

```
<hostname>.lsc
<hostname>.pem
```

Where hostname is the host where the VOMS server is running.

When both lsc and pem files are present for a given VO and hostname, the lsc file takes precedence.

### LSC file syntax
The LSC file contains a list of X.509 subject strings, one on each line, encoded in OpenSSL slash-separated syntax, describing the certificate chain (up and including the CA that issued the certificate). For instance, the voms.cnaf.infn.it VOMS server has the following LSC file:

```
/C=IT/O=INFN/OU=Host/L=CNAF/CN=voms.cnaf.infn.it
/C=IT/O=INFN/CN=INFN CA
```

## EXAMPLES
Assuming locally two VOs are trusted, the cms VO and the cdf VO, the /etc/grid-security/vomsdir directory will be structured as follows:

```
/etc/grid-security/vomsdir
/etc/grid-security/vomsdir/cms
/etc/grid-security/vomsdir/cdf
```

The /etc/grid-security/vomsdir/cms directory will contain the following files:

```
lcg-voms.cern.ch.lsc
voms.cern.ch.lsc
```

The /etc/grid-security/vomsdir/cdf directory will contain the following files:

```
voms-01.pd.infn.it.lsc
voms.cnaf.infn.it.lsc
voms.fnal.gov.lsc
```

The LSC files will contain descriptions of the certificate chains used by VOMS servers to sign attribute certificates.

## BUGS
To report bugs or ask for support, use GGUS: https://ggus.eu/pages/home.php

## AUTHORS
Andrea Ceccanti <andrea.ceccanti@cnaf.infn.it>

Daniele Andreotti <daniele.andreotti@cnaf.infn.it>

Valerio Venturi <valerio.venturi@cnaf.infn.it>

## SEE ALSO
voms-proxy-destroy(1), voms-proxy-info(1), voms-lsc(5)

## COPYING
Copyright 2012 Istituto Nazionale di Fisica Nucleare

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

```
http://www.apache.org/licenses/LICENSE-2.0
```

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.


vomses

title: vomses(5)

summary: The VOMS server contact table

text:
# vomses(5)

## NAME
vomses - The VOMS server contact table

## SYNOPSIS
/etc/vomses

~/.glite/vomses

## DESCRIPTION
This manual page describes the format of vomses files. vomses files contain contact information for VOMS servers and are typically organized in the /etc/vomses directory. A vomses file is a simple text file which contains one or more lines formatted as follows:

"alias" "hostname" "port" "server DN" "vo_name"

Where:

alias: an alias that can be used for this VOMS server (this is typically identical to the vo_name)

hostname: the hostname where the VOMS server is running

vo_name: the name of the VO served by the VOMS server

port: the port where the VOMS server is listening for incoming requests

server DN: the certificate subject of the VOMS server

System wide VOMSES configuration is maintained in the /etc/vomses file or directory. If /etc/vomses is a directory, all the files contained in such directory are parsed looking for VOMS contact information.

A user can define its custom vomses configuration in the ~/.glite/vomses file or directory, which will be parsed in the same way as just described.

## EXAMPLES
The following is an example of valid vomes file for the cms VO:

```
"cms" "lcg-voms.cern.ch" "15002" "/DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch" "cms"
"cms" "voms.cern.ch" "15002" "/DC=ch/DC=cern/OU=computers/CN=voms.cern.ch" "cms"
```

## BUGS
To report bugs or ask for support, use GGUS: https://ggus.eu/pages/home.php

## AUTHORS
Andrea Ceccanti <andrea.ceccanti@cnaf.infn.it>

Daniele Andreotti <daniele.andreotti@cnaf.infn.it>

Valerio Venturi <valerio.venturi@cnaf.infn.it>

## SEE ALSO
voms-proxy-destroy(1), voms-proxy-info(1), vomsdir(5)

## COPYING
Copyright 2012 Istituto Nazionale di Fisica Nucleare

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

```
http://www.apache.org/licenses/LICENSE-2.0
```

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.