mairixrc

package: mairix

title: mairixrc(5)

summary: configuration file for mairix(1)

text:
# mairixrc(5)

## NAME
mairixrc - configuration file for mairix(1)

## SYNOPSIS
$HOME/.mairixrc

## DESCRIPTION
The mairixrc file tells mairix where your mail folders are located. It also tells mairix where the results of searches are to be written.

mairix searches for this file at $HOME/.mairixrc unless the -f option is used.

The directives base, mfolder, and database must always appear in the file. There must also be some folder definitions (using the maildir, mh, or mbox) directives.

### Comments
Any line starting with a '#' character is treated as a comment.

### Directives
base=base-directory

This defines the path to the common parent directory of all your maildir folders.

imap_server=hostname

If any IMAP source folders are specified or the results folder is an IMAP folder, this defines the host name of the IMAP server. The port is currently always 143. This option is mutually exclusive with the

imap_pipe=shell-command

If any IMAP source folders are specified or the results folder is an IMAP folder, this defines a shell command that can be used to connect to the IMAP server and talk to it over UNIX pipes instead of a TCP/IP connection. This option is mutually exclusive with the 'imap_server' option.

imap_username=username

If any IMAP source folders are specified or the results folder is an IMAP folder, this defines the user name to use to log in to the IMAP server. This parameter is optional, but IMAP servers normally require clients to log in, so it is normally necessary to specify it. One example of a case where it is not required is if the 'imap_pipe' option is in use the the shell command established a connection with an IMAP server in pre-autenticated state.

imap_password=password

If any IMAP source folders are specified or the results folder is an IMAP folder, this defines the password to use to log in to the IMAP server. This parameter is optional, but IMAP servers normally require clients to log in, so it is normally necessary to specify it.

maildir=list-of-folder-specifications

This is a colon-separated list of the Maildir folders (relative to `base') that you want indexed. Any entry that ends `...' is recursively scanned to find any Maildir folders underneath it. More than one line starting with `maildir' can be included. In this case, mairix joins the lines together with colons as though a single list of folders had been given on a single very long line.

Each colon-separated entry may be a wildcard. See the discussion under mbox (below) for the wildcard syntax. For example

```
maildir=zzz/foo*...
```

```

```

will match maildir folders like these (relative to the base-directory)

```
zzz/foobar/xyz
zzz/fooquux
zzz/foo
zzz/fooabc/u/v/w
```

```

```

and

```
maildir=zzz/foo[abc]*
```

```

```

will match maildir folders like these (relative to the folder_base)

```
zzz/fooa
zzz/fooaaaxyz
zzz/foobcd
zzz/fooccccccc
```

```

```

If a folder name contains a colon, you can write this by using the sequence '\:' to escape the colon. Otherwise, the backslash character is treated normally. (If the folder name actually contains the sequence '\:', you're out of luck.)

mh=list-of-folder-specifications

This is a colon-separated list of the MH folders (relative to `base') that you want indexed. Any entry that ends '...' is recursively scanned to find any MH folders underneath it. More than one line starting with 'mh' can be included. In this case, mairix joins the lines together with colons as though a single list of folders had been given on a single very long line.

Each colon-separated entry may be a wildcard, see the discussion under maildir (above) and mbox (below) for the syntax and semantics of specifying wildcards.

mairix recognizes the types of MH folders created by the following email applications:

- xmh

- sylpheed

- claws-mail

- evolution

- NNML

- Mew

mbox=list-of-folder-specifications

This is a colon-separated list of the mbox folders (relative to `base') that you want indexed. Each colon-separated item in the list can be suffixed by '...'. If the item matches a regular file, that file is treated as a mbox folder and the '...' suffix is ignored. If the item matches a directory, a recursive scan of everything inside that directory is made, and all regular files are initially considered as mbox folders. (Any directories found in this scan are themselves scanned, since the scan is recursive.)

Each colon-separated item may contain wildcard operators, but only in its final path component. The wildcard operators currently supported are

*

Match zero or more characters (each character matched is arbitrary)

?

Match exactly one arbitrary character

[abcs-z]

Character class : match a single character from the set a, b, c, s, t, u, v, w, x, y and z. To include a literal ']' in the class, place it immediately after the opening '['. To include a literal '-' in the class, place it immediately before the closing ']'.

If these metacharacters are included in non-final path components, they have no special meaning.

Here are some examples

mbox=foo/bar*

matches 'foo/bar', 'foo/bar1', 'foo/barrrr' etc

mbox=foo*/bar*

matches 'foo*/bar', 'foo*/bar1', 'foo*/barrrr' etc

mbox=foo/*

matches 'foo/bar', 'foo/bar1', 'foo/barrrr', 'foo/foo', ´foo/x' etc

mbox=foo...

matches any regular file in the tree rooted at 'foo'

mbox=foo/*...

same as before

mbox=foo/[a-z]*...

matches 'foo/a', 'foo/aardvark/xxx', 'foo/zzz/foobar', ´foo/w/x/y/zzz', but not 'foo/A/foobar' Regular files that are mbox folder candidates are examined internally. Only files containing standard mbox 'From ' separator lines will be scanned for messages.

If a regular file has a name ending in '.gz', and gzip support is compiled into the mairix binary, the file will be treated as a gzipped mbox.

If a regular file has a name ending in '.bz2', and bzip support is compiled into the mairix binary, the file will be treated as a bzip2'd mbox.

More than one line starting with 'mbox' can be included. In this case, mairix joins the lines together with colons as though a single list of folders had been given on a single very long line.

mairix performs no locking of mbox folders when it is accessing them. If a mail delivery program is modifying the mbox at the same time, it is likely that one or messages in the mbox will never get indexed by mairix (until the database is removed and recreated from scratch, anyway.) The assumption is that mairix will be used to index archive folders rather than incoming ones, so this is unlikely to be much of a problem in reality.

mairix can support a maximum of 65536 separate mboxes, and a maximum of 65536 messages within any one mbox.

imap=list-of-folders

This is a colon-separated list of the IMAP folders that you want indexed. These folders must all be located on the same account on the same IMAP server. The configuration options imap_server and imap_pipe specify how to connect to the IMAP server.

More than one line starting with 'imap' can be included. In this case, mairix joins the lines together with colons as though a single list of folders had been given on a single very long line.

omit=list-of-glob-patterns

This is a colon-separated list of glob patterns for folders to be omitted from the indexing. This allows wide wildcards and recursive elements to be used in the maildir,mh, andmbox directives, with the omit option used to selectively remove unwanted folders from the folder lists. Within the glob patterns, a single '*' matches any sequence of characters other than '/'. However '**' matches any sequence of characters including '/'. This allows glob patterns to be constructed which have a wildcard for just one directory component, or for any number of directory components.

The _omit_ option can be specified as many times as required so that the list of patterns doesn't all have to fit on one line.

As an example,

```
mbox=bulk...
omit=bulk/spam*
```

```

```

will index all mbox folders at any level under the 'bulk' subdirectory of the base folder, except for those folders whose names start 'bulk/spam', e.g. 'bulk/spam', 'bulk/spam2005' etc. In constrast,

```
mbox=bulk...
omit=bulk/spam**
```

```

```

will index all mbox folders at any level under the 'bulk' subdirectory of the base folder, except for those folders whose names start 'bulk/spam', e.g. 'bulk/spam', 'bulk/spam2005', ´bulk/spam/2005', 'bulk/spam/2005/jan' etc.

nochecks

This takes no arguments. If a line starting with nochecks is present, it is the equivalent of specifying the -Q flag to every indexing run.

mfolder=match-folder-name

This defines the name of the folder (within the directory specified by base) into which the search mode writes its output. (If the mformat used is 'raw' or 'excerpt', then this setting is not used and may be omitted.) The mfolder setting may be over-ridden for a particular search by using the -o option to mairix.

mairix will refuse to output search results to a folder that appears to be amongst those that are indexed. This is to prevent accidental deletion of emails.

If the first character of the mfolder value is '/' or '.', it is taken as a pathname in its own right. This allows you to specify absolute paths and paths relative to the current directory where the mfolder should be written. Otherwise, the value of mfolder is appended to the value of base, in the same way as for the source folders.

mformat=format

This defines the type of folder used for the match folder where the search results go. There are six valid settings for format, namely 'maildir', 'mh', 'mbox', 'imap', 'raw', or 'excerpt'. If the 'raw' setting is used then mairix will just print out the path names of the files that match and no match folder will be created. If the 'excerpt' setting is used, mairix will also print out the To:, Cc:, From:, Subject: and Date: headers of the matching messages. 'maildir' is the default if this option is not defined. The setting is case-insensitive.

database=path-to-database

This defines the path where mairix's index database is kept. You can keep this file anywhere you like. Currently, mairix will place a single database file at the location indicated by path-to-database. However, a future version of mairix may instead place a directory containing several files at this location.

path-to-database should be an absolute pathname (starting with '/'). If a relative pathname is used, it will be interpreted relative to the current directory at the time mairix is run, (not relative to the location of the mairixrc file or anything like that.)

follow_mbox_symlinks

This takes no arguments. By default, mairix will skip symlinks to mboxes when indexing. If a line starting with follow_mbox_symlinks is present, mairix will follow them instead of skipping them.

### Expansions
The part of each line in '.mairixrc' following the equals sign can contain the following types of expansion:

Home directory expansion

If the sequence '~/' appears at the start of the text after the equals sign, it is expanded to the user's home directory. Example:

```
database=~/Mail/mairix_database
```

```

```

Environment expansion

If a '$' is followed by a sequence of alpha-numeric characters (or ´_'), the whole string is replaced by looking up the corresponding environment variable. Similarly, if '$' is followed by an open brace ('{'), everything up to the next close brace is looked up as an environment variable and the result replaces the entire sequence. Suppose in the shell we do

```
export FOO=bar
```

```

```

and the '.mairixrc' file contains

```
maildir=xxx/$FOO
mbox=yyy/a${FOO}b
```

```

```

this is equivalent to

```
maildir=xxx/bar
mbox=yyy/abarb
```

```

```

If the specified environment variable is not set, the replacement is the empty string.

## NOTES
An alternative path to the configuration file may be given with the -f option to mairix(1).


makedumpfile.conf

package: makedumpfile

title: makedumpfile.conf(5)

text:
# makedumpfile.conf(5)

## NAME
makedumpfile.conf - The filter configuration file for makedumpfile(8).

## DESCRIPTION
The makedumpfile.conf is a configuration file for makedumpfile tool. makedumpfile.conf file contains the erase commands to filter out desired kernel data from the vmcore while creating DUMPFILE using makedumpfile tool. makedumpfile reads the filter config and builds the list of memory addresses and its sizes after processing filter commands. The memory locations that require to be filtered out are then poisoned with character X (58 in Hex).

## FILE FORMAT
The file consists of module sections that contains filter commands. A section begins with the name of the section in square brackets and continues until the next section begins.

"["<ModuleName>"]"

<FilterCommands>

where

"[" is the character [

"]" is the character ]

<ModuleName>

is either 'vmlinux' or name of a Linux kernel module.

<FilterCommands>

is a list of one or more filter commands as described in the section FILTER COMMANDS of this manual page.

The section name indicates a kernel module name (including vmlinux) where the symbols specified in subsequent erase commands belong to. The unnamed section defaults to [vmlinux] section. However, a user can also explicitly define [vmlinux] section. The sections help makedumpfile tool to select appropriate kernel or module debuginfo file before processing the subsequent erase commands. Before selecting appropriate debuginfo file, the module name is validated against the loaded modules from the vmcore. If no match is found, then the section is ignored and makedumpfile skips to the next module section. If match is found, then makedumpfile will try to load the corresponding module debuginfo file. If module debuginfo is not available then, makedumpfile will skip the section with a warning message.

## FILTER COMMANDS

### filter command
A filter command is either an erase command or a loop construct. Each erase command and loop construct must start with a new line. Each filter command describes data in the dump to be erased. Syntax:

<EraseCommands>|<LoopConstruct>

where

<EraseCommands>

Described in the subsection erase command of this manual page.

<LoopConstruct>

Described in the subsection Loop construct of this manual page.

### erase command
Erase specified size of a kernel data referred by specified kernel/module symbol or its member component. The erase command syntax is:

erase <Symbol>[.member[...]] [size <SizeValue>[K|M]]

erase <Symbol>[.member[...]] [size <SizeSymbol>]

erase <Symbol>[.member[...]] [nullify]

where

<Symbol>

A kernel or module symbol (variable) name that is part of global symbols /proc/kallsyms.

<SizeValue>

A positive integer value as a size of the data in bytes to be erased. The suffixes 'K' and 'M' can be used to specify kilobytes and Megabytes respectively where, K means 1024 bytes and M means 1024 ^ 2 = 1048576 bytes. The suffixes are not case sensitive.

<SizeSymbol>

A simple expression of the form <Symbol>[.member[...]] that denotes a symbol which contains a positive integer value as a size of the data in bytes to be erased.

<Symbol>[.member[...]]

A simple expression that results into either a global kernel symbol name or its member components. The expression always uses '.' operator to specify the member component of kernel symbol or its member irrespective of whether it is of pointer type or not.

member[...]

Member or component of member in <Symbol>.

The erase command takes two arguments 1. kernel symbol name or its member components and 2. size of the data referred by argument (1) OR nullify keyword. The second argument size OR nullify is optional. The unit for size value is in bytes. If size option is not specified then the size of the first argument is determined according to its data type using dwarf info from debuginfo file. In case of 'char *' data type, the length of string pointed by 'char *' pointer is determined with an upper limit of 1024. The size can be specified in two forms 1. a integer value as explained above (<SizeValue>) and 2. a simple expression in the form of <Symbol>[.member[...]]] that results into base type (integer) variable.

If the specified <Symbol> is of type 'void *', then user needs to provide either size or nullify option, otherwise the erase command will not have any effect.

The nullify option only works if specified <Symbol> is a pointer. Instead of erasing data pointed by the specified pointer nullify erases the pointer value and set it to '0' (NULL). Please note that by nullifying the pointer values may affect the debug ability of created DUMPFILE. Use the nullify option only when the size of data to be erased is not known. e.g. data pointed by 'void *'.

Let us look at the makedumpfile.conf file from the example below which was configured to erase desired kernel data from the kernel module with name mymodule. At line 1 and 3, the user has not specified size option while erasing 'array_var' and 'mystruct1.name' symbols. Instead the user depends on makedumpfile to automatically determine the sizes to be erased i.e 100 bytes for 'array_var' and 11 bytes for 'mystruct1.name'. At line 2, while erasing the 'mystruct1.buffer' member the user has specified the size value 25 against the actual size of 50. In this case the user specified size takes the precedence and makedumpfile erases only 25 bytes from ´mystruct1.buffer'. At line 4, the size of the data pointed by void * pointer 'mystruct1.addr' is unknown. Hence the nullify option has been specified to reset the pointer value to NULL. At line 5, the ´mystruct2.addr_size' is specified as size argument to determine the size of the data pointed by void * pointer 'mystruct2.addr'.

Example:

Assuming the following piece of code is from kernel module 'mymodule':

struct s1 {

char *name;

void *addr1;

void *addr2;

char buffer[50];

};

struct s2 {

void *addr;

long addr_size;

};

/* Global symbols */

char array_var[100];

struct s1 mystruct1;

struct s2 *mystruct2;

int foo()

{

...

s1.name = "Hello World";

...

}

makedumpfile.conf:

[mymodule]

erase array_var

erase mystruct1.buffer size 25

erase mystruct1.name

erase mystruct1.addr1 nullify

\# Assuming addr2 points to 1024 bytes

erase mystruct1.addr2 size 1K

erase mystruct2.addr size mystruct2.addr_size

EOF

### Loop construct
A Loop construct allows the user to traverse the linked list or array elements and erase the data contents referred by each element.

for <id> in {<ArrayVar> |

<StructVar> via <NextMember> |

<ListHeadVar> within <StructName>:<ListHeadMember>}

erase <id>[.MemberExpression] [size <SizeExpression>|nullify]

[erase <id>...]

[...]

endfor

where

<id>

Arbitrary name used to temporarily point to elements of the list. This is also called iteration variable.

<ArrayVar>

A simple expression in the form of <Symbol>[.member[...]] that results into an array variable.

<StructVar>

A simple expression in the form of <Symbol>[.member[...]] that results into a variable that points to a structure.

<NextMember>

Member within <StructVar> that points to an object of same type that of <StructVar>.

<ListHeadVar>

A simple expression in the form of <Symbol>[.member[...]] that results into a variable of type struct list_head.

<StructName>

Name of the structure type that can be traversed using HEAD variable <ListHeadVar> and contains a member named <ListHeadMember>.

<ListHeadMember>

Name of a member in <StructName>, of type struct list_head.

<MemberExpression>

A simple expression in the form of [.member[...]] to specify a member or component of an element in <ArrayVar>, <StructVar> or <StructName>.

<SizeExpression>

Size value in the form of <SizeValue>, <id>[.MemberExpression] or <Symbol>[.member[...]].

The for loop construct allows to iterate on list of elements in an array or linked lists. Each element in the list is assigned to iteration variable <id>. The type of the iteration variable is determined by that of the list elements. The entry specified after 'in' terminal is called LIST entry. The LIST entry can be an array variable, structure variable/pointer or a struct list_head type variable. The set of erase commands specified between for and endfor, will be executed for each element in the LIST entry.

If the LIST entry specified is an array variable, then the loop will be executed for each array element. The size of the array will be determined by using dwarf information.

If the LIST entry specified is a structure variable/pointer, then a traversal member (<NextMember>) must be specified using 'via' terminal. The for loop will continue until the value of traversal member is NULL or matches with address of the first node <StructVar> if it is a circular linked list.

If the LIST entry is specified using a struct list_head type variable, then within terminal must be used to specify the structure name <StructName> that is surrounding to it along with the struct list_head type member after ':' which is part of the linked list. In the erase statement <id> then denotes the structure that the list_head is contained in (ELEMENT_OF).

The below example illustrates how to use loop construct for traversing Array, linked list via next member and list_head.

Example:

Assuming following piece of code is from kernel module 'mymodule':

struct s1 {

struct *next;

struct list_head list;

char private[100];

void *key;

long key_size;

};

/* Global symbols */

struct s1 mystruct1;

static LIST_HEAD(s1_list_head);

struct s1 myarray[100];

void foo()

{

struct s1 *s1_ptr;

...

...

s1_ptr = malloc(...);

...

...

list_add(&s1_ptr->list, &s1_list_head);

...

}

makedumpfile.conf:

[mymodule]

\# erase private fields from list starting with mystruct1 connected via

\# 'next' member:

for mys1 in mystruct1 via next

erase mys1.private

erase mys1.key size mys1.key_size

endfor

\# erase private fields from list starting with list_head variable

\# s1_list_head.

for mys1 in s1_list_head.next within s1:list

erase mys1.private

erase mys1.key size mys1.key_size

endfor

\# erase private fields from all elements of the array myarray:

for mys1 in myarray

erase mys1.private

erase mys1.key size mys1.key_size

endfor

EOF

In the above example, the first for construct traverses the linked list through a specified structure variable mystruct1 of type struct s1. The linked list can be traversed using 'next' member of mystruct1. Hence a via terminal has been used to specify the traversal member name 'next'.

The second for construct traverses the linked list through a specified struct list_head variable s1_list_head.next. The global symbol s1_list_head is a start address of the linked list and its next member points to the address of struct list_head type member 'list' from struct s1. Hence a within terminal is used to specify the structure name 's1' that can be traversed using s1_list_head.next variable along with the name of struct list_head type member 'list' which is part of the linked list that starts from s1_list_head global symbol.

The third for construct traverses the array elements specified through a array variable myarray.

## SEE ALSO
makedumpfile(8)


texinfo

package: makeinfo

title: texinfo(5)

summary: software documentation system

text:
# texinfo(5)

## NAME
texinfo - software documentation system

## DESCRIPTION
Texinfo is a documentation system that uses a single source file to produce both online information and printed output. It is primarily designed for writing software manuals.

For a full description of the Texinfo language and associated tools, please see the Texinfo manual (written in Texinfo itself). Most likely, running this command from your shell:

```
info texinfo
```

or this key sequence from inside Emacs:

```
M-x info RET m texinfo RET
```

will get you there.

## AVAILABILITY
http://www.gnu.org/software/texinfo/

or any GNU mirror site.

## REPORTING BUGS
Please send bug reports to bug-texinfo@gnu.org, general questions and discussion to help-texinfo@gnu.org.

## SEE ALSO
info(1), install-info(1), makeinfo(1), texi2dvi(1), texindex(1).

emacs(1), tex(1).

info(5).


mako

package: mako

title: mako(5)

text:
# mako(5)

## NAME
mako - configuration file

## DESCRIPTION
The config file is located at ~/.config/mako/config or at $XDG_CONFIG_HOME/mako/config. Option lines can be specified to configure mako like so:

key=value

Empty lines and lines that begin with # are ignored.

## GLOBAL CONFIGURATION OPTIONS
max-history=n

Set maximum number of expired notifications to keep in the history buffer to n. If the buffer is full, newly expired notifications replace the oldest ones. If 0, history is disabled. Default: 5

sort=+/-time | +/-priority

Sorts incoming notifications by time and/or priority in ascending(+) or descending(-) order. Default: -time

## BINDING OPTIONS
Bindings allow one to perform an action when an event is triggered. Supported values are none, dismiss, dismiss-all, dismiss-group, invoke-action <action>, invoke-default-action and exec <command>.

on-button-left=action

Default: invoke-default-action

on-button-middle=action

Default: none

on-button-right=action

Default: dismiss

on-touch=action

Default: dismiss

on-notify = action

Default: none

When exec is used, the command will be executed in a POSIX shell. The shell variable id will be set to the notification ID. For example, the following option will display an interactive action menu on middle click:

```
on-button-middle=exec makoctl menu -n "$id" dmenu -p 'Select action: '
```

The following option will play a sound when a new notification is opened:

```
on-notify=exec mpv /usr/share/sounds/freedesktop/stereo/message.oga
```

When using invoke-action or invoke-default-action a xdg-activation token will be sent to the client, allowing the client to request focus from the compositor. The compositor must support the xdg_activation_v1 protocol and allow the focus request for the example to work correctly:

```
[app-name="some-app-id" actionable]
on-button-left=invoke-action mail-reply-sender
```

## STYLE OPTIONS
font=font

Set font to font, in Pango format. Default: monospace 10

background-color=color

Set background color to color. See COLORS for more information. Default: #285577FF

text-color=color

Set text color to color. See COLORS for more information. Default: #FFFFFFFF

width=px

Set width of notification popups. Default: 300

height=px

Set maximum height of notification popups. Notifications whose text takes up less space are shrunk to fit. Default: 100

outer-margin=directional

Set outer-margin of each edge to the size specified by directional. See DIRECTIONAL VALUES for more information. This margin applies to the outside of the whole notification list. Default: 0

margin=directional

Set margin of each edge to the size specified by directional. See DIRECTIONAL VALUES for more information. This margin applies to each individual notification. Note that it applies in addition to outer-margin, meaning first and last notifications will use the sum of both margins. Default: 10

padding=directional

Set padding on each side to the size specified by directional. See DIRECTIONAL VALUES for more information. Default: 5

border-size=px

Set popup border size to px pixels. Default: 2

border-color=color

Set popup border color to color. See COLORS for more information. Default: #4C7899FF

border-radius=px

Set popup corner radius to px pixels. Default: 0

progress-color=[over|source] color

Set popup progress indicator color to color. See COLOR for more information. To draw the progress indicator on top of the background color, use the over attribute. To replace the background color, use the source attribute (this can be useful when the notification is semi-transparent). Progress can be indicated in a notification by setting a hint, "value" to an integer between 0 and 100 inclusive.

Default: over #5588AAFF

icons=0|1

Show icons in notifications. Default: 1

max-icon-size=px

Set maximum icon size to px pixels. Default: 64

icon-path=path[:path...]

Paths to search for icons when a notification specifies a name instead of a full path. Colon-delimited. This approximates the search algorithm used by the XDG Icon Theme Specification, but does not support any of the theme metadata. Therefore, if you want to search parent themes, you'll need to add them to the path manually. The path should be the root of the icon theme, the categories and resolutions will be searched for the most appropriate match.

/usr/share/icons/hicolor and /usr/share/pixmaps are always searched.

Default: ""

icon-location=position

Position of the icon relative to the displayed text. Valid options are left, right, top and bottom. Default: left

markup=0|1

If 1, enable Pango markup. If 0, disable Pango markup. If enabled, Pango markup will be interpreted in your format specifier and in the body of notifications. Default: 1

actions=0|1

Applications may request an action to be associated with activating a notification. Disabling this will cause mako to ignore these requests. Default: 1

history=0|1

If set, mako will save notifications that have reached their timeout into the history buffer instead of immediately deleting them. max-history determines the size of the history buffer. Default: 1

format=format

Set notification format string to format. See FORMAT SPECIFIERS for more information. To change this for grouped notifications, set it within a grouped criteria. Default: %s\n%b

Default when grouped: (%g) %s\n%b

text-alignment=left|center|right

Set notification text alignment. Default: left

default-timeout=timeout

Set the default timeout to timeout in milliseconds. To disable the timeout, set it to zero. Default: 0

ignore-timeout=0|1

If set, mako will ignore the expire timeout sent by notifications and use the one provided by default-timeout instead. Default: 0

group-by=field[,field,...]

A comma-separated list of criteria fields that will be compared to other visible notifications to determine if this one should form a group with them. All listed criteria must be exactly equal for two notifications to group. Default: none

max-visible=n

Set maximum number of visible notifications to n. Older notifications will be hidden. If -1, all notifications are visible. Default: 5

output=name

Show notifications on the specified output. If empty, notifications will appear on the focused output. Requires the compositor to support the Wayland protocol xdg-output-unstable-v1 version 2.

Default: ""

layer=layer

Arrange mako at the specified layer, relative to normal windows. Supported values are background, bottom, top, and overlay. Using overlay will cause notifications to be displayed above fullscreen windows, though this may also occur at top depending on your compositor. Default: top

anchor=position

Show notifications at the specified position on the output. Supported values are top-right, top-center, top-left, bottom-right, bottom-center, bottom-left, center-right, center-left and center. Default: top-right

## CRITERIA
In addition to the set of options at the top of the file, the config file may contain zero or more sections, each containing any combination of the BINDING OPTIONS and STYLE OPTIONS. The sections, called criteria, are defined with an INI-like square bracket syntax. The brackets may contain any number of fields, like so:

[field=value field2=value2 ...]

When a notification is received, it will be compared to the fields defined in each criteria. If all of the fields match, the style options within will be applied to the notification. Fields not included in the criteria are not considered during the match. A notification may match any number of criteria. This matching occurs in the order the criteria are defined in the config file, meaning that if multiple criteria match a notification, the last occurrence of any given style option will "win".

The following fields are available in criteria:

•app-name (string)

•app-icon (string)

•summary (string)

•An exact match on the summary of the notification.

•This field conflicts with summary~.

•summary~ (string)

•A POSIX extended regular expression match on the summary of the notification.

•This field conflicts with summary.

•body (string)

•An exact match on the body of the notification.

•This field conflicts with body~.

•body~ (string)

•A POSIX extended regular expression match on the body of the

notification. •This field conflicts with body.

•urgency (one of "low", "normal", "critical")

•category (string)

•desktop-entry (string)

•actionable (boolean)

•expiring (boolean)

•mode (string)

•Only apply style options in this section if the provided mode is currently enabled. For more information about modes, see the MODES section.

The following fields are also available to match on a second pass based on where previous style options decided to place each notification:

•grouped (boolean)

•Whether the notification is grouped with any others (its group-index is not -1).

•group-index (int)

•The notification's index within its group, or -1 if it is not grouped.

•hidden (boolean)

•hidden is special, it defines the style for the placeholder shown when the number of notifications or groups exceeds max-visible.

•output (string)

- Which output the notification was sorted onto. See the output style option for possible values.

•anchor (string)

•Which position on the output the notification was assigned to. See the

anchor style option for possible values.

There are only two passes performed on each notification, so the second-pass criteria are not allowed to reposition the notification.

If a field's value contains special characters, they may be escaped with a backslash, or quoted:

[app-name="Google Chrome"] [app-name=Google\ Chrome]

Quotes within quotes may also be escaped, and a literal backslash may be specified as \\. No spaces are allowed around the equal sign. Escaping equal signs within values is unnecessary.

Additionally, boolean values may be specified using any of true/false, 0/1, or as bare words:

[actionable=true] [actionable=1] [actionable] [actionable=false] [actionable=0] [!actionable]

There are three criteria always present at the front of the list:

•An empty criteria which matches all notifications and contains the defaults for all style options, overwritten with any configured in the global section.

•[grouped], which sets the default format for grouped notifications and sets them invisible.

•[group-index=0], which makes the first member of each group visible again.

These options can be overridden by simply defining the criteria yourself and overriding them.

There are some rules restricting what can be configured depending on what is being matched by a given criteria:

•Criteria matching grouped or group-index are not allowed to change the anchor, output, or group-by, as this would invalidate the grouping. Grouping is only performed once rather than recursively, to avoid the potential for infinite loops.

## CRITERIA-ONLY STYLE OPTIONS
Some style options are not useful in the global context and therefore have no associated command-line option.

invisible=0|1

Whether this notification should be invisible even if it is above the max-visible cutoff. This is used primarily for hiding members of groups. If you want to make more than the first group member visible, turn this option off within a group-index criteria. Default: 0

## COLORS
Colors can be specified as #RRGGBB or #RRGGBBAA.

## DIRECTIONAL VALUES
Some options set values that affect all four edges of a notification. These options can be specified in several different ways, depending on how much control over each edge is desired:

•A single value will apply to all four edges.

•Two values will set vertical and horizontal edges separately.

•Three will set top, horizontal, and bottom edges separately.

•Four will set top, right, bottom, and left edges separately.

When specifying multiple values, they should be comma-separated. For example, this would set the top margin to 10, left and right to 20, and bottom to five:

```
margin = 10,20,5
```

## FORMAT SPECIFIERS
Format specification works similarly to printf(3), but with a different set of specifiers.

%% Literal "%"

\\ Literal "\"

\n New Line

### For notifications
%a Application name

%s Notification summary

%b Notification body

%g Number of notifications in the current group

%i Notification id

### For the hidden notifications placeholder
%h Number of hidden notifications

%t Total number of notifications

## MODES
mako supports applying style options conditionally via modes. A configuration section with a mode criteria will only be applied if the current mode matches. makoctl(1) can be used to change the current mode.

The initial list of modes contains a single mode called "default". This is deprecated, in a future version the initial list of modes will be empty.

For example, to hide all notifications if the mode "do-not-disturb" is enabled:

```
[mode=do-not-disturb]
invisible=1
```

makoctl mode -a do-not-disturb will hide all notifications, makoctl mode -r do-not-disturb will show them again.

## AUTHORS
Maintained by Simon Ser <contact@emersion.fr>, who is assisted by other open-source contributors. For more information about mako development, see https://github.com/emersion/mako.

## SEE ALSO
mako(1) makoctl(1)


manpath

package: man-db

title: manpath(5)

summary: format of the /etc/man_db.conf file

text:
# manpath(5)

## NAME
manpath - format of the /etc/man_db.conf file

## DESCRIPTION
The manpath configuration file is used by the manual page utilities to assess users' manpaths at run time, to indicate which manual page hierarchies (manpaths) are to be treated as system hierarchies and to assign them directories to be used for storing cat files.

If the environment variable $MANPATH is already set, the information contained within /etc/man_db.conf will not override it.

## SEARCH PATH
By default, man-db examines the user's $PATH. For each path_element found there, it adds manpath_element to the search path.

If there is no MANPATH_MAP line in the configuration file for a given path_element, then it adds all of path_element/../man, path_element/man, path_element/../share/man, and path_element/share/man that exist as directories to the search path.

It then adds any MANDATORY_MANPATH entries from the configuration file to the search path.

Finally, if the --systems option is used or the $SYSTEM environment variable is set, then that should consist of a sequence of operating system names separated by commas or colons. This acts as a template, expanding the search path once more to allow access to other operating systems' manual pages: for each system name, man-db looks for that name as a subdirectory of each entry in the search path, and adds it to the final search path if it exists. A system name of man inserts the normal search path without subdirectories. For example, if the search path would otherwise have been /usr/share/man:/usr/local/man, and $SYSTEM is set to newOS:man, then the final search path will be /usr/share/man/newOS:/usr/share/man:/usr/local/man/newOS:/usr/local/man.

The $MANPATH environment variable overrides man-db's default manual page search paths. Most users should not need to set it. Its syntax is similar to the $PATH environment variable: it consists of a sequence of directory names separated by colons. It overrides the default search path described above.

If the value of $MANPATH starts with a colon, then the default search path is added at its start. If the value of $MANPATH ends with a colon, then the default search path is added at its end. If the value of $MANPATH contains a double colon (::), then the default search path is inserted in the middle of the value, between the two colons.

## FORMAT
The following field types are currently recognised:

\# comment

Blank lines or those beginning with a # will be treated as comments and ignored.

MANDATORY_MANPATH manpath_element

Lines of this form indicate manpaths that every automatically generated $MANPATH should contain. This will typically include /usr/man.

MANPATH_MAP path_element manpath_element

Lines of this form set up $PATH to $MANPATH mappings. For each path_element found in the user's $PATH, manpath_element will be added to the $MANPATH.

MANDB_MAP manpath_element [ catpath_element ]

Lines of this form indicate which manpaths are to be treated as system manpaths, and optionally where their cat files should be stored. This field type is particularly important if man is a setuid program, as (when in the system configuration file /etc/man_db.conf rather than the per-user configuration file .manpath) it indicates which manual page hierarchies to access as the setuid user and which as the invoking user. The system manual page hierarchies are usually those stored under /usr such as /usr/man, /usr/local/man and /usr/X11R6/man.

If cat pages from a particular manpath_element are not to be stored or are to be stored in the traditional location, catpath_element may be omitted.

Traditional cat placement would be impossible for read only mounted manual page hierarchies and because of this it is possible to specify any valid directory hierarchy for their storage. To observe the Linux FSSTND the keyword FSSTND can be used in place of an actual directory.

Unfortunately, it is necessary to specify all system man tree paths, including alternate operating system paths such as /usr/man/sun and any NLS locale paths such as /usr/man/de_DE.88591.

As the information is parsed line by line in the order written, it is necessary for any manpath that is a sub-hierarchy of another hierarchy to be listed first, otherwise an incorrect match will be made. An example is that /usr/man/de_DE.88591 must come before /usr/man.

DEFINE key value

Lines of this form define miscellaneous configuration variables; see the default configuration file for those variables used by the manual pager utilities. They include default paths to various programs (such as grep and tbl), and default sets of arguments to those programs.

SECTION section ...

Lines of this form define the order in which manual sections should be searched. If there are no SECTION directives in the configuration file, the default is:

```
SECTION 1 n l 8 3 0 2 3type 5 4 9 6 7
```

If multiple SECTION directives are given, their section lists will be concatenated.

If a particular extension is not in this list (say, 1mh) it will be displayed with the rest of the section it belongs to. The effect of this is that you only need to explicitly list extensions if you want to force a particular order. Sections with extensions should usually be adjacent to their main section (e.g. "1 1mh 8 ...").

SECTIONS is accepted as an alternative name for this directive.

MINCATWIDTH width

If the terminal width is less than width, cat pages will not be created (if missing) or displayed. The default is 80.

MAXCATWIDTH width

If the terminal width is greater than width, cat pages will not be created (if missing) or displayed. The default is 80.

CATWIDTH width

If width is non-zero, cat pages will always be formatted for a terminal of the given width, regardless of the width of the terminal actually being used. This overrides MINCATWIDTH and MAXCATWIDTH.

NOCACHE

This flag prevents man(1) from creating cat pages automatically.

## BUGS
Unless the rules above are followed and observed precisely, the manual pager utilities will not function as desired. The rules are overly complicated.

https://gitlab.com/man-db/man-db/-/issues

https://savannah.nongnu.org/bugs/?group=man-db


acct

package: man-pages

title: acct(5)

summary: process accounting file

text:
# acct(5)

## NAME
acct - process accounting file

## SYNOPSIS

```
#include <sys/acct.h>
```

## DESCRIPTION
If the kernel is built with the process accounting option enabled (CONFIG_BSD_PROCESS_ACCT), then calling acct(2) starts process accounting, for example:

acct("/var/log/pacct");

When process accounting is enabled, the kernel writes a record to the accounting file as each process on the system terminates. This record contains information about the terminated process, and is defined in <sys/acct.h> as follows:

```
#define ACCT_COMM 16
typedef u_int16_t comp_t;
struct acct {

    char ac_flag;           /* Accounting flags */

    u_int16_t ac_uid;       /* Accounting user ID */

    u_int16_t ac_gid;       /* Accounting group ID */

    u_int16_t ac_tty;       /* Controlling terminal */

    u_int32_t ac_btime;     /* Process creation time

                               (seconds since the Epoch) */

    comp_t    ac_utime;     /* User CPU time */

    comp_t    ac_stime;     /* System CPU time */

    comp_t    ac_etime;     /* Elapsed time */

    comp_t    ac_mem;       /* Average memory usage (kB) */

    comp_t    ac_io;        /* Characters transferred (unused) */

    comp_t    ac_rw;        /* Blocks read or written (unused) */

    comp_t    ac_minflt;    /* Minor page faults */

    comp_t    ac_majflt;    /* Major page faults */

    comp_t    ac_swaps;     /* Number of swaps (unused) */

    u_int32_t ac_exitcode;  /* Process termination status

                               (see wait(2)) */

    char      ac_comm[ACCT_COMM+1];

                            /* Command name (basename of last

                               executed command; null-terminated) */

    char      ac_pad[X];    /* padding bytes */
};
enum {          /* Bits that may be set in ac_flag field */

    AFORK = 0x01,           /* Has executed fork, but no exec */

    ASU   = 0x02,           /* Used superuser privileges */

    ACORE = 0x08,           /* Dumped core */

    AXSIG = 0x10            /* Killed by a signal */
};
```

The comp_t data type is a floating-point value consisting of a 3-bit, base-8 exponent, and a 13-bit mantissa. A value, c, of this type can be converted to a (long) integer as follows:

```
    v = (c & 0x1fff) << (((c >> 13) & 0x7) * 3);
```

The ac_utime, ac_stime, and ac_etime fields measure time in "clock ticks"; divide these values by sysconf(_SC_CLK_TCK) to convert them to seconds.

### Version 3 accounting file format
Since Linux 2.6.8, an optional alternative version of the accounting file can be produced if the CONFIG_BSD_PROCESS_ACCT_V3 option is set when building the kernel. With this option is set, the records written to the accounting file contain additional fields, and the width of c_uid and ac_gid fields is widened from 16 to 32 bits (in line with the increased size of UID and GIDs in Linux 2.4 and later). The records are defined as follows:

```
struct acct_v3 {

    char      ac_flag;      /* Flags */

    char      ac_version;   /* Always set to ACCT_VERSION (3) */

    u_int16_t ac_tty;       /* Controlling terminal */

    u_int32_t ac_exitcode;  /* Process termination status */

    u_int32_t ac_uid;       /* Real user ID */

    u_int32_t ac_gid;       /* Real group ID */

    u_int32_t ac_pid;       /* Process ID */

    u_int32_t ac_ppid;      /* Parent process ID */

    u_int32_t ac_btime;     /* Process creation time */

    float     ac_etime;     /* Elapsed time */

    comp_t    ac_utime;     /* User CPU time */

    comp_t    ac_stime;     /* System time */

    comp_t    ac_mem;       /* Average memory usage (kB) */

    comp_t    ac_io;        /* Characters transferred (unused) */

    comp_t    ac_rw;        /* Blocks read or written

                               (unused) */

    comp_t    ac_minflt;    /* Minor page faults */

    comp_t    ac_majflt;    /* Major page faults */

    comp_t    ac_swaps;     /* Number of swaps (unused) */

    char      ac_comm[ACCT_COMM]; /* Command name */
};
```

## VERSIONS
Although it is present on most systems, it is not standardized, and the details vary somewhat between systems.

## STANDARDS
None.

## HISTORY
glibc 2.6.

Process accounting originated on BSD.

## NOTES
Records in the accounting file are ordered by termination time of the process.

Up to and including Linux 2.6.9, a separate accounting record is written for each thread created using the NPTL threading library; since Linux 2.6.10, a single accounting record is written for the entire process on termination of the last thread in the process.

The /proc/sys/kernel/acct file, described in proc(5), defines settings that control the behavior of process accounting when disk space runs low.

## SEE ALSO
lastcomm(1), acct(2), accton(8), sa(8)


charmap

title: charmap(5)

summary: character set description file

text:
# charmap(5)

## NAME
charmap - character set description file

## DESCRIPTION
A character set description (charmap) defines all available characters and their encodings in a character set. localedef(1) can use charmaps to create locale variants for different character sets.

### Syntax
The charmap file starts with a header that may consist of the following keywords:

<code_set_name>

is followed by the name of the character map.

<comment_char>

is followed by a character that will be used as the comment character for the rest of the file. It defaults to the number sign (#).

<escape_char>

is followed by a character that should be used as the escape character for the rest of the file to mark characters that should be interpreted in a special way. It defaults to the backslash (\).

<mb_cur_max>

is followed by the maximum number of bytes for a character. The default value is 1.

<mb_cur_min>

is followed by the minimum number of bytes for a character. This value must be less than or equal than <mb_cur_max>. If not specified, it defaults to <mb_cur_max>.

The character set definition section starts with the keyword CHARMAP in the first column.

The following lines may have one of the two following forms to define the character set:

<character> byte-sequence comment

This form defines exactly one character and its byte sequence, comment being optional.

<character>..<character> byte-sequence comment

This form defines a character range and its byte sequence, comment being optional.

The character set definition section ends with the string END CHARMAP.

The character set definition section may optionally be followed by a section to define widths of characters.

The WIDTH_DEFAULT keyword can be used to define the default width for all characters not explicitly listed. The default character width is 1.

The width section for individual characters starts with the keyword WIDTH in the first column.

The following lines may have one of the two following forms to define the widths of the characters:

<character> width

This form defines the width of exactly one character.

<character>...<character> width

This form defines the width for all the characters in the range.

The width definition section ends with the string END WIDTH.

## FILES
/usr/share/i18n/charmaps

Usual default character map path.

## STANDARDS
POSIX.2.

## EXAMPLES
The Euro sign is defined as follows in the UTF-8 charmap:

```
<U20AC>     /xe2/x82/xac EURO SIGN
```

## SEE ALSO
iconv(1), locale(1), localedef(1), locale(5), charsets(7)


core

title: core(5)

summary: core dump file

text:
# core(5)

## NAME
core - core dump file

## DESCRIPTION
The default action of certain signals is to cause a process to terminate and produce a core dump file, a file containing an image of the process's memory at the time of termination. This image can be used in a debugger (e.g., gdb(1)) to inspect the state of the program at the time that it terminated. A list of the signals which cause a process to dump core can be found in signal(7).

A process can set its soft RLIMIT_CORE resource limit to place an upper limit on the size of the core dump file that will be produced if it receives a "core dump" signal; see getrlimit(2) for details.

There are various circumstances in which a core dump file is not produced:

•

The process does not have permission to write the core file. (By default, the core file is called core or core.pid, where pid is the ID of the process that dumped core, and is created in the current working directory. See below for details on naming.) Writing the core file fails if the directory in which it is to be created is not writable, or if a file with the same name exists and is not writable or is not a regular file (e.g., it is a directory or a symbolic link).

•

A (writable, regular) file with the same name as would be used for the core dump already exists, but there is more than one hard link to that file.

•

The filesystem where the core dump file would be created is full; or has run out of inodes; or is mounted read-only; or the user has reached their quota for the filesystem.

•

The directory in which the core dump file is to be created does not exist.

•

The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell's ulimit command (limit in csh(1)). However, RLIMIT_CORE will be ignored if the system is configured to pipe core dumps to a program.

•

The binary being executed by the process does not have read permission enabled. (This is a security measure to ensure that an executable whose contents are not readable does not produce a—possibly readable—core dump containing an image of the executable.)

•

The process is executing a set-user-ID (set-group-ID) program that is owned by a user (group) other than the real user (group) ID of the process, or the process is executing a program that has file capabilities (see capabilities(7)). (However, see the description of the prctl(2) PR_SET_DUMPABLE operation, and the description of the /proc/sys/fs/suid_dumpable file in proc(5).)

•

/proc/sys/kernel/core_pattern is empty and /proc/sys/kernel/core_uses_pid contains the value 0. (These files are described below.) Note that if /proc/sys/kernel/core_pattern is empty and /proc/sys/kernel/core_uses_pid contains the value 1, core dump files will have names of the form .pid, and such files are hidden unless one uses the ls(1) -a option.

•

(Since Linux 3.7) The kernel was configured without the CONFIG_COREDUMP option.

In addition, a core dump may exclude part of the address space of the process if the madvise(2) MADV_DONTDUMP flag was employed.

On systems that employ systemd(1) as the init framework, core dumps may instead be placed in a location determined by systemd(1). See below for further details.

### Naming of core dump files
By default, a core dump file is named core, but the /proc/sys/kernel/core_pattern file (since Linux 2.6 and 2.4.21) can be set to define a template that is used to name core dump files. The template can contain % specifiers which are substituted by the following values when a core file is created:

%%

A single % character.

%c

Core file size soft resource limit of crashing process (since Linux 2.6.24).

%d

Dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE (since Linux 3.7).

%e

The process or thread's comm value, which typically is the same as the executable filename (without path prefix, and truncated to a maximum of 15 characters), but may have been modified to be something different; see the discussion of /proc/pid/comm and /proc/pid/task/tid/comm in proc(5).

%E

Pathname of executable, with slashes ('/') replaced by exclamation marks ('!') (since Linux 3.0).

%g

Numeric real GID of dumped process.

%h

Hostname (same as nodename returned by uname(2)).

%i

TID of thread that triggered core dump, as seen in the PID namespace in which the thread resides (since Linux 3.18).

%I

TID of thread that triggered core dump, as seen in the initial PID namespace (since Linux 3.18).

%p

PID of dumped process, as seen in the PID namespace in which the process resides.

%P

PID of dumped process, as seen in the initial PID namespace (since Linux 3.12).

%s

Number of signal causing dump.

%t

Time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).

%u

Numeric real UID of dumped process.

A single % at the end of the template is dropped from the core filename, as is the combination of a % followed by any character other than those listed above. All other characters in the template become a literal part of the core filename. The template may include '/' characters, which are interpreted as delimiters for directory names. The maximum size of the resulting core filename is 128 bytes (64 bytes before Linux 2.6.19). The default value in this file is "core". For backward compatibility, if /proc/sys/kernel/core_pattern does not include %p and /proc/sys/kernel/core_uses_pid (see below) is nonzero, then .PID will be appended to the core filename.

Paths are interpreted according to the settings that are active for the crashing process. That means the crashing process's mount namespace (see mount_namespaces(7)), its current working directory (found via getcwd(2)), and its root directory (see chroot(2)).

Since Linux 2.4, Linux has also provided a more primitive method of controlling the name of the core dump file. If the /proc/sys/kernel/core_uses_pid file contains the value 0, then a core dump file is simply named core. If this file contains a nonzero value, then the core dump file includes the process ID in a name of the form core.PID.

Since Linux 3.6, if /proc/sys/fs/suid_dumpable is set to 2 ("suidsafe"), the pattern must be either an absolute pathname (starting with a leading '/' character) or a pipe, as defined below.

### Piping core dumps to a program
Since Linux 2.6.19, Linux supports an alternate syntax for the /proc/sys/kernel/core_pattern file. If the first character of this file is a pipe symbol (|), then the remainder of the line is interpreted as the command-line for a user-space program (or script) that is to be executed.

Since Linux 5.3.0, the pipe template is split on spaces into an argument list before the template parameters are expanded. In earlier kernels, the template parameters are expanded first and the resulting string is split on spaces into an argument list. This means that in earlier kernels executable names added by the %e and %E template parameters could get split into multiple arguments. So the core dump handler needs to put the executable names as the last argument and ensure it joins all parts of the executable name using spaces. Executable names with multiple spaces in them are not correctly represented in earlier kernels, meaning that the core dump handler needs to use mechanisms to find the executable name.

Instead of being written to a file, the core dump is given as standard input to the program. Note the following points:

•

The program must be specified using an absolute pathname (or a pathname relative to the root directory, /), and must immediately follow the '|' character.

•

The command-line arguments can include any of the % specifiers listed above. For example, to pass the PID of the process that is being dumped, specify %p in an argument.

•

The process created to run the program runs as user and group root.

•

Running as root does not confer any exceptional security bypasses. Namely, LSMs (e.g., SELinux) are still active and may prevent the handler from accessing details about the crashed process via /proc/pid.

•

The program pathname is interpreted with respect to the initial mount namespace as it is always executed there. It is not affected by the settings (e.g., root directory, mount namespace, current working directory) of the crashing process.

•

The process runs in the initial namespaces (PID, mount, user, and so on) and not in the namespaces of the crashing process. One can utilize specifiers such as %P to find the right /proc/pid directory and probe/enter the crashing process's namespaces if needed.

•

The process starts with its current working directory as the root directory. If desired, it is possible change to the working directory of the dumping process by employing the value provided by the %P specifier to change to the location of the dumping process via /proc/pid/cwd.

•

Command-line arguments can be supplied to the program (since Linux 2.6.24), delimited by white space (up to a total line length of 128 bytes).

•

The RLIMIT_CORE limit is not enforced for core dumps that are piped to a program via this mechanism.

### /proc/sys/kernel/core_pipe_limit
When collecting core dumps via a pipe to a user-space program, it can be useful for the collecting program to gather data about the crashing process from that process's /proc/pid directory. In order to do this safely, the kernel must wait for the program collecting the core dump to exit, so as not to remove the crashing process's /proc/pid files prematurely. This in turn creates the possibility that a misbehaving collecting program can block the reaping of a crashed process by simply never exiting.

Since Linux 2.6.32, the /proc/sys/kernel/core_pipe_limit can be used to defend against this possibility. The value in this file defines how many concurrent crashing processes may be piped to user-space programs in parallel. If this value is exceeded, then those crashing processes above this value are noted in the kernel log and their core dumps are skipped.

A value of 0 in this file is special. It indicates that unlimited processes may be captured in parallel, but that no waiting will take place (i.e., the collecting program is not guaranteed access to /proc/<crashing-PID>). The default value for this file is 0.

### Controlling which mappings are written to the core dump
Since Linux 2.6.23, the Linux-specific /proc/pid/coredump_filter file can be used to control which memory segments are written to the core dump file in the event that a core dump is performed for the process with the corresponding process ID.

The value in the file is a bit mask of memory mapping types (see mmap(2)). If a bit is set in the mask, then memory mappings of the corresponding type are dumped; otherwise they are not dumped. The bits in this file have the following meanings:

bit 0

Dump anonymous private mappings.

bit 1

Dump anonymous shared mappings.

bit 2

Dump file-backed private mappings.

bit 3

Dump file-backed shared mappings.

bit 4 (since Linux 2.6.24)

Dump ELF headers.

bit 5 (since Linux 2.6.28)

Dump private huge pages.

bit 6 (since Linux 2.6.28)

Dump shared huge pages.

bit 7 (since Linux 4.4)

Dump private DAX pages.

bit 8 (since Linux 4.4)

Dump shared DAX pages.

By default, the following bits are set: 0, 1, 4 (if the CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS kernel configuration option is enabled), and 5. This default can be modified at boot time using the coredump_filter boot option.

The value of this file is displayed in hexadecimal. (The default value is thus displayed as 33.)

Memory-mapped I/O pages such as frame buffer are never dumped, and virtual DSO (vdso(7)) pages are always dumped, regardless of the coredump_filter value.

A child process created via fork(2) inherits its parent's coredump_filter value; the coredump_filter value is preserved across an execve(2).

It can be useful to set coredump_filter in the parent shell before running a program, for example:

```
$ echo 0x7 > /proc/self/coredump_filter
$ ./some_program
```

This file is provided only if the kernel was built with the CONFIG_ELF_CORE configuration option.

### Core dumps and systemd
On systems using the systemd(1) init framework, core dumps may be placed in a location determined by systemd(1). To do this, systemd(1) employs the core_pattern feature that allows piping core dumps to a program. One can verify this by checking whether core dumps are being piped to the systemd-coredump(8) program:

```
$ cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e
```

In this case, core dumps will be placed in the location configured for systemd-coredump(8), typically as lz4(1) compressed files in the directory /var/lib/systemd/coredump/. One can list the core dumps that have been recorded by systemd-coredump(8) using coredumpctl(1):

```
$ coredumpctl list | tail -5
Wed 2017-10-11 22:25:30 CEST  2748 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:29:10 CEST  2716 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:30:50 CEST  2767 1000 1000 3 present  /usr/bin/sleep
Thu 2017-10-12 06:37:40 CEST  2918 1000 1000 3 present  /usr/bin/cat
Thu 2017-10-12 08:13:07 CEST  2955 1000 1000 3 present  /usr/bin/cat
```

The information shown for each core dump includes the date and time of the dump, the PID, UID, and GID of the dumping process, the signal number that caused the core dump, and the pathname of the executable that was being run by the dumped process. Various options to coredumpctl(1) allow a specified coredump file to be pulled from the systemd(1) location into a specified file. For example, to extract the core dump for PID 2955 shown above to a file named core in the current directory, one could use:

```
$ coredumpctl dump 2955 -o core
```

For more extensive details, see the coredumpctl(1) manual page.

To (persistently) disable the systemd(1) mechanism that archives core dumps, restoring to something more like traditional Linux behavior, one can set an override for the systemd(1) mechanism, using something like:

```
# echo "kernel.core_pattern=core.%p" > \
               /etc/sysctl.d/50-coredump.conf
# /lib/systemd/systemd-sysctl
```

It is also possible to temporarily (i.e., until the next reboot) change the core_pattern setting using a command such as the following (which causes the names of core dump files to include the executable name as well as the number of the signal which triggered the core dump):

```
# sysctl -w kernel.core_pattern="%e-%s.core"
```

## NOTES
The gdb(1) gcore command can be used to obtain a core dump of a running process.

In Linux versions up to and including 2.6.27, if a multithreaded process (or, more precisely, a process that shares its memory with another process by being created with the CLONE_VM flag of clone(2)) dumps core, then the process ID is always appended to the core filename, unless the process ID was already included elsewhere in the filename via a %p specification in /proc/sys/kernel/core_pattern. (This is primarily useful when employing the obsolete LinuxThreads implementation, where each thread of a process has a different PID.)

## EXAMPLES
The program below can be used to demonstrate the use of the pipe syntax in the /proc/sys/kernel/core_pattern file. The following shell session demonstrates the use of this program (compiled to create an executable named core_pattern_pipe_test):

```
$ cc -o core_pattern_pipe_test core_pattern_pipe_test.c
$ su
Password:
# echo "|$PWD/core_pattern_pipe_test %p UID=%u GID=%g sig=%s" > \
    /proc/sys/kernel/core_pattern
# exit
$ sleep 100
^\                     # type control-backslash
Quit (core dumped)
$ cat core.info
argc=5
argc[0]=</home/mtk/core_pattern_pipe_test>
argc[1]=<20575>
argc[2]=<UID=1000>
argc[3]=<GID=100>
argc[4]=<sig=3>
Total bytes in core dump: 282624
```

### Program source

```
/* core_pattern_pipe_test.c */
#define _GNU_SOURCE
#include <sys/stat.h>
#include <fcntl.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define BUF_SIZE 1024
int
main(int argc, char *argv[])
{

    ssize_t nread, tot;

    char buf[BUF_SIZE];

    FILE *fp;

    char cwd[PATH_MAX];

    /* Change our current working directory to that of the

       crashing process. */

    snprintf(cwd, PATH_MAX, "/proc/%s/cwd", argv[1]);

    chdir(cwd);

    /* Write output to file "core.info" in that directory. */

    fp = fopen("core.info", "w+");

    if (fp == NULL)

        exit(EXIT_FAILURE);

    /* Display command-line arguments given to core_pattern

       pipe program. */

    fprintf(fp, "argc=%d\n", argc);

    for (size_t j = 0; j < argc; j++)

        fprintf(fp, "argc[%zu]=<%s>\n", j, argv[j]);

    /* Count bytes in standard input (the core dump). */

    tot = 0;

    while ((nread = read(STDIN_FILENO, buf, BUF_SIZE)) > 0)

        tot += nread;

    fprintf(fp, "Total bytes in core dump: %zd\n", tot);

    fclose(fp);

    exit(EXIT_SUCCESS);
}
```

## SEE ALSO
bash(1), coredumpctl(1), gdb(1), getrlimit(2), mmap(2), prctl(2), sigaction(2), elf(5), proc(5), pthreads(7), signal(7), systemd-coredump(8)


title: dir_colors(5)

summary: configuration file for dircolors(1)

text:
# dir_colors(5)

## NAME
dir_colors - configuration file for dircolors(1)

## DESCRIPTION
The program ls(1) uses the environment variable LS_COLORS to determine the colors in which the filenames are to be displayed. This environment variable is usually set by a command like

eval `dircolors some_path/dir_colors`

found in a system default shell initialization file, like /etc/profile or /etc/csh.cshrc. (See also dircolors(1).) Usually, the file used here is /etc/DIR_COLORS and can be overridden by a .dir_colors file in one's home directory.

This configuration file consists of several statements, one per line. Anything right of a hash mark (#) is treated as a comment, if the hash mark is at the beginning of a line or is preceded by at least one whitespace. Blank lines are ignored.

The global section of the file consists of any statement before the first TERM statement. Any statement in the global section of the file is considered valid for all terminal types. Following the global section is one or more terminal-specific sections, preceded by one or more TERM statements which specify the terminal types (as given by the TERM environment variable) the following declarations apply to. It is always possible to override a global declaration by a subsequent terminal-specific one.

The following statements are recognized; case is insignificant:

TERM terminal-type

Starts a terminal-specific section and specifies which terminal it applies to. Multiple TERM statements can be used to create a section which applies for several terminal types.

COLOR yes|all|no|none|tty

(Slackware only; ignored by GNU dircolors(1).) Specifies that colorization should always be enabled (yes or all), never enabled (no or none), or enabled only if the output is a terminal (tty). The default is no.

EIGHTBIT yes|no

(Slackware only; ignored by GNU dircolors(1).) Specifies that eight-bit ISO 8859 characters should be enabled by default. For compatibility reasons, this can also be specified as 1 for yes or 0 for no. The default is no.

OPTIONS options

(Slackware only; ignored by GNU dircolors(1).) Adds command-line options to the default ls command line. The options can be any valid ls command-line options, and should include the leading minus sign. Note that dircolors does not verify the validity of these options.

NORMAL color-sequence

Specifies the color used for normal (nonfilename) text.

Synonym: NORM.

FILE color-sequence

Specifies the color used for a regular file.

DIR color-sequence

Specifies the color used for directories.

LINK color-sequence

Specifies the color used for a symbolic link.

Synonyms: LNK, SYMLINK.

ORPHAN color-sequence

Specifies the color used for an orphaned symbolic link (one which points to a nonexistent file). If this is unspecified, ls will use the LINK color instead.

MISSING color-sequence

Specifies the color used for a missing file (a nonexistent file which nevertheless has a symbolic link pointing to it). If this is unspecified, ls will use the FILE color instead.

FIFO color-sequence

Specifies the color used for a FIFO (named pipe).

Synonym: PIPE.

SOCK color-sequence

Specifies the color used for a socket.

DOOR color-sequence

(Supported since fileutils 4.1) Specifies the color used for a door (Solaris 2.5 and later).

BLK color-sequence

Specifies the color used for a block device special file.

Synonym: BLOCK.

CHR color-sequence

Specifies the color used for a character device special file.

Synonym: CHAR.

EXEC color-sequence

Specifies the color used for a file with the executable attribute set.

SUID color-sequence

Specifies the color used for a file with the set-user-ID attribute set.

Synonym: SETUID.

SGID color-sequence

Specifies the color used for a file with the set-group-ID attribute set.

Synonym: SETGID.

STICKY color-sequence

Specifies the color used for a directory with the sticky attribute set.

STICKY_OTHER_WRITABLE color-sequence

Specifies the color used for an other-writable directory with the executable attribute set.

Synonym: OWT.

OTHER_WRITABLE color-sequence

Specifies the color used for an other-writable directory without the executable attribute set.

Synonym: OWR.

LEFTCODE color-sequence

Specifies the left code for non-ISO 6429 terminals (see below).

Synonym: LEFT.

RIGHTCODE color-sequence

Specifies the right code for non-ISO 6429 terminals (see below).

Synonym: RIGHT.

ENDCODE color-sequence

Specifies the end code for non-ISO 6429 terminals (see below).

Synonym: END.

*extension color-sequence

Specifies the color used for any file that ends in extension.

.extension color-sequence

Same as *.extension. Specifies the color used for any file that ends in .extension. Note that the period is included in the extension, which makes it impossible to specify an extension not starting with a period, such as ~ for emacs backup files. This form should be considered obsolete.

### ISO 6429 (ANSI) color sequences
Most color-capable ASCII terminals today use ISO 6429 (ANSI) color sequences, and many common terminals without color capability, including xterm and the widely used and cloned DEC VT100, will recognize ISO 6429 color codes and harmlessly eliminate them from the output or emulate them. ls uses ISO 6429 codes by default, assuming colorization is enabled.

ISO 6429 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

Not all commands will work on all systems or display devices.

ls uses the following defaults:

NORMAL

0

Normal (nonfilename) text

FILE

0

Regular file

DIR

32

Directory

LINK

36

Symbolic link

ORPHAN

undefined

Orphaned symbolic link

MISSING

undefined

Missing file

FIFO

31

Named pipe (FIFO)

SOCK

33

Socket

BLK

44;37

Block device

CHR

44;37

Character device

EXEC

35

Executable file

A few terminal programs do not recognize the default properly. If all text gets colorized after you do a directory listing, change the NORMAL and FILE codes to the numerical codes for your normal foreground and background colors.

### Other terminal types (advanced configuration)
If you have a color-capable (or otherwise highlighting) terminal (or printer!) which uses a different set of codes, you can still generate a suitable setup. To do so, you will have to use the LEFTCODE, RIGHTCODE, and ENDCODE definitions.

When writing out a filename, ls generates the following output sequence: LEFTCODE typecode RIGHTCODE filename ENDCODE, where the typecode is the color sequence that depends on the type or name of file. If the ENDCODE is undefined, the sequence LEFTCODE NORMAL RIGHTCODE will be used instead. The purpose of the left- and rightcodes is merely to reduce the amount of typing necessary (and to hide ugly escape codes away from the user). If they are not appropriate for your terminal, you can eliminate them by specifying the respective keyword on a line by itself.

NOTE: If the ENDCODE is defined in the global section of the setup file, it cannot be undefined in a terminal-specific section of the file. This means any NORMAL definition will have no effect. A different ENDCODE can, however, be specified, which would have the same effect.

### Escape sequences
To specify control- or blank characters in the color sequences or filename extensions, either C-style \-escaped notation or stty-style ^-notation can be used. The C-style notation includes the following characters:

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

\nnn

Any character (octal notation)

\xnnn

Any character (hexadecimal notation)

\_

Space

\\

Backslash (\)

\^

Caret (^)

\#

Hash mark (#)

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.

## FILES
/etc/DIR_COLORS

System-wide configuration file.

~/.dir_colors

Per-user configuration file.

This page describes the dir_colors file format as used in the fileutils-4.1 package; other versions may differ slightly.

## NOTES
The default LEFTCODE and RIGHTCODE definitions, which are used by ISO 6429 terminals are:

LEFTCODE

\e[

RIGHTCODE

m

The default ENDCODE is undefined.

## SEE ALSO
dircolors(1), ls(1), stty(1), xterm(1)