DIREVENT.CONF(5)

πŸ’– DIREVENT.CONF(5) πŸ’–

okay bestie, so this is the direvent.conf page β€” the config file for direvent(8). it's a lot, so buckle up, we're doing this in parts 🫢


✨ NAME ✨

direvent.conf β€” the configuration file for direvent(8). that's it, that's the name, short and iconic πŸ’…


🌸 DESCRIPTION 🌸

so the config file is made up of statements and comments. that's the whole vibe.

there are three classes of lexical tokens:

  • keywords
  • values
  • separators

blanks, tabs, newlines and comments β€” collectively called white space β€” are ignored, except when they're doing their one job of separating tokens. also, some white space is required to separate otherwise adjacent keywords and values. so like, don't just mush your words together, bestie 😭


πŸŽ€ COMMENTS πŸŽ€

comments can show up anywhere white space is allowed. there are two kinds: single-line and multi-line.

single-line comments start with # or // and go all the way to the end of the line, periodt:

# This is a comment
// This too is a comment

multi-line (or C-style) comments start with the two characters /* (slash, star) and keep going until the first occurrence of */ (star, slash).

🚨 multi-line comments cannot be nested. however, single-line comments may well appear inside multi-line ones. no cap.

πŸ¦‹ Pragmatic Comments πŸ¦‹

pragmatic comments are like regular single-line comments but with main character energy β€” they actually change how the configuration is parsed. they start with a # sign and end at the next physical newline character.

  • #include <FILE> / #include FILE β€” include the contents of the file FILE. if FILE is an absolute file name, the named file is included. if it doesn't exist, an error message gets issued.

if FILE contains wildcard characters (*, [, ], or ?), it's interpreted as a shell globbing pattern, and all files matching that pattern get included, in lexicographical order. if no matching files are found, the directive is replaced with an empty line.

otherwise, the form with angle brackets searches for the file in the include search path, while the second one looks for it in the current working directory first, and if it's not found there, then in the include search path. if the file is not found, an error message will be issued.

the order of directories goes like this: first, direvent scans any directories given with -I options, in the same order as given on the command line, and then the directories in the standard include search path. that latter one is defined at compile time and you can peek at it in the output of the --help option. iykyk ✨

  • #include_once <FILE> / #include_once FILE β€” same as #include, except that if the FILE (or any of the files it expands to) has already been included, it will not be included again. we love no duplicates πŸ’…
  • #line num / #line num "FILE" β€” this line makes the parser believe, for purposes of error diagnostics, that the line number of the next source line is given by num and the current input file is named by FILE. if FILE is absent, the remembered file name does not change.
  • # num "FILE" β€” this is a special form of the #line statement, understood for compatibility with the C preprocessor. throwback fr fr 🫢

πŸ‘‘ STATEMENTS πŸ‘‘

πŸ’œ Simple statement

a simple statement is a keyword and a value, separated by any amount of whitespace. it's terminated with a semicolon (;).

here's one, living its truth:

pidfile /var/run/direvent.pid;

scroll down for the list of valid simple statements ⬇️

a value can be one of these:

  • number β€” a sequence of decimal digits.
  • boolean β€” one of: yes, true, t or 1, meaning true; and no, false, nil, 0 meaning false.
  • unquoted string β€” may contain letters, digits, and any of these characters: _, -, ., /, @, *, :.
  • quoted string β€” any sequence of characters enclosed in double-quotes ("). a backslash appearing inside a quoted string introduces an escape sequence, which gets replaced with a single character according to these rules:
    • \\ β†’ \ β€” ASCII 134
    • \" β†’ " β€” ASCII 042
    • \a β†’ audible bell β€” ASCII 007
    • \b β†’ backspace β€” ASCII 010
    • \f β†’ form-feed β€” ASCII 014
    • \n β†’ new line β€” ASCII 012
    • \r β†’ carriage return β€” ASCII 015
    • \t β†’ horizontal tabulation β€” ASCII 011
    • \v β†’ vertical tabulation β€” ASCII 013

plus, the sequence \newline is removed from the string. this lets you split long strings over several physical lines, like:

"a long string may be\
 split over several lines"
😭 if the character following a backslash is not one of the ones listed above, the backslash is ignored and a warning is issued. noted, bestie.
  • Here-document β€” a special construct that lets you introduce strings of text containing embedded newlines.

the <<word construct tells the parser to read all the following lines up to the line containing only word, with possible trailing blanks. all the lines it reads get concatenated together into a single string. for example:

<<EOT
A multiline
string
EOT

the body of a here-document is interpreted the same way as a double-quoted string, unless word is preceded by a backslash (e.g. <<\EOT) or enclosed in double-quotes β€” in which case the text is read as is, with no interpretation of escape sequences. 🧚

if word is prefixed with - (a dash), then all leading tab characters are stripped from the input lines and from the line containing word. furthermore, if the - is followed by a single space, all leading whitespace is stripped from them. this lets you indent here-documents in a natural fashion. for example:

<<- TEXT
    The leading whitespace will be
    ignored when reading these lines.
TEXT

it is important that the terminating delimiter be the only token on its line. the only exception to this rule is allowed if a here-document appears as the last element of a statement β€” in that case a semicolon can be placed on the same line as its terminating delimiter, like:

help-text <<-EOT
    A sample help text.
EOT;
  • list β€” a comma-separated list of values, enclosed in parentheses. here's a statement whose value is a list of strings:
option (wait, stderr);

in any context where a list is appropriate, a single value is allowed without being a member of a list β€” it's equivalent to a list with a single member. so like, this:

option wait;

is equivalent to this:

option (wait);

🌈 Block Statement

a block statement introduces a logical group of statements. it's a keyword, followed by an optional value called a tag, and a sequence of statements enclosed in curly braces, like this:

watcher {
    path /etc;
    event create;
}

the closing curly brace may be followed by a semicolon, although that's not required. so do it or don't, we support you either way πŸ’…


⭐ VARIABLE EXPANSION ⭐

arguments of some statements undergo variable expansion before use. during variable expansion, variable references found in a string get replaced with the actual values of the corresponding variables.

a variable reference has the form $VAR or ${VAR}, where VAR is the variable name. the two forms are entirely equivalent. the curly-brace form is normally used when the variable name is immediately followed by an alphanumeric symbol, which would otherwise be counted as part of it. this form also lets you specify what action to take if the variable is undefined or expands to an empty value:

  • ${VARIABLE:-WORD} β€” Use Default Values. if VARIABLE is unset or null, the expansion of WORD is substituted. otherwise, the value of VARIABLE is substituted.
  • ${VARIABLE:=WORD} β€” Assign Default Values. if VARIABLE is unset or null, the expansion of WORD is assigned to the variable. the value of VARIABLE is then substituted.
  • ${VARIABLE:?WORD} β€” Display Error if Null or Unset. if VARIABLE is null or unset, the expansion of WORD (or a message to that effect if WORD is not present) is output to the current logging channel. otherwise, the value of VARIABLE is substituted.
  • ${VARIABLE:+WORD} β€” Use Alternate Value. if VARIABLE is null or unset, nothing is substituted; otherwise, the expansion of WORD is substituted.

two kinds of variables take part in variable expansion: environment variables and macro variables. the latter are special variable-like entities defined by direvent to carry information about the event and its target file 🫢

  • file β€” name of the file covered by the event.
  • genev_code β€” generic (system-independent) event code. it's a bitwise OR of the event codes represented as a decimal number.
  • genev_name β€” generic event name. if several generic events are reported simultaneously, the value of this variable is a list of event names separated by space characters. each name corresponds to a bit in genev_code.
  • self_test_pid β€” the PID of the external command started with the --self-test (-T) option. if direvent is started without this option, this variable is not defined.
  • sysev_code β€” system-dependent event code. it's a bitwise OR of the event codes represented as a decimal number.
  • sysev_name β€” system-dependent event name. if several events are reported, the value of this variable is a list of event names separated by space characters. each name corresponds to a bit in sysev_code. see the section SYSTEM DEPENDENCIES in direvent(8) for a list of system-dependent event names. πŸ‘‘

✨ GENERAL SETTINGS ✨

okay bestie, these are the top-level knobs that boss around the daemon itself πŸ’…

  • user NAME; β€” sets the user to run as. NAME must be the name of a user that actually exists on the system. No imaginary friends allowed.
  • foreground BOOL; β€” run in the foreground. That's the whole vibe, no notes 🌸.
  • pidfile FILE; β€” upon successful startup, stash the PID of the daemon process in FILE. A little receipt of itself, iconic πŸ“.
  • debug NUMBER; β€” sets the debug level. Valid NUMBER values are 0 (no debug, silent queen) up to 3 (maximum verbosity, yapping privileges fully unlocked).
  • shutdown-timeout NUMBER β€” sets the time to wait for all subprocesses to terminate before exiting the program, in seconds. Any process that's still running after this timeout expires gets forcefully terminated 😭. NUMBER is a floating-point number. The default is 1 second.

πŸ““ LOGGING πŸ““

While it's connected to the terminal, direvent outputs its diagnostics and debugging messages to the standard error. After it disconnects from the controlling terminal, it closes the first three file descriptors and directs all its output to the syslog. When it's running in foreground mode, its messages are sent both to the standard error and to the syslog. Bi messaging rights fr fr 🫢✨.

The following configuration statement controls the syslog output:

syslog {
    facility STRING;
    tag STRING;
    print-priority BOOL;
}

The statements are:

  • facility STRING; β€” set the syslog facility. STRING is one of the following: user, daemon, auth or authpriv, mail, cron, local0 through local7 (case-insensitive, we don't gatekeep capitalization), or a facility number.
  • tag STRING; β€” tag syslog messages with STRING. Normally the messages are tagged with the program name. πŸŽ€
  • print-priority BOOL; β€” prefix each message with its priority.

An example syslog statement:

syslog {
    facility local0;
    print-priority yes;
}

🌍 ENVIRONMENT 🌍

By default the command inherits the environment of direvent, augmented with the following variables:

  • DIREVENT_SYSEV_CODE β€” the system-dependent event code (see the sysev_code macro variable).
  • DIREVENT_SYSEV_NAME β€” the system-dependent event name or names (see the sysev_name macro variable).
  • DIREVENT_GENEV_CODE β€” the generic event code (see the genev_code macro variable).
  • DIREVENT_GENEV_NAME β€” the generic event name or names (see the genev_name macro variable).
  • DIREVENT_FILE β€” the name of the affected file relative to the current working directory (see the file macro variable).

This environment can be further modified, using the environ configuration statement:

environ {
    clear;
    keep PATTERN;
    keep"NAME=VALUE";
    set "NAME=VALUE";
    eval EXPR;
    unset PATTERN;
    unset "NAME=VALUE";
}

Statements inside the environ block define operations that modify the environment. Their arguments undergo variable expansion. The order is not decorative, bestie β€” it's a whole pipeline:

  1. The clear statement is executed first.
  2. Then, keep statements are applied, in order of their appearance.
  3. Finally, set and unset statements are applied in order of their appearance in the configuration.

Now the statements themselves:

  • clear β€” clears the environment by removing (unsetting) all variables, except those listed in keep statements, if such are given (see below). This statement is always executed first. πŸ‘‘
  • keep PATTERN β€” declares variables matching PATTERN (a globbing pattern) as exempt from clearing. This statement implies clear.
  • keep "NAME=VALUE" β€” retains NAME in the environment only if it has the value VALUE. Notice the double-quotes, they're doing important work 🫑.
  • set "NAME=VALUE" β€” assigns VALUE to the environment variable NAME. The value is subject to variable expansion using the same syntax as in shell. The set, eval, and unset (see below) statements are executed in order of their appearance.
  • eval EXPR β€” perform variable expansion on EXPR and discard the result. This is useful for side-effects. It's giving "the expansion was the point" πŸ’….
  • unset PATTERN β€” unset environment variables matching PATTERN.
  • unset "NAME=VALUE" β€” unset environment variable NAME if it has the given VALUE.

πŸ‘€ WATCHER πŸ‘€

The watcher statement configures a single event watcher. One watcher can control several events in multiple pathnames. Any number of watcher statements is allowed in the configuration file, each one of them declaring a separate watcher β€” no sharing, no merging, just main character energy each time πŸ‘‘.

watcher {
    path PATHNAME [recursive [NUMBER]];
    file STRING-LIST;
    event STRING-LIST;
    command STRING;
    user NAME;
    timeout NUMBER;
    option STRING-LIST;
    environ {ENV-SPEC}
}

The statements within a watcher block are:

  • path PATHNAME [recursive [NUMBER]]; β€” defines a pathname to watch. PATHNAME must be the name of an existing directory in the file system. The watcher will watch events occurring for all files within that directory. If the optional recursive clause is specified, this directory will be watched recursively, i.e. when any subdirectory is created in it, direvent will set up a watcher for files in this subdirectory. This new watcher will be an exact copy of the parent watcher, excepting for the pathnames. The optional NUMBER parameter defines a cut-off nesting level for recursive watching. If supplied, the recursive behaviour will apply only to the directories that are nested below that level. πŸͺ†βœ¨

Any number of path statements can appear in a watcher block. At least one path must be defined β€” mandatory, not a suggestion.

  • file STRING-LIST; β€” selects which files are eligible for monitoring. The argument is a list of globbing patterns (in the sense of fnmatch(3)) and/or extended regular expressions (regex(7)), one of which the file name must match in order for the watcher to act on it. Regular expressions must be surrounded by a pair of slashes, optionally followed by the following flags:
    • b β€” use basic regular expressions.
    • i β€” enable case-insensitive matching.
    • A pattern or regular expression prefixed with ! matches file names that don't match the pattern without !. (yes the negation lives inside the pattern, unhinged but we respect it πŸŽ€)
  • event STRING-LIST; β€” configures the filesystem events to watch for in the directories declared by the path statements. The argument is a list of event names. Both generic and system-dependent event names are allowed. Multiple event statements accumulate. A missing event statement means watch all events. For example:
event (open,delete);
  • command STRING; β€” defines a command to execute on event. STRING is a command line just as you would type it in sh(1). It may contain macro variables, which will be expanded prior to execution. For example:
command "/bin/prog -event $genev_name -file $file";

See the section HANDLER ENVIRONMENT in direvent(8), for a detailed discussion of how the command is executed. πŸ“–

  • user STRING; β€” run the command as this user.
  • timeout NUMBER; β€” terminate the command if it runs longer than NUMBER seconds. The default is 5 seconds.
  • option STRING-LIST; β€” a list of additional options. The following options are defined:
    • shell β€” invoke the handler command as $SHELL -c "command".
    • wait β€” wait for the program to terminate before handling the next event from the event queue. Normally the program runs asynchronously.
    • stdout β€” capture the standard output of the command and redirect it to the syslog with the LOG_INFO priority.
    • stderr β€” capture the standard error of the command and redirect it to the syslog with the LOG_ERR priority.
  • environ {ENV-SPEC} β€” modify command environment. See the section ENVIRONMENT, for a discussion of sub-statements in ENV-SPEC. This statement applies to the environment, modified by the global environ statement, if any.

🌈 SEE ALSO 🌈

direvent(8). that's the sister page, go say hi πŸ¦‹


Copyright Β© 2012-2026 Sergey Poznyakoff
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This  is  free  software:  you  are  free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

and that's the whole page bestie πŸŽ€ stay free, stay redistributable, and remember there's NO WARRANTY to the extent permitted by law πŸ˜­πŸ’€. This was DIREVENT, in its DIREVENT.CONF(5) era, dated June 5, 2026 β€” go watch some files for me πŸ’–βœ¨

πŸ“¦ where this page comes from