neulab/tldr huggingface dataset:
General notes When splitting files mkvmerge(1) will correctly adjust the chapters as well. This means that each file only includes the chapter entries that apply to it, and that the timestamps will be offset to match the new timestamps of each output file.
mkvmerge(1) is able to copy chapters from Matroska(TM) source files unless this is explicitly disabled with the --no-chapters option. The chapters from all sources (Matroska(TM) files, Ogg files, MP4 files, chapter text files) are usually not merged but end up in separate ChapterEditions. Only if chapters are read from several Matroska(TM) or XML files that share the same edition UIDs will chapters be merged into a single ChapterEdition. If such a merge is desired in other situations as well then the user has to extract the chapters from all sources with mkvextract(1) first, merge the XML files manually and mux them afterwards.
Introduction Matroska(TM)'s tag system is similar to that of other containers: a set of KEY=VALUE pairs. However, in Matroska(TM) these tags can also be nested, and both the KEY and the VALUE are elements of their own. The example file example-tags-2.xml shows how to use this system.
Scope of the tags Matroska(TM) tags do not automatically apply to the complete file. They can, but they also may apply to different parts of the file: to one or more tracks, to one or more chapters, or even to a combination of both. The Matroska(TM) specification[5] gives more details about this fact.
One important fact is that tags are linked to tracks or chapters with the Targets Matroska(TM) tag element, and that the UIDs used for this linking are not the track IDs mkvmerge(1) uses everywhere. Instead the numbers used are the UIDs which mkvmerge(1) calculates automatically (if the track is taken from a file format other than Matroska(TM)) or which are copied from the source file if the track's source file is a Matroska(TM) file. Therefore it is difficult to know which UIDs to use in the tag file before the file is handed over to mkvmerge(1).
mkvmerge(1) knows two options with which you can add tags to Matroska(TM) files: The --global-tags and the --tags options. The difference is that the former option, --global-tags, will make the tags apply to the complete file by removing any of those Targets elements mentioned above. The latter option, --tags, automatically inserts the UID that mkvmerge(1) generates for the tag specified with the TID part of the --tags option.
Example Let's say that you want to add tags to a video track read from an AVI. mkvmerge --identify file.avi tells you that the video track's ID (do not mix this ID with the UID!) is 0. So you create your tag file, leave out all Targets elements and call mkvmerge(1):
$ mkvmerge -o file.mkv --tags 0:tags.xml file.avi
Tag file format mkvmerge(1) supports a XML based tag file format. The format is very closely modeled after the Matroska(TM) specification[5]. Both the binary and the source distributions of MKVToolNix come with a sample file called example-tags-2.xml which simply lists all known tags and which can be used as a basis for real life tag files.
The basics are:
•   The outermost element must be <Tags>.
•   One logical tag is contained inside one pair of <Tag> XML tags.
•   White spaces directly before and after tag contents are ignored.
Data types The new Matroska(TM) tagging system only knows two data types, a UTF-8 string and a binary type. The first is used for the tag's name and the <String> element while the binary type is used for the <Binary> element.
As binary data itself would not fit into a XML file mkvmerge(1) supports two other methods of storing binary data. If the contents of a XML tag starts with '@' then the following text is treated as a file name. The corresponding file's content is copied into the Matroska(TM) element.
Otherwise the data is expected to be Base64 encoded. This is an encoding that transforms binary data into a limited set of ASCII characters and is used e.g. in email programs.  mkvextract(1) will output Base64 encoded data for binary elements.
The deprecated tagging system knows some more data types which can be found in the official Matroska(TM) tag specs. As mkvmerge(1) does not support this system anymore these types aren't described here.
Known tags for the XML file format The following lists the supported XML tags, their data types and, where appropriate, the valid range for their values:
Tags (master) Tag (master) Targets (master) TargetTypeValue (unsigned integer) TargetType (UTF-8 string) TrackUID (unsigned integer) EditionUID (unsigned integer) ChapterUID (unsigned integer) AttachmentUID (unsigned integer) Simple (master) Simple (master) Name (UTF-8 string) TagLanguage (UTF-8 string) DefaultLanguage (unsigned integer) String (UTF-8 string) Binary (binary)
With a segment info XML file it is possible to set certain values in the "segment information" header field of a Matroska(TM) file. All of these values cannot be set via other command line options.
Other "segment information" header fields can be set via command line options but not via the XML file. This includes e.g. the --title and the --timestamp-scale options.
There are other elements that can be set neither via command line options nor via the XML files. These include the following elements: DateUTC (also known as the "muxing date"), MuxingApp, WritingApp and Duration. They're always set by mkvmerge(1) itself.
Info (master) SegmentUID (binary, valid range: length in bytes == 16) SegmentFilename (UTF-8 string) PreviousSegmentUID (binary, valid range: length in bytes == 16) PreviousSegmentFilename (UTF-8 string) NextSegmentUID (binary, valid range: length in bytes == 16) NextSegmentFilename (UTF-8 string) SegmentFamily (binary, valid range: length in bytes == 16) ChapterTranslate (master) ChapterTranslateEditionUID (unsigned integer) ChapterTranslateCodec (unsigned integer) ChapterTranslateID (binary)
MATROSKA(TM) FILE LAYOUT The Matroska(TM) file layout is quite flexible.  mkvmerge(1) will render a file in a predefined way. The resulting file looks like this:
[EBML head] [segment {meta seek #1} [segment information] [track information] {attachments} {chapters} [cluster 1] {cluster 2} ... {cluster n} {cues} {meta seek #2} {tags}]
The elements in curly braces are optional and depend on the contents and options used. A couple of notes:
•   meta seek #1 includes only a small number of level 1 elements, and only if they actually exist: attachments, chapters, cues, tags, meta seek #2. Older versions of mkvmerge(1) used to put the clusters into this meta seek element as well. Therefore some imprecise guessing was necessary to reserve enough space. It often failed. Now only the clusters are stored in meta seek #2, and meta seek #1 refers to the meta seek element #2.
•   Attachment, chapter and tag elements are only present if they were added.
The shortest possible Matroska(TM) file would look like this:
[EBML head] [segment [segment information] [track information] [cluster 1]]
This might be the case for audio-only files.
mkvmerge(1) allows the user to chose the timestamps for a specific track himself. This can be used in order to create files with variable frame rate video or include gaps in audio. A frame in this case is the unit that mkvmerge(1) creates separately per Matroska(TM) block. For video this is exactly one frame, for audio this is one packet of the specific audio type. E.g. for AC-3 this would be a packet containing 1536 samples.
Timestamp files that are used when tracks are appended to each other must only be specified for the first part in a chain of tracks. For example if you append two files, v1.avi and v2.avi, and want to use timestamps then your command line must look something like this:
$ mkvmerge ... --timestamps 0:my_timestamps.txt v1.avi +v2.avi
There are four formats that are recognized by mkvmerge(1). The first line always contains the version number. Empty lines, lines containing only whitespace and lines beginning with '#' are ignored.
Timestamp file format v1 This format starts with the version line. The second line declares the default number of frames per second. All following lines contain three numbers separated by commas: the start frame (0 is the first frame), the end frame and the number of frames in this range. The FPS is a floating point number with the dot '.' as the decimal point. The ranges can contain gaps for which the default FPS is used. An example:
# timestamp format v1 assume 27.930 800,1000,25 1500,1700,30
Timestamp file format v2 In this format each line contains a timestamp for the corresponding frame. This timestamp must be given in millisecond precision. It can be a floating point number, but it doesn't have to be. You have to give at least as many timestamp lines as there are frames in the track. The timestamps in this file must be sorted. Example for 25fps:
# timestamp format v2 0 40 80
Timestamp file format v3 In this format each line contains a duration in seconds followed by an optional number of frames per second. Both can be floating point numbers. If the number of frames per second is not present the default one is used. For audio you should let the codec calculate the frame timestamps itself. For that you should be using 0.0 as the number of frames per second. You can also create gaps in the stream by using the 'gap' keyword followed by the duration of the gap. Example for an audio file:
# timestamp format v3 assume 0.0 25.325 7.530,38.236 gap, 10.050 2.000,38.236
Timestamp file format v4 This format is identical to the v2 format. The only difference is that the timestamps do not have to be sorted. This format should almost never be used.
mkvmerge(1) exits with one of three exit codes:
•   0 -- This exit code means that muxing has completed successfully.
•   1 -- In this case mkvmerge(1) has output at least one warning, but muxing did continue. A warning is prefixed with the text 'Warning:'. Depending on the issues involved the resulting file might be ok or not. The user is urged to check both the warning and the resulting file.
•   2 -- This exit code is used after an error occurred.  mkvmerge(1) aborts right after outputting the error message. Error messages range from wrong command line arguments over read/write errors to broken files.
mkvmerge(1) uses the default variables that determine the system's locale (e.g.  LANG and the LC_* family). Additional variables:
MKVMERGE_DEBUG, MKVTOOLNIX_DEBUG and its short form MTX_DEBUG The content is treated as if it had been passed via the --debug option.
MKVMERGE_ENGAGE, MKVTOOLNIX_ENGAGE and its short form MTX_ENGAGE The content is treated as if it had been passed via the --engage option.
mkvinfo(1), mkvextract(1), mkvpropedit(1), mkvtoolnix-gui(1)
The latest version can always be found at the MKVToolNix homepage[6].
Moritz Bunkus <moritz@bunkus.org> Developer
1. the Matroska(TM) website https://www.matroska.org/
2. the IANA homepage https://www.iana.org/assignments/media-types/
3. mkvmerge-identification-output-schema-v14.json https://mkvtoolnix.download/doc/mkvmerge-identification-output-schema-v14.json
4. RFC 7159 https://tools.ietf.org/html/rfc7159
5. Matroska(TM) specification https://www.matroska.org/technical/specs/index.html
6. the MKVToolNix homepage https://mkvtoolnix.download/
GIT-MAINTENANCE(1)                 Git Manual                 GIT-MAINTENANCE(1)
git-maintenance - Run tasks to optimize Git repository data
git maintenance run [<options>]
Run tasks to optimize Git repository data, speeding up other Git commands and reducing storage requirements for the repository.
Git commands that add repository data, such as git add or git fetch, are optimized for a responsive user experience. These commands do not take time to optimize the Git data, since such optimizations scale with the full size of the repository while these user commands each perform a relatively small action.
The git maintenance command provides flexibility for how to optimize the Git repository.
register Initialize Git config values so any scheduled maintenance will start running on this repository. This adds the repository to the maintenance.repo config variable in the current user’s global config and enables some recommended configuration values for maintenance.<task>.schedule. The tasks that are enabled are safe for running in the background without disrupting foreground processes.
The register subcommand will also set the maintenance.strategy config value to incremental, if this value is not previously set. The incremental strategy uses the following schedule for each maintenance task:
•   gc: disabled.
•   commit-graph: hourly.
•   prefetch: hourly.
•   loose-objects: daily.
•   incremental-repack: daily.
git maintenance register will also disable foreground maintenance by setting maintenance.auto = false in the current repository. This config setting will remain after a git maintenance unregister command.
run Run one or more maintenance tasks. If one or more --task options are specified, then those tasks are run in that order. Otherwise, the tasks are determined by which maintenance.<task>.enabled config options are true. By default, only maintenance.gc.enabled is true.
start Start running maintenance on the current repository. This performs the same config updates as the register subcommand, then updates the background scheduler to run git maintenance run --scheduled on an hourly basis.
stop Halt the background maintenance schedule. The current repository is not removed from the list of maintained repositories, in case the background maintenance is restarted later.
unregister Remove the current repository from background maintenance. This only removes the repository from the configured list. It does not stop the background maintenance processes from running.
commit-graph The commit-graph job updates the commit-graph files incrementally, then verifies that the written data is correct. The incremental write is safe to run alongside concurrent Git processes since it will not expire .graph files that were in the previous commit-graph-chain file. They will be deleted by a later run based on the expiration delay.
prefetch The prefetch task updates the object directory with the latest objects from all registered remotes. For each remote, a git fetch command is run. The configured refspec is modified to place all requested refs within refs/prefetch/. Also, tags are not updated.
This is done to avoid disrupting the remote-tracking branches. The end users expect these refs to stay unmoved unless they initiate a fetch. With prefetch task, however, the objects necessary to complete a later real fetch would already be obtained, so the real fetch would go faster. In the ideal case, it will just become an update to a bunch of remote-tracking branches without any object transfer.
gc Clean up unnecessary files and optimize the local repository. "GC" stands for "garbage collection," but this task performs many smaller tasks. This task can be expensive for large repositories, as it repacks all Git objects into a single pack-file. It can also be disruptive in some situations, as it deletes stale data. See git- gc(1) for more details on garbage collection in Git.
loose-objects The loose-objects job cleans up loose objects and places them into pack-files. In order to prevent race conditions with concurrent Git commands, it follows a two-step process. First, it deletes any loose objects that already exist in a pack-file; concurrent Git processes will examine the pack-file for the object data instead of the loose object. Second, it creates a new pack-file (starting with "loose-") containing a batch of loose objects. The batch size is limited to 50 thousand objects to prevent the job from taking too long on a repository with many loose objects. The gc task writes unreachable objects as loose objects to be cleaned up by a later step only if they are not re-added to a pack-file; for this reason it is not advisable to enable both the loose-objects and gc tasks at the same time.
incremental-repack The incremental-repack job repacks the object directory using the multi-pack-index feature. In order to prevent race conditions with concurrent Git commands, it follows a two-step process. First, it calls git multi-pack-index expire to delete pack-files unreferenced by the multi-pack-index file. Second, it calls git multi-pack-index repack to select several small pack-files and repack them into a bigger one, and then update the multi-pack-index entries that refer to the small pack-files to refer to the new pack-file. This prepares those small pack-files for deletion upon the next run of git multi-pack-index expire. The selection of the small pack-files is such that the expected size of the big pack-file is at least the batch size; see the --batch-size option for the repack subcommand in git-multi-pack-index(1). The default batch-size is zero, which is a special case that attempts to repack all pack-files into a single pack-file.
pack-refs The pack-refs task collects the loose reference files and collects them into a single file. This speeds up operations that need to iterate across many references. See git-pack-refs(1) for more information.
--auto When combined with the run subcommand, run maintenance tasks only if certain thresholds are met. For example, the gc task runs when the number of loose objects exceeds the number stored in the gc.auto config setting, or when the number of pack-files exceeds the gc.autoPackLimit config setting. Not compatible with the --schedule option.
--schedule When combined with the run subcommand, run maintenance tasks only if certain time conditions are met, as specified by the maintenance.<task>.schedule config value for each <task>. This config value specifies a number of seconds since the last time that task ran, according to the maintenance.<task>.lastRun config value. The tasks that are tested are those provided by the --task=<task> option(s) or those with maintenance.<task>.enabled set to true.
--quiet Do not report progress or other information over stderr.
--task=<task> If this option is specified one or more times, then only run the specified tasks in the specified order. If no --task=<task> arguments are specified, then only the tasks with maintenance.<task>.enabled configured as true are considered. See the TASKS section for the list of accepted <task> values.
--scheduler=auto|crontab|systemd-timer|launchctl|schtasks When combined with the start subcommand, specify the scheduler for running the hourly, daily and weekly executions of git maintenance run. Possible values for <scheduler> are auto, crontab (POSIX), systemd-timer (Linux), launchctl (macOS), and schtasks (Windows). When auto is specified, the appropriate platform-specific scheduler is used; on Linux, systemd-timer is used if available, otherwise crontab. Default is auto.
The git maintenance command is designed to simplify the repository maintenance patterns while minimizing user wait time during Git commands. A variety of configuration options are available to allow customizing this process. The default maintenance options focus on operations that complete quickly, even on large repositories.
Users may find some cases where scheduled maintenance tasks do not run as frequently as intended. Each git maintenance run command takes a lock on the repository’s object database, and this prevents other concurrent git maintenance run commands from running on the same repository. Without this safeguard, competing processes could leave the repository in an unpredictable state.
The background maintenance schedule runs git maintenance run processes on an hourly basis. Each run executes the "hourly" tasks. At midnight, that process also executes the "daily" tasks. At midnight on the first day of the week, that process also executes the "weekly" tasks. A single process iterates over each registered repository, performing the scheduled tasks for that frequency. Depending on the number of registered repositories and their sizes, this process may take longer than an hour. In this case, multiple git maintenance run commands may run on the same repository at the same time, colliding on the object database lock. This results in one of the two tasks not running.
If you find that some maintenance windows are taking longer than one hour to complete, then consider reducing the complexity of your maintenance tasks. For example, the gc task is much slower than the incremental-repack task. However, this comes at a cost of a slightly larger object database. Consider moving more expensive tasks to be run less frequently.
Expert users may consider scheduling their own maintenance tasks using a different schedule than is available through git maintenance start and Git configuration options. These users should be aware of the object database lock and how concurrent git maintenance run commands behave. Further, the git gc command should not be combined with git maintenance run commands. git gc modifies the object database but does not take the lock in the same way as git maintenance run. If possible, use git maintenance run --task=gc instead of git gc.
The following sections describe the mechanisms put in place to run background maintenance by git maintenance start and how to customize them.
The standard mechanism for scheduling background tasks on POSIX systems is cron(8). This tool executes commands based on a given schedule. The current list of user-scheduled tasks can be found by running crontab -l. The schedule written by git maintenance start is similar to this:
# BEGIN GIT MAINTENANCE SCHEDULE # The following schedule was created by Git # Any edits made in this region might be # replaced in the future by a Git command.
0 1-23 * * * "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=hourly 0 0 * * 1-6 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=daily 0 0 * * 0 "/<path>/git" --exec-path="/<path>" for-each-repo --config=maintenance.repo maintenance run --schedule=weekly
# END GIT MAINTENANCE SCHEDULE
The comments are used as a region to mark the schedule as written by Git. Any modifications within this region will be completely deleted by git maintenance stop or overwritten by git maintenance start.
The crontab entry specifies the full path of the git executable to ensure that the executed git command is the same one with which git maintenance start was issued independent of PATH. If the same user runs git maintenance start with multiple Git executables, then only the latest executable is used.
These commands use git for-each-repo --config=maintenance.repo to run git maintenance run --schedule=<frequency> on each repository listed in the multi-valued maintenance.repo config option. These are typically loaded from the user-specific global config. The git maintenance process then determines which maintenance tasks are configured to run on each repository with each <frequency> using the maintenance.<task>.schedule config options. These values are loaded from the global or repository config values.
If the config values are insufficient to achieve your desired background maintenance schedule, then you can create your own schedule. If you run crontab -e, then an editor will load with your user-specific cron schedule. In that editor, you can add your own schedule lines. You could start by adapting the default schedule listed earlier, or you could read the crontab(5) documentation for advanced scheduling techniques. Please do use the full path and --exec-path techniques from the default schedule to ensure you are executing the correct binaries in your schedule.
While Linux supports cron, depending on the distribution, cron may be an optional package not necessarily installed. On modern Linux distributions, systemd timers are superseding it.
If user systemd timers are available, they will be used as a replacement of cron.
In this case, git maintenance start will create user systemd timer units and start the timers. The current list of user-scheduled tasks can be found by running systemctl --user list-timers. The timers written by git maintenance start are similar to this:
$ systemctl --user list-timers NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES Thu 2021-04-29 19:00:00 CEST 42min left    Thu 2021-04-29 18:00:11 CEST 17min ago  git-maintenance@hourly.timer git-maintenance@hourly.service Fri 2021-04-30 00:00:00 CEST 5h 42min left Thu 2021-04-29 00:00:11 CEST 18h ago    git-maintenance@daily.timer  git-maintenance@daily.service Mon 2021-05-03 00:00:00 CEST 3 days left   Mon 2021-04-26 00:00:11 CEST 3 days ago git-maintenance@weekly.timer git-maintenance@weekly.service
One timer is registered for each --schedule=<frequency> option.
The definition of the systemd units can be inspected in the following files:
~/.config/systemd/user/git-maintenance@.timer ~/.config/systemd/user/git-maintenance@.service ~/.config/systemd/user/timers.target.wants/git-maintenance@hourly.timer ~/.config/systemd/user/timers.target.wants/git-maintenance@daily.timer ~/.config/systemd/user/timers.target.wants/git-maintenance@weekly.timer
git maintenance start will overwrite these files and start the timer again with systemctl --user, so any customization should be done by creating a drop-in file, i.e. a .conf suffixed file in the ~/.config/systemd/user/git-maintenance@.service.d directory.
git maintenance stop will stop the user systemd timers and delete the above mentioned files.
For more details, see systemd.timer(5).
While macOS technically supports cron, using crontab -e requires elevated privileges and the executed process does not have a full user context. Without a full user context, Git and its credential helpers cannot access stored credentials, so some maintenance tasks are not functional.
Instead, git maintenance start interacts with the launchctl tool, which is the recommended way to schedule timed jobs in macOS. Scheduling maintenance through git maintenance (start|stop) requires some launchctl features available only in macOS 10.11 or later.
Your user-specific scheduled tasks are stored as XML-formatted .plist files in ~/Library/LaunchAgents/. You can see the currently-registered tasks using the following command:
$ ls ~/Library/LaunchAgents/org.git-scm.git* org.git-scm.git.daily.plist org.git-scm.git.hourly.plist org.git-scm.git.weekly.plist
One task is registered for each --schedule=<frequency> option. To inspect how the XML format describes each schedule, open one of these .plist files in an editor and inspect the <array> element following the <key>StartCalendarInterval</key> element.
git maintenance start will overwrite these files and register the tasks again with launchctl, so any customizations should be done by creating your own .plist files with distinct names. Similarly, the git maintenance stop command will unregister the tasks with launchctl and delete the .plist files.
To create more advanced customizations to your background tasks, see launchctl.plist(5) for more information.
Windows does not support cron and instead has its own system for scheduling background tasks. The git maintenance start command uses the schtasks command to submit tasks to this system. You can inspect all background tasks using the Task Scheduler application. The tasks added by Git have names of the form Git Maintenance (<frequency>). The Task Scheduler GUI has ways to inspect these tasks, but you can also export the tasks to XML files and view the details there.
Note that since Git is a console application, these background tasks create a console window visible to the current user. This can be changed manually by selecting the "Run whether user is logged in or not" option in Task Scheduler. This change requires a password input, which is why git maintenance start does not select it by default.
If you want to customize the background tasks, please rename the tasks so future calls to git maintenance (start|stop) do not overwrite your custom tasks.
MKNOD(1)                          User Commands                         MKNOD(1)
mknod - make block or character special files
mknod [OPTION]... NAME TYPE [MAJOR MINOR]
Create the special file NAME of the given TYPE.
-m, --mode=MODE set file permission bits to MODE, not a=rw - umask
-Z     set the SELinux security context to default type
--context[=CTX] like -Z, or if CTX is specified then set the SELinux or SMACK security context to CTX
Both MAJOR and MINOR must be specified when TYPE is b, c, or u, and they must be omitted when TYPE is p.  If MAJOR or MINOR begins with 0x or 0X, it is interpreted as hexadecimal; otherwise, if it begins with 0, as octal; otherwise, as decimal.  TYPE may be:
b      create a block (buffered) special file
c, u   create a character (unbuffered) special file
p      create a FIFO
NOTE: your shell may have its own version of mknod, which usually supersedes the version described here.  Please refer to your shell's documentation for details about the options it supports.
Written by David MacKenzie.
mknod(2)
Full documentation <https://www.gnu.org/software/coreutils/mknod> or available locally via: info '(coreutils) mknod invocation'
env(5)                         File Formats Manual                        env(5)
env - rancid environment configuration file
env contains environment configuration information for do-diffs(1) and rancid(1) including shell PATH, list of rancid groups, etc. and is read by do-diffs(1) at run-time.
The syntax of env is that of sh(1).  env is used to set environment variables used by other rancid scripts to effect their run-time behavior or to enable them to find their resources.
The following variables are used (alphabetically):
BASEDIR BASEDIR is the top-level directory where rancid is installed.  Its value is set by configure and should be modified if rancid is moved to a new location in the file system without re-installing from the distribution.
Default: /usr/local/rancid
CVSROOT cvs(1) and create_cvs(1) use this environment variable to locate the CVS repository.  It should not be necessary to alter CVSROOT.
Default: $BASEDIR/CVS
FILTER_PWDS Determines which passwords will be filtered from configs.  The value may be "NO", "YES", or "ALL" to filter none of the passwords, only those which are reversable or plain-text, or all (plus ssh keys, etc), respectively.
Default: YES
Note: a value of "NO" could be a security issue since diffs are sent via e-mail.  A value of "ALL" is encouraged.
Note: FILTER_PWDS does not affect the handling of SNMP community strings.  see NOCOMMSTR below.
Note: passwords whose value cycles and would produce erroneous diffs are always filtered (eg: Alteon passwords).
LIST_OF_GROUPS Defines a list of group names of routers separated by white-space. These names become the directory names in $BASEDIR which contain the data for that set of devices.  do-diffs(1) also uses this variable to determine which device groups it should collect. Choose these names to be descriptive of the set of devices and do not use spaces, unprintable characters, etc.
Example: LIST_OF_GROUPS="UofO USFS"
Two groups are defined; UofO (University of Oregon) and USFS (US Forest Service).  Each will have a directory created (see create_cvs(1)) $BASEDIR/UofO and $BASEDIR/USFS respectively, which will contain their data.
Each group must also have aliases for the administrative and diff recipients set-up in /etc/aliases.  For example:
rancid-uofo:            frank rancid-admin-uofo:      joe,bob rancid-usfs:            frank rancid-admin-usfs:      joe,bob
NOCOMMSTR If set, rancid(1) will filter SNMP community strings from configs. Otherwise, they will be retained and may appear in clear-text in e-mail diffs.  By default, this is not set.
NOPIPE If set, rancid(1) will use temporary files to save the output from the router and then read these to build the file which will be saved in CVS.  Otherwise, an IPC pipe will be used.  We have found that the buffering mechanisms used in perl and expect are heinous. Using temporary files may result in a noticeable improvement in speed.  By default, this is not set.
OLDTIME Specified as a number of hours, OLDTIME defines how many hours should pass since a successful collection of a device's configuration and when control_rancid(1) should start complaining about failures.  The value should be greater than the number of hours between do-diffs cron runs.
Default: 4
PAR_COUNT Defines the number of rancid processes that par(1) will start simultaneously as control_rancid(1) attempts to perform collections.  Raising this value will decrease the amount of time necessary for a complete collection of a (or all) rancid groups at the expense of system load.  The default is relatively cautious. If collections are not completing quickly enough for users, use trial and error of speed versus system load to find a suitable value.
Default: 5
PATH   Is a colon separate list of directory pathnames in the the file system where rancid's sh(1) and perl(1) scripts should look for the programs that it needs, such as telnet(1).  Its value is set by configure.  Should it be necessary to modify PATH, note that it must include $BASEDIR/bin (see above).
TERM   Some Unix utilities require TERM, the terminal type, to be set to a sane value.  The default should suffice.
Default: network
TMPDIR Some Unix utilities recognize TMPDIR as a directory where temporary files can be stored.  In some cases, rancid utilizes this directory for lock files and other temporary files.
Default: /tmp
Each of these are simply environment variables.  In order for them to be present in the environment of child processes, each must be exported. See sh(1) for more information on the built-in command export.
env is interpreted directly by sh(1), so its syntax follows that of the bourne shell.  Errors may produce quite unexpected results.
$BASEDIR/bin/env Configuration file described here.
control_rancid(1), create_cvs(1), do-diffs(1), rancid(1)
RENAME(1p)             User Contributed Perl Documentation            RENAME(1p)
rename - renames multiple files
rename [ -h|-m|-V ] [ -v ] [ -0 ] [ -n ] [ -f ] [ -d ] [ -e|-E perlexpr]*|perlexpr [ files ]
"rename" renames the filenames supplied according to the rule specified as the first argument.  The perlexpr argument is a Perl expression which is expected to modify the $_ string in Perl for at least some of the filenames specified.  If a given filename is not modified by the expression, it will not be renamed.  If no filenames are given on the command line, filenames will be read via standard input.
For example, to rename all files matching "*.bak" to strip the extension, you might say
rename 's/\.bak$//' *.bak
To translate uppercase names to lower, you'd use
rename 'y/A-Z/a-z/' *
-v, --verbose Verbose: print names of files successfully renamed.
-0, --null Use \0 as record separator when reading from STDIN.
-n, --nono No action: print names of files to be renamed, but don't rename.
-f, --force Over write: allow existing files to be over-written.
--path, --fullpath Rename full path: including any directory component.  DEFAULT
-d, --filename, --nopath, --nofullpath Do not rename directory: only rename filename component of path.
-h, --help Help: print SYNOPSIS and OPTIONS.
-m, --man Manual: print manual page.
-V, --version Version: show version number.
-e      Expression: code to act on files name.
May be repeated to build up code (like "perl -e").  If no -e, the first argument is used as code.
-E      Statement: code to act on files name, as -e but terminated by ';'.
No environment variables are used.
mv(1), perl(1)
If you give an invalid Perl expression you'll get a syntax error.
The original "rename" did not check for the existence of target filenames, so had to be used with care.
GIT-GREP(1)                        Git Manual                        GIT-GREP(1)
git-grep - Print lines matching a pattern
git grep [-a | --text] [-I] [--textconv] [-i | --ignore-case] [-w | --word-regexp] [-v | --invert-match] [-h|-H] [--full-name] [-E | --extended-regexp] [-G | --basic-regexp] [-P | --perl-regexp] [-F | --fixed-strings] [-n | --line-number] [--column] [-l | --files-with-matches] [-L | --files-without-match] [(-O | --open-files-in-pager) [<pager>]] [-z | --null] [ -o | --only-matching ] [-c | --count] [--all-match] [-q | --quiet] [--max-depth <depth>] [--[no-]recursive] [--color[=<when>] | --no-color] [--break] [--heading] [-p | --show-function] [-A <post-context>] [-B <pre-context>] [-C <context>] [-W | --function-context] [--threads <num>] [-f <file>] [-e] <pattern> [--and|--or|--not|(|)|-e <pattern>...] [--recurse-submodules] [--parent-basename <basename>] [ [--[no-]exclude-standard] [--cached | --no-index | --untracked] | <tree>...] [--] [<pathspec>...]
Look for specified patterns in the tracked files in the work tree, blobs registered in the index file, or blobs in given tree objects. Patterns are lists of one or more search expressions separated by newline characters. An empty string as search expression matches all lines.
--cached Instead of searching tracked files in the working tree, search blobs registered in the index file.
--no-index Search files in the current directory that is not managed by Git.
--untracked In addition to searching in the tracked files in the working tree, search also in untracked files.
--no-exclude-standard Also search in ignored files by not honoring the .gitignore mechanism. Only useful with --untracked.
--exclude-standard Do not pay attention to ignored files specified via the .gitignore mechanism. Only useful when searching files in the current directory with --no-index.
--recurse-submodules Recursively search in each submodule that is active and checked out in the repository. When used in combination with the <tree> option the prefix of all submodule output will be the name of the parent project’s <tree> object. This option has no effect if --no-index is given.
-a, --text Process binary files as if they were text.
--textconv Honor textconv filter settings.
--no-textconv Do not honor textconv filter settings. This is the default.
-i, --ignore-case Ignore case differences between the patterns and the files.
-I Don’t match the pattern in binary files.
--max-depth <depth> For each <pathspec> given on command line, descend at most <depth> levels of directories. A value of -1 means no limit. This option is ignored if <pathspec> contains active wildcards. In other words if "a*" matches a directory named "a*", "*" is matched literally so --max-depth is still effective.
-r, --recursive Same as --max-depth=-1; this is the default.
--no-recursive Same as --max-depth=0.
-w, --word-regexp Match the pattern only at word boundary (either begin at the beginning of a line, or preceded by a non-word character; end at the end of a line or followed by a non-word character).
-v, --invert-match Select non-matching lines.
-h, -H By default, the command shows the filename for each match.  -h option is used to suppress this output.  -H is there for completeness and does not do anything except it overrides -h given earlier on the command line.
--full-name When run from a subdirectory, the command usually outputs paths relative to the current directory. This option forces paths to be output relative to the project top directory.
-E, --extended-regexp, -G, --basic-regexp Use POSIX extended/basic regexp for patterns. Default is to use basic regexp.
-P, --perl-regexp Use Perl-compatible regular expressions for patterns.
-F, --fixed-strings Use fixed strings for patterns (don’t interpret pattern as a regex).
-n, --line-number Prefix the line number to matching lines.
--column Prefix the 1-indexed byte-offset of the first match from the start of the matching line.
-l, --files-with-matches, --name-only, -L, --files-without-match Instead of showing every matched line, show only the names of files that contain (or do not contain) matches. For better compatibility with git diff, --name-only is a synonym for --files-with-matches.
-O[<pager>], --open-files-in-pager[=<pager>] Open the matching files in the pager (not the output of grep). If the pager happens to be "less" or "vi", and the user specified only one pattern, the first file is positioned at the first match automatically. The pager argument is optional; if specified, it must be stuck to the option without a space. If pager is unspecified, the default pager will be used (see core.pager in git-config(1)).
-z, --null Use \0 as the delimiter for pathnames in the output, and print them verbatim. Without this option, pathnames with "unusual" characters are quoted as explained for the configuration variable core.quotePath (see git-config(1)).
-o, --only-matching Print only the matched (non-empty) parts of a matching line, with each such part on a separate output line.
-c, --count Instead of showing every matched line, show the number of lines that match.
--color[=<when>] Show colored matches. The value must be always (the default), never, or auto.
--no-color Turn off match highlighting, even when the configuration file gives the default to color output. Same as --color=never.
--break Print an empty line between matches from different files.
--heading Show the filename above the matches in that file instead of at the start of each shown line.
-p, --show-function Show the preceding line that contains the function name of the match, unless the matching line is a function name itself. The name is determined in the same way as git diff works out patch hunk headers (see Defining a custom hunk-header in gitattributes(5)).
-<num>, -C <num>, --context <num> Show <num> leading and trailing lines, and place a line containing -- between contiguous groups of matches.
-A <num>, --after-context <num> Show <num> trailing lines, and place a line containing -- between contiguous groups of matches.
-B <num>, --before-context <num> Show <num> leading lines, and place a line containing -- between contiguous groups of matches.
-W, --function-context Show the surrounding text from the previous line containing a function name up to the one before the next function name, effectively showing the whole function in which the match was found. The function names are determined in the same way as git diff works out patch hunk headers (see Defining a custom hunk-header in gitattributes(5)).
--threads <num> Number of grep worker threads to use. See grep.threads in CONFIGURATION for more information.
-f <file> Read patterns from <file>, one per line.
Passing the pattern via <file> allows for providing a search pattern containing a \0.
Not all pattern types support patterns containing \0. Git will error out if a given pattern type can’t support such a pattern. The --perl-regexp pattern type when compiled against the PCRE v2 backend has the widest support for these types of patterns.
In versions of Git before 2.23.0 patterns containing \0 would be silently considered fixed. This was never documented, there were also odd and undocumented interactions between e.g. non-ASCII patterns containing \0 and --ignore-case.
In future versions we may learn to support patterns containing \0 for more search backends, until then we’ll die when the pattern type in question doesn’t support them.
-e The next parameter is the pattern. This option has to be used for patterns starting with - and should be used in scripts passing user input to grep. Multiple patterns are combined by or.
--and, --or, --not, ( ... ) Specify how multiple patterns are combined using Boolean expressions. --or is the default operator.  --and has higher precedence than --or. -e has to be used for all patterns.
--all-match When giving multiple pattern expressions combined with --or, this flag is specified to limit the match to files that have lines to match all of them.
-q, --quiet Do not output matched lines; instead, exit with status 0 when there is a match and with non-zero status when there isn’t.
<tree>... Instead of searching tracked files in the working tree, search blobs in the given trees.
-- Signals the end of options; the rest of the parameters are <pathspec> limiters.
<pathspec>... If given, limit the search to paths matching at least one pattern. Both leading paths match and glob(7) patterns are supported.
For more details about the <pathspec> syntax, see the pathspec entry in gitglossary(7).
git grep 'time_t' -- '*.[ch]' Looks for time_t in all tracked .c and .h files in the working directory and its subdirectories.
git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \) Looks for a line that has #define and either MAX_PATH or PATH_MAX.
git grep --all-match -e NODE -e Unexpected Looks for a line that has NODE or Unexpected in files that have lines that match both.
git grep solution -- :^Documentation Looks for solution, excluding files in Documentation.
The --threads option (and the grep.threads configuration) will be ignored when --open-files-in-pager is used, forcing a single-threaded execution.
When grepping the object store (with --cached or giving tree objects), running with multiple threads might perform slower than single threaded if --textconv is given and there’re too many text conversions. So if you experience low performance in this case, it might be desirable to use --threads=1.
grep.lineNumber If set to true, enable -n option by default.
grep.column If set to true, enable the --column option by default.
grep.patternType Set the default matching behavior. Using a value of basic, extended, fixed, or perl will enable the --basic-regexp, --extended-regexp, --fixed-strings, or --perl-regexp option accordingly, while the value default will return to the default matching behavior.
grep.extendedRegexp If set to true, enable --extended-regexp option by default. This option is ignored when the grep.patternType option is set to a value other than default.
grep.threads Number of grep worker threads to use. If unset (or set to 0), Git will use as many threads as the number of logical cores available.
grep.fullName If set to true, enable --full-name option by default.
grep.fallbackToNoIndex If set to true, fall back to git grep --no-index if git grep is executed outside of a git repository. Defaults to false.
USERMOD(8)                 System Management Commands                 USERMOD(8)
usermod - modify a user account
usermod [options] LOGIN
The usermod command modifies the system account files to reflect the changes that are specified on the command line.
The options which apply to the usermod command are:
-a, --append Add the user to the supplementary group(s). Use only with the -G option.
-b, --badnames Allow names that do not conform to standards.
-c, --comment COMMENT The new value of the user's password file comment field. It is normally modified using the chfn(1) utility.
-d, --home HOME_DIR The user's new login directory.
If the -m option is given, the contents of the current home directory will be moved to the new home directory, which is created if it does not already exist.
-e, --expiredate EXPIRE_DATE The date on which the user account will be disabled. The date is specified in the format YYYY-MM-DD.
An empty EXPIRE_DATE argument will disable the expiration of the account.
This option requires a /etc/shadow file. A /etc/shadow entry will be created if there were none.
-f, --inactive INACTIVE The number of days after a password expires until the account is permanently disabled.
A value of 0 disables the account as soon as the password has expired, and a value of -1 disables the feature.
-g, --gid GROUP The group name or number of the user's new initial login group. The group must exist.
Any file from the user's home directory owned by the previous primary group of the user will be owned by this new group.
The group ownership of files outside of the user's home directory must be fixed manually.
-G, --groups GROUP1[,GROUP2,...[,GROUPN]]] A list of supplementary groups which the user is also a member of. Each group is separated from the next by a comma, with no intervening whitespace. The groups are subject to the same restrictions as the group given with the -g option.
If the user is currently a member of a group which is not listed, the user will be removed from the group. This behaviour can be changed via the -a option, which appends the user to the current supplementary group list.
-l, --login NEW_LOGIN The name of the user will be changed from LOGIN to NEW_LOGIN. Nothing else is changed. In particular, the user's home directory or mail spool should probably be renamed manually to reflect the new login name.
-L, --lock Lock a user's password. This puts a '!' in front of the encrypted password, effectively disabling the password. You can't use this option with -p or -U.
Note: if you wish to lock the account (not only access with a password), you should also set the EXPIRE_DATE to 1.