neulab/tldr huggingface dataset:
BorgBackup (short: Borg) is a deduplicating backup program.  Optionally, it supports compression and authenticated encryption.
The main goal of Borg is to provide an efficient and secure way to backup data.  The data deduplication technique used makes Borg suitable for daily backups since only changes are stored.  The authenticated encryption technique makes it suitable for backups to not fully trusted targets.
Borg stores a set of files in an archive. A repository is a collection of archives. The format of repositories is Borg-specific. Borg does not distinguish archives from each other in any way other than their name, it does not matter when or where archives were created (e.g. different hosts).
A step-by-step example 1. Before a backup can be made a repository has to be initialized:
$ borg init --encryption=repokey /path/to/repo
2. Backup the ~/src and ~/Documents directories into an archive called Monday:
$ borg create /path/to/repo::Monday ~/src ~/Documents
3. The next day create a new archive called Tuesday:
$ borg create --stats /path/to/repo::Tuesday ~/src ~/Documents
This backup will be a lot quicker and a lot smaller since only new never before seen data is stored. The --stats option causes Borg to output statistics about the newly created archive such as the amount of unique data (not shared with other archives):
------------------------------------------------------------------------------ Archive name: Tuesday Archive fingerprint: bd31004d58f51ea06ff735d2e5ac49376901b21d58035f8fb05dbf866566e3c2 Time (start): Tue, 2016-02-16 18:15:11 Time (end):   Tue, 2016-02-16 18:15:11
Duration: 0.19 seconds Number of files: 127 ------------------------------------------------------------------------------ Original size      Compressed size    Deduplicated size This archive:                4.16 MB              4.17 MB             26.78 kB All archives:                8.33 MB              8.34 MB              4.19 MB
Unique chunks         Total chunks Chunk index:                     132                  261 ------------------------------------------------------------------------------
4. List all archives in the repository:
$ borg list /path/to/repo Monday                               Mon, 2016-02-15 19:14:44 Tuesday                              Tue, 2016-02-16 19:15:11
5. List the contents of the Monday archive:
$ borg list /path/to/repo::Monday drwxr-xr-x user   group          0 Mon, 2016-02-15 18:22:30 home/user/Documents -rw-r--r-- user   group       7961 Mon, 2016-02-15 18:22:30 home/user/Documents/Important.doc ...
6. Restore the Monday archive by extracting the files relative to the current directory:
$ borg extract /path/to/repo::Monday
7. Recover disk space by manually deleting the Monday archive:
$ borg delete /path/to/repo::Monday
NOTE: Borg is quiet by default (it works on WARNING log level).  You can use options like --progress or --list to get specific reports during command execution.  You can also add the -v (or --verbose or --info) option to adjust the log level to INFO to get other informational messages.
Positional Arguments and Options: Order matters Borg only supports taking options (-s and --progress in the example) to the left or right of all positional arguments (repo::archive and path in the example), but not in between them:
borg create -s --progress repo::archive path  # good and preferred borg create repo::archive path -s --progress  # also works borg create -s repo::archive path --progress  # works, but ugly borg create repo::archive -s --progress path  # BAD
This is due to a problem in the argparse module: https://bugs.python.org/issue15112
Repository URLs Local filesystem (or locally mounted network filesystem):
/path/to/repo - filesystem path to repo directory, absolute path
path/to/repo - filesystem path to repo directory, relative path
Also, stuff like ~/path/to/repo or ~other/path/to/repo works (this is expanded by your shell).
Note: you may also prepend a file:// to a filesystem path to get URL style.
Remote repositories accessed via ssh user@host:
user@host:/path/to/repo - remote repo, absolute path
ssh://user@host:port/path/to/repo - same, alternative syntax, port can be given
Remote repositories with relative paths can be given using this syntax:
user@host:path/to/repo - path relative to current directory
user@host:~/path/to/repo - path relative to user's home directory
user@host:~other/path/to/repo - path relative to other's home directory
Note: giving user@host:/./path/to/repo or user@host:/~/path/to/repo or user@host:/~other/path/to/repo is also supported, but not required here.
Remote repositories with relative paths, alternative syntax with port:
ssh://user@host:port/./path/to/repo - path relative to current directory
ssh://user@host:port/~/path/to/repo - path relative to user's home directory
ssh://user@host:port/~other/path/to/repo - path relative to other's home directory
If you frequently need the same repo URL, it is a good idea to set the BORG_REPO environment variable to set a default for the repo URL:
export BORG_REPO='ssh://user@host:port/path/to/repo'
Then just leave away the repo URL if only a repo URL is needed and you want to use the default - it will be read from BORG_REPO then.
Use :: syntax to give the repo URL when syntax requires giving a positional argument for the repo (e.g. borg mount :: /mnt).
Repository / Archive Locations Many commands want either a repository (just give the repo URL, see above) or an archive location, which is a repo URL followed by ::archive_name.
Archive names must not contain the / (slash) character. For simplicity, maybe also avoid blanks or other characters that have special meaning on the shell or in a filesystem (borg mount will use the archive name as directory name).
If you have set BORG_REPO (see above) and an archive location is needed, use ::archive_name - the repo URL part is then read from BORG_REPO.
Logging Borg writes all log output to stderr by default. But please note that something showing up on stderr does not indicate an error condition just because it is on stderr. Please check the log levels of the messages and the return code of borg for determining error, warning or success conditions.
If you want to capture the log output to a file, just redirect it:
borg create repo::archive myfiles 2>> logfile
Custom logging configurations can be implemented via BORG_LOGGING_CONF.
The log level of the builtin logging configuration defaults to WARNING. This is because we want Borg to be mostly silent and only output warnings, errors and critical messages, unless output has been requested by supplying an option that implies output (e.g. --list or --progress).
Log levels: DEBUG < INFO < WARNING < ERROR < CRITICAL
Use --debug to set DEBUG log level - to get debug, info, warning, error and critical level output.
Use --info (or -v or --verbose) to set INFO log level - to get info, warning, error and critical level output.
Use --warning (default) to set WARNING log level - to get warning, error and critical level output.
Use --error to set ERROR log level - to get error and critical level output.
Use --critical to set CRITICAL log level - to get critical level output.
While you can set misc. log levels, do not expect that every command will give different output on different log levels - it's just a possibility.
WARNING: Options --critical and --error are provided for completeness, their usage is not recommended as you might miss important information.
Return codes Borg can exit with the following return codes (rc):
┌────────────┬─────────────────────────────┐ │Return code │ Meaning                     │ ├────────────┼─────────────────────────────┤ │0           │ success (logged as INFO)    │ ├────────────┼─────────────────────────────┤ │1           │ warning (operation reached  │ │            │ its normal end, but there   │ │            │ were warnings -- you should │ │            │ check the log, logged as    │ │            │ WARNING)                    │ ├────────────┼─────────────────────────────┤ │2           │ error (like a fatal error,  │ │            │ a local or remote           │ │            │ exception, the operation    │ │            │ did not reach its normal    │ │            │ end, logged as ERROR)       │ ├────────────┼─────────────────────────────┤ │128+N       │ killed by signal N (e.g.    │ │            │ 137 == kill -9)             │ └────────────┴─────────────────────────────┘
If you use --show-rc, the return code is also logged at the indicated level as the last log entry.
Environment Variables Borg uses some environment variables for automation:
BORG_REPO When set, use the value to give the default repository location. If a command needs an archive parameter, you can abbreviate as ::archive. If a command needs a repository parameter, you can either leave it away or abbreviate as ::, if a positional parameter is required.
BORG_PASSPHRASE When set, use the value to answer the passphrase question for encrypted repositories.  It is used when a passphrase is needed to access an encrypted repo as well as when a new passphrase should be initially set when initializing an encrypted repo.  See also BORG_NEW_PASSPHRASE.
BORG_PASSCOMMAND When set, use the standard output of the command (trailing newlines are stripped) to answer the passphrase question for encrypted repositories.  It is used when a passphrase is needed to access an encrypted repo as well as when a new passphrase should be initially set when initializing an encrypted repo. Note that the command is executed without a shell. So variables, like $HOME will work, but ~ won't.  If BORG_PASSPHRASE is also set, it takes precedence.  See also BORG_NEW_PASSPHRASE.
BORG_PASSPHRASE_FD When set, specifies a file descriptor to read a passphrase from. Programs starting borg may choose to open an anonymous pipe and use it to pass a passphrase. This is safer than passing via BORG_PASSPHRASE, because on some systems (e.g. Linux) environment can be examined by other processes.  If BORG_PASSPHRASE or BORG_PASSCOMMAND are also set, they take precedence.
BORG_NEW_PASSPHRASE When set, use the value to answer the passphrase question when a new passphrase is asked for.  This variable is checked first. If it is not set, BORG_PASSPHRASE and BORG_PASSCOMMAND will also be checked.  Main usecase for this is to fully automate borg change-passphrase.
BORG_DISPLAY_PASSPHRASE When set, use the value to answer the "display the passphrase for verification" question when defining a new passphrase for encrypted repositories.
BORG_HOSTNAME_IS_UNIQUE=no Borg assumes that it can derive a unique hostname / identity (see borg debug info).  If this is not the case or you do not want Borg to automatically remove stale locks, set this to no.
BORG_HOST_ID Borg usually computes a host id from the FQDN plus the results of uuid.getnode() (which usually returns a unique id based on the MAC address of the network interface. Except if that MAC happens to be all-zero - in that case it returns a random value, which is not what we want (because it kills automatic stale lock removal).  So, if you have a all-zero MAC address or other reasons to better externally control the host id, just set this environment variable to a unique value. If all your FQDNs are unique, you can just use the FQDN. If not, use fqdn@uniqueid.
BORG_LOGGING_CONF When set, use the given filename as INI-style logging configuration.  A basic example conf can be found at docs/misc/logging.conf.
BORG_RSH When set, use this command instead of ssh. This can be used to specify ssh options, such as a custom identity file ssh -i /path/to/private/key. See man ssh for other options. Using the --rsh CMD commandline option overrides the environment variable.
BORG_REMOTE_PATH When set, use the given path as borg executable on the remote (defaults to "borg" if unset).  Using --remote-path PATH commandline option overrides the environment variable.
BORG_FILES_CACHE_SUFFIX When set to a value at least one character long, instructs borg to use a specifically named (based on the suffix) alternative files cache. This can be used to avoid loading and saving cache entries for backup sources other than the current sources.
BORG_FILES_CACHE_TTL When set to a numeric value, this determines the maximum "time to live" for the files cache entries (default: 20). The files cache is used to quickly determine whether a file is unchanged.  The FAQ explains this more detailed in: always_chunking
BORG_SHOW_SYSINFO When set to no (default: yes), system information (like OS, Python version, ...) in exceptions is not shown.  Please only use for good reasons as it makes issues harder to analyze.
BORG_LIBC borg uses ctypes.util.find_library to locate the 'c' library (aka libc).  find_library needs a shell and will invoke some tools like ldconfig, gcc/cc or objdump.  If a shell or these tools are not available, you can give the name of your libc via BORG_LIBC=libc.so.6 (for example) and borg will not try the find_library call.
BORG_SELFTEST This can be used to influence borg's builtin self-tests. The default is to execute the tests at the beginning of each borg command invocation.
BORG_SELFTEST=disabled can be used to switch off the tests and rather save some time.  Disabling is not recommended for normal borg users, but large scale borg storage providers can use this to optimize production servers after at least doing a one-time test borg (with selftests not disabled) when installing or upgrading machines / OS / borg.
BORG_WORKAROUNDS A list of comma separated strings that trigger workarounds in borg, e.g. to work around bugs in other software.
Currently known strings are:
basesyncfile Use the more simple BaseSyncFile code to avoid issues with sync_file_range.  You might need this to run borg on WSL (Windows Subsystem for Linux) or in systemd.nspawn containers on some architectures (e.g. ARM).  Using this does not affect data safety, but might result in a more bursty write to disk behaviour (not continuously streaming to disk).
Some automatic answerers (if set, they automatically answer confirmation questions):
BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK=no (or =yes) For "Warning: Attempting to access a previously unknown unencrypted repository"
BORG_RELOCATED_REPO_ACCESS_IS_OK=no (or =yes) For "Warning: The repository at location ... was previously located at ..."
BORG_CHECK_I_KNOW_WHAT_I_AM_DOING=NO (or =YES) For "This is a potentially dangerous function..." (check --repair)
BORG_DELETE_I_KNOW_WHAT_I_AM_DOING=NO (or =YES) For "You requested to completely DELETE the repository including all archives it contains:"
Note: answers are case sensitive. setting an invalid answer value might either give the default answer or ask you interactively, depending on whether retries are allowed (they by default are allowed). So please test your scripts interactively before making them a non-interactive script.
Directories and files:
BORG_BASE_DIR Defaults to $HOME or ~$USER or ~ (in that order).  If you want to move all borg-specific folders to a custom path at once, all you need to do is to modify BORG_BASE_DIR: the other paths for cache, config etc. will adapt accordingly (assuming you didn't set them to a different custom value).
BORG_CACHE_DIR Defaults to $BORG_BASE_DIR/.cache/borg. If BORG_BASE_DIR is not explicitly set while XDG env var XDG_CACHE_HOME is set, then $XDG_CACHE_HOME/borg is being used instead.  This directory contains the local cache and might need a lot of space for dealing with big repositories. Make sure you're aware of the associated security aspects of the cache location: cache_security
BORG_CONFIG_DIR Defaults to $BORG_BASE_DIR/.config/borg. If BORG_BASE_DIR is not explicitly set while XDG env var XDG_CONFIG_HOME is set, then $XDG_CONFIG_HOME/borg is being used instead. This directory contains all borg configuration directories, see the FAQ for a security advisory about the data in this directory: home_config_borg
BORG_SECURITY_DIR Defaults to $BORG_CONFIG_DIR/security.  This directory contains information borg uses to track its usage of NONCES ("numbers used once" - usually in encryption context) and other security relevant data.
BORG_KEYS_DIR Defaults to $BORG_CONFIG_DIR/keys.  This directory contains keys for encrypted repositories.
BORG_KEY_FILE When set, use the given filename as repository key file.
TMPDIR This is where temporary files are stored (might need a lot of temporary space for some operations), see tempfile for details.
Building:
BORG_OPENSSL_PREFIX Adds given OpenSSL header file directory to the default locations (setup.py).
BORG_LIBLZ4_PREFIX Adds given prefix directory to the default locations. If a 'include/lz4.h' is found Borg will be linked against the system liblz4 instead of a bundled implementation. (setup.py)
BORG_LIBB2_PREFIX Adds given prefix directory to the default locations. If a 'include/blake2.h' is found Borg will be linked against the system libb2 instead of a bundled implementation. (setup.py)
BORG_LIBZSTD_PREFIX Adds given prefix directory to the default locations. If a 'include/zstd.h' is found Borg will be linked against the system libzstd instead of a bundled implementation. (setup.py)
Please note:
• Be very careful when using the "yes" sayers, the warnings with prompt exist for your / your data's security/safety.
• Also be very careful when putting your passphrase into a script, make sure it has appropriate file permissions (e.g.  mode 600, root:root).
File systems We strongly recommend against using Borg (or any other database-like software) on non-journaling file systems like FAT, since it is not possible to assume any consistency in case of power failures (or a sudden disconnect of an external drive or similar failures).
While Borg uses a data store that is resilient against these failures when used on journaling file systems, it is not possible to guarantee this with some hardware -- independent of the software used. We don't know a list of affected hardware.
If you are suspicious whether your Borg repository is still consistent and readable after one of the failures mentioned above occurred, run borg check --verify-data to make sure it is consistent.  Requirements for Borg repository file systems.INDENT 0.0
• Long file names
• At least three directory levels with short names
• Typically, file sizes up to a few hundred MB.  Large repositories may require large files (>2 GB).
• Up to 1000 files per directory (10000 for repositories initialized with Borg 1.0)
• mkdir(2) should be atomic, since it is used for locking
• Hardlinks are needed for borg_upgrade (if --inplace option is not used).  Also hardlinks are used for more safe and secure file updating (e.g. of the repo config file), but the code tries to work also if hardlinks are not supported.
Units To display quantities, Borg takes care of respecting the usual conventions of scale. Disk sizes are displayed in decimal, using powers of ten (so kB means 1000 bytes). For memory usage, binary prefixes are used, and are indicated using the IEC binary prefixes, using powers of two (so KiB means 1024 bytes).
Date and Time We format date and time conforming to ISO-8601, that is: YYYY-MM-DD and HH:MM:SS (24h clock).
For more information about that, see: https://xkcd.com/1179/
Unless otherwise noted, we display local date and time.  Internally, we store and process date and time as UTC.
Resource Usage Borg might use a lot of resources depending on the size of the data set it is dealing with.
If one uses Borg in a client/server way (with a ssh: repository), the resource usage occurs in part on the client and in another part on the server.
If one uses Borg as a single process (with a filesystem repo), all the resource usage occurs in that one process, so just add up client + server to get the approximate resource usage.
CPU client:
• borg create: does chunking, hashing, compression, crypto (high CPU usage)
• chunks cache sync: quite heavy on CPU, doing lots of hashtable operations.
• borg extract: crypto, decompression (medium to high CPU usage)
• borg check: similar to extract, but depends on options given.
• borg prune / borg delete archive: low to medium CPU usage
• borg delete repo: done on the server
It won't go beyond 100% of 1 core as the code is currently single-threaded.  Especially higher zlib and lzma compression levels use significant amounts of CPU cycles. Crypto might be cheap on the CPU (if hardware accelerated) or expensive (if not).
CPU server: It usually doesn't need much CPU, it just deals with the key/value store (repository) and uses the repository index for that.
borg check: the repository check computes the checksums of all chunks (medium CPU usage) borg delete repo: low CPU usage
CPU (only for client/server operation): When using borg in a client/server way with a ssh:-type repo, the ssh processes used for the transport layer will need some CPU on the client and on the server due to the crypto they are doing - esp. if you are pumping big amounts of data.
Memory (RAM) client: The chunks index and the files index are read into memory for performance reasons. Might need big amounts of memory (see below). Compression, esp. lzma compression with high levels might need substantial amounts of memory.
Memory (RAM) server: The server process will load the repository index into memory. Might need considerable amounts of memory, but less than on the client (see below).
Chunks index (client only): Proportional to the amount of data chunks in your repo. Lots of chunks in your repo imply a big chunks index.  It is possible to tweak the chunker params (see create options).
Files index (client only): Proportional to the amount of files in your last backups. Can be switched off (see create options), but next backup might be much slower if you do.  The speed benefit of using the files cache is proportional to file size.
Repository index (server only): Proportional to the amount of data chunks in your repo. Lots of chunks in your repo imply a big repository index.  It is possible to tweak the chunker params (see create options) to influence the amount of chunks being created.
Temporary files (client): Reading data and metadata from a FUSE mounted repository will consume up to the size of all deduplicated, small chunks in the repository. Big chunks won't be locally cached.
Temporary files (server): A non-trivial amount of data will be stored on the remote temp directory for each client that connects to it. For some remotes, this can fill the default temporary directory at /tmp. This can be remediated by ensuring the $TMPDIR, $TEMP, or $TMP environment variable is properly set for the sshd process.  For some OSes, this can be done just by setting the correct value in the .bashrc (or equivalent login config file for other shells), however in other cases it may be necessary to first enable PermitUserEnvironment yes in your sshd_config file, then add environment="TMPDIR=/my/big/tmpdir" at the start of the public key to be used in the authorized_hosts file.
Cache files (client only): Contains the chunks index and files index (plus a collection of single- archive chunk indexes which might need huge amounts of disk space, depending on archive count and size - see FAQ about how to reduce).
Network (only for client/server operation): If your repository is remote, all deduplicated (and optionally compressed/ encrypted) data of course has to go over the connection (ssh:// repo url).  If you use a locally mounted network filesystem, additionally some copy operations used for transaction support also go over the connection. If you backup multiple sources to one target repository, additional traffic happens for cache resynchronization.
Support for file metadata Besides regular file and directory structures, Borg can preserve
• symlinks (stored as symlink, the symlink is not followed)
• special files:
• character and block device files (restored via mknod)
• FIFOs ("named pipes")
• special file contents can be backed up in --read-special mode.  By default the metadata to create them with mknod(2), mkfifo(2) etc. is stored.
• hardlinked regular files, devices, FIFOs (considering all items in the same archive)
• timestamps in nanosecond precision: mtime, atime, ctime
• other timestamps: birthtime (on platforms supporting it)
• permissions:
• IDs of owning user and owning group
• names of owning user and owning group (if the IDs can be resolved)
• Unix Mode/Permissions (u/g/o permissions, suid, sgid, sticky)
On some platforms additional features are supported:
┌─────────────────┬──────────┬───────────┬───────────┐ │Platform         │ ACLs [5] │ xattr [6] │ Flags [7] │ ├─────────────────┼──────────┼───────────┼───────────┤ │Linux            │ Yes      │ Yes       │ Yes [1]   │ ├─────────────────┼──────────┼───────────┼───────────┤ │Mac OS X         │ Yes      │ Yes       │ Yes (all) │ ├─────────────────┼──────────┼───────────┼───────────┤ │FreeBSD          │ Yes      │ Yes       │ Yes (all) │ ├─────────────────┼──────────┼───────────┼───────────┤ │OpenBSD          │ n/a      │ n/a       │ Yes (all) │ ├─────────────────┼──────────┼───────────┼───────────┤ │NetBSD           │ n/a      │ No [2]    │ Yes (all) │ ├─────────────────┼──────────┼───────────┼───────────┤ │Solaris and      │ No [3]   │ No [3]    │ n/a       │ │derivatives      │          │           │           │ ├─────────────────┼──────────┼───────────┼───────────┤ │Windows (cygwin) │ No [4]   │ No        │ No        │ └─────────────────┴──────────┴───────────┴───────────┘
Other Unix-like operating systems may work as well, but have not been tested at all.
Note that most of the platform-dependent features also depend on the file system.  For example, ntfs-3g on Linux isn't able to convey NTFS ACLs.
[1]  Only "nodump", "immutable", "compressed" and "append" are supported. Feature request #618 for more flags.
[2]  Feature request #1332
[3]  Feature request #1337
[4]  Cygwin tries to map NTFS ACLs to permissions with varying degrees of success.
[5]  The native access control list mechanism of the OS. This normally limits access to non-native ACLs. For example, NTFS ACLs aren't completely accessible on Linux with ntfs-3g.
[6]  extended attributes; key-value pairs attached to a file, mainly used by the OS.  This includes resource forks on Mac OS X.
[7]  aka BSD flags. The Linux set of flags [1] is portable across platforms.  The BSDs define additional flags.
borg-common(1) for common command line options
borg-init(1), borg-create(1), borg-mount(1), borg-extract(1), borg-list(1), borg-info(1), borg-delete(1), borg-prune(1), borg-recreate(1)
borg-compression(1), borg-patterns(1), borg-placeholders(1)
• Main web site https://www.borgbackup.org/
• Releases https://github.com/borgbackup/borg/releases
• Changelog https://github.com/borgbackup/borg/blob/master/docs/changes.rst
• GitHub https://github.com/borgbackup/borg
• Security contact https://borgbackup.readthedocs.io/en/latest/support.html#security-contact
The Borg Collective
VLC(1)                       General Commands Manual                      VLC(1)
vlc, qvlc, svlc, nvlc, rvlc, cvlc - the VLC media player
vlc [OPTIONS] [ITEMS]...
This manual page documents briefly the VLC multimedia player and server.
VLC follows the usual GNU command line syntax, with long options starting with two dashes (`-').  For a precise description of options, please use "vlc --help".
The complete list of VLC options depends on what plugins are installed because they automatically add their own options. Please use "vlc --longhelp --advanced" for a complete list of available options.
VLC recognizes several URL-style items:
*.mpg, *.vob, *.avi, *.mp3, *.ogg, *.opus Various multimedia file formats
dvd://[<device>][@<raw device>][#[<title>][:[<chapter>][:<angle>]]] DVD device (for instance dvd:///dev/dvd). The raw device is optional and must have been prepared beforehand.
vcd://[<device>][@{E|P|E|T|S}[<number>]] VCD device (for instance vcd:///dev/cdrom).
udp://[@[<multicast address>][:<local port>]] UDP stream, such as one sent by VLS or another VLC.  Usually "udp://" is enough.
http://<server address>[:<server port>]/[<file>] HTTP stream
rtsp://<server address>[:<server port>]/<stream name> RTSP Video On Demand stream
vlc://<command> Execute a playlist command. Commands are: pause (pause execution of other items), and quit (close VLC).
The following environment variables may affect VLC:
DISPLAY The X11 display server address.
http_proxy The HTTP proxy server URL.
OSSAUDIO_DEV The default audio output device, used by the OSSv4 output plugin.
VLC_DATA_PATH The directory containing VLC run-time data files (e.g. /usr/share/vlc).
VLC_PLUGIN_PATH An extra directory to load VLC plugins from.
VLC_VERBOSE The level of verbosity for log messages (0: silent, 1: error/info, 2: warning, 3: debug).
XDG_CACHE_DIR XDG_CONFIG_DIR XDG_DATA_DIR The directories to store user cached data, user configuration files and user data files respectively.
XDG_DOCUMENTS_DIR XDG_DOWNLOAD_DIR XDG_MUSIC_DIR XDG_PICTURES_DIR XDG_VIDEO_DIR The directories to fetch or store user text files, downloads, music, pictures (i.e. snapshots), and video respectively.
XDG_SESSION_COOKIE The unique identifier of the desktop session, used by the PulseAudio output plugin.
Online documentation: http://www.videolan.org/doc/
This manual page was written by Sam Hocevar <sam@zoy.org>, for the Debian GNU/Linux system (but may be used by others).
CUYO(6)                           Games Manual                           CUYO(6)
cuyo - Tetris-like game with many suprises
cuyo [-d] [-f] [-g widthxheight] [-h] [-?] [--version versions] [ld-file]
cuyo -?
Use A, D, W and S or the arrow keys to move left, move right, turn and drop the falling piece.  Try to put blobs of the same color together. (You don't need to form rows or columns.  Any shape will do.)  When enough blobs of the same color are connected, they explode.  (What "enough" means depends on the level.)  Try to make explosions next to the the grass (or whatever there is in the level instead of the grass). Then, it will explode, too.  The level is finished when no grass is left. In some levels, you will need a chain reaction to get rid of the grass- equivalent.  And many other things may happen in other levels. In two-player-mode, each time one player causes an explosion, the other one gets grey things (which explode when something else explodes next to them).  If one player builds a too big tower, the other player may get one of his rows.
-d     Debug mode.
-f     Fullscreen mode.
-g widthxheight Set the window size.
-h     Print a short help message and exit with status 0.
-?     Print a short help message and exit with status 1.
--version versions, --version=versions Activate special versions of levels and level tracks.  versions is a comma-separated list of version specifiers.  Version specifiers pertaining to difficulty setting, numbers of players, and level tracks can also be set from the main menu.  See the cual(6) manpage for the relevant values.  The other version specifiers which are actually used in levels are eco and geek.
eco makes a very few levels less resource-hungry.  In the consequence, they also become less beautiful.
If you're trying to design own levels, you can pass the name of your .ld file (level description file) to test the level.  If you do that, this will be the only available level.
The main work is to draw all those little icons.  Then you have to create a level description file which tells cuyo how to put everything together. There is an example level with many comments.  Its description file is example.ld.  (It should be part of the cuyo distribution and probably lies in the same directory as the other cuyo level description files.) It is rather outdated but may still be a good starting point.
Other Sources of information are:
- Try man cual.  Cual - the Cuyo Animation Language - is the format of level description files.
- And of course, there are the level description files of the existing levels (files ending in .ld, probably located somewhere like /usr/share/games/cuyo/).
cual(6)
The level description language is still under development. In the preferences dialog, some keys are not displayed correctly. The AI Player is not very intelligent.  In particular, it doesn't understand most of the special features of the levels, and so, it sometimes behaves very silly. See the TODO file for other bugs.
Mainly Immanuel Halupczok <cuyo@karimmi.de>. Other contributors to the source code: Bernhard R. Link, Mark Weyer, Bernhard Seckinger. Other contributors of levels: Daniela Lipps, Simon Huggenberger.
B2SUM(1)                          User Commands                         B2SUM(1)
b2sum - compute and check BLAKE2 message digest
b2sum [OPTION]... [FILE]...
Print or check BLAKE2b (512-bit) checksums.
The sums are computed as described in RFC 7693.  When checking, the input should be a former output of this program.  The default mode is to print a line with: checksum, a space, a character indicating input mode ('*' for binary, ' ' for text or where binary is insignificant), and name for each FILE.
Written by Padraig Brady and Samuel Neves.
Full documentation <https://www.gnu.org/software/coreutils/b2sum> or available locally via: info '(coreutils) b2sum invocation'
VIRTUALENV(1)                      virtualenv                      VIRTUALENV(1)
virtualenv - virtualenv 20.8.0 Latest version on PyPI[image: PyPI - Implementation] [image] [image: PyPI - Python Version] [image] Documentation statusDiscordPyPI - DownloadsPyPI - LicenseOpen issuesOpen pull requestsPackage popularity
virtualenv is a tool to create isolated Python environments. Since Python 3.3, a subset of it has been integrated into the standard library under the venv module. The venv module does not offer all features of this library, to name just a few more prominent:
• is slower (by not having the app-data seed method),
• is not as extendable,
• cannot create virtual environments for arbitrarily installed python versions (and automatically discover these),
• is not upgrade-able via pip,
• does not have as rich programmatic API (describe virtual environments without creating them).
The basic problem being addressed is one of dependencies and versions, and indirectly permissions.  Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these libraries? If you install everything into your host python (e.g. python3.8) it's easy to end up in a situation where two packages have conflicting requirements.
Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application. Also, what if you can't install packages into the global site-packages directory, due to not having permissions to change the host python environment?
In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't access the globally installed libraries either).
Related projects, that build abstractions on top of virtualenv
• virtualenvwrapper - a useful set of scripts for creating and deleting virtual environments
• pew - provides a set of commands to manage multiple virtual environments
• tox - a generic virtualenv management and test automation command line tool, driven by a tox.ini configuration file
• nox - a tool that automates testing in multiple Python environments, similar to tox, driven by a noxfile.py configuration file
• Corey Schafer tutorial on how to use it
• Using virtualenv with mod_wsgi
Presenting how the package works from within
• Bernat Gabor: status quo of virtual environments
• Carl Meyer: Reverse-engineering Ian Bicking's brain: inside pip and virtualenv
Installation via pipx virtualenv is a CLI tool that needs a Python interpreter to run. If you already have a Python 3.5+ interpreter the best is to use pipx to install virtualenv into an isolated environment. This has the added benefit that later you'll be able to upgrade virtualenv without affecting other parts of the system.
pipx install virtualenv virtualenv --help
via pip Alternatively you can install it within the global Python interpreter itself (perhaps as a user package via the --user flag). Be cautious if you are using a python install that is managed by your operating system or another package manager. pip might not coordinate with those tools, and may leave your system in an inconsistent state. Note, if you go down this path you need to ensure pip is new enough per the subsections below:
python -m pip install --user virtualenv python -m virtualenv --help
wheel Installing virtualenv via a wheel (default with pip) requires an installer that can understand the python-requires tag (see PEP-503), with pip this is version 9.0.0 (released 2016 November). Furthermore, in case you're not installing it via the PyPi you need to be using a mirror that correctly forwards the python-requires tag (notably the OpenStack mirrors don't do this, or older devpi versions - added with version 4.7.0).
sdist When installing via a source distribution you need an installer that handles the PEP-517 specification. In case of pip this is version 18.0.0 or later (released on 2018 July). If you cannot upgrade your pip to support this you need to ensure that the build requirements from pyproject.toml are satisfied before triggering the install.
via zipapp You can use virtualenv without installing it too. We publish a Python zipapp, you can just download this from https://bootstrap.pypa.io/virtualenv.pyz and invoke this package with a python interpreter:
python virtualenv.pyz --help
The root level zipapp is always the current latest release. To get the last supported zipapp against a given python minor release use the link https://bootstrap.pypa.io/virtualenv/x.y/virtualenv.pyz, e.g. for the last virtualenv supporting Python 2.7 use https://bootstrap.pypa.io/virtualenv/2.7/virtualenv.pyz.
If you are looking for past version of virtualenv.pyz they are available here: https://github.com/pypa/get-virtualenv/blob/<virtualenv version>/public/<python version>/virtualenv.pyz?raw=true
via setup.py We don't recommend and officially support this method. One should prefer using an installer that supports PEP-517 interface, such as pip 19.0.0 or later. That being said you might be able to still install a package via this method if you satisfy build dependencies before calling the install command (as described under sdist).
latest unreleased Installing an unreleased version is discouraged and should be only done for testing purposes. If you do so you'll need a pip version of at least 18.0.0 and use the following command:
pip install git+https://github.com/pypa/virtualenv.git@main
Python and OS Compatibility virtualenv works with the following Python interpreter implementations:
• CPython versions 2.7, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10
• PyPy 2.7 and 3.5+.
This means virtualenv works on the latest patch version of each of these minor versions. Previous patch versions are supported on a best effort approach.
CPython is shipped in multiple forms, and each OS repackages it, often applying some customization along the way.  Therefore we cannot say universally that we support all platforms, but rather specify some we test against. In case of ones not specified here the support is unknown, though likely will work. If you find some cases please open a feature request on our issue tracker.
Linux • installations from python.org
• Ubuntu 16.04+ (both upstream and deadsnakes builds)
• Fedora
• RHEL and CentOS
• OpenSuse
• Arch Linux
macOS In case of macOS we support:
• installations from python.org
• python versions installed via brew (both older python2.7 and python3)
• Python 3 part of XCode (Python framework - /Library/Frameworks/Python3.framework/)
• Python 2 part of the OS (/System/Library/Frameworks/Python.framework/Versions/)
Windows • Installations from python.org
• Windows Store Python - note only version 3.7+
Packaging variants • Normal variant (file structure as comes from python.org).
• We support CPython 2 system installations that do not contain the python files for the standard library if the respective compiled files are present (e.g. only os.pyc, not os.py). This can be used by custom systems may want to maximize available storage or obfuscate source code by removing .py files.
User Guide Introduction Virtualenv has one basic command:
virtualenv venv
This will create a python virtual environment of the same version as virtualenv, installed into the subdirectory venv. The command line tool has quite a few of flags that modify the tool's behaviour, for a full list make sure to check out cli_flags.
The tool works in two phases:
• Phase 1 discovers a python interpreter to create a virtual environment from (by default this is the same python as the one virtualenv is running from, however we can change this via the p option).
• Phase 2 creates a virtual environment at the specified destination (dest), this can be broken down into four further sub-steps:
• create a python that matches the target python interpreter from phase 1,
• install (bootstrap) seed packages (one or more of pip, setuptools, wheel) in the created virtual environment,
• install activation scripts into the binary directory of the virtual environment (these will allow end users to activate the virtual environment from various shells).
• create files that mark the virtual environment as to be ignored by version control systems (currently we support Git only, as Mercurial, Bazaar or SVN do not support ignore files in subdirectories). This step can be skipped with the no-vcs-ignore option.
The python in your new virtualenv is effectively isolated from the python that was used to create it.
Python discovery The first thing we need to be able to create a virtual environment is a python interpreter. This will describe to the tool what type of virtual environment you would like to create, think of it as: version, architecture, implementation.
virtualenv being a python application has always at least one such available, the one virtualenv itself is using, and as such this is the default discovered element. This means that if you install virtualenv under python 3.8, virtualenv will by default create virtual environments that are also of version 3.8.
Created python virtual environments are usually not self-contained. A complete python packaging is usually made up of thousands of files, so it's not efficient to install the entire python again into a new folder. Instead virtual environments are mere shells, that contain little within themselves, and borrow most from the system python (this is what you installed, when you installed python itself). This does mean that if you upgrade your system python your virtual environments might break, so watch out. The upside of this, referring to the system python, is that creating virtual environments can be fast.
Here we'll describe the built-in mechanism (note this can be extended though by plugins). The CLI flag p or python allows you to specify a python specifier for what type of virtual environment you would like, the format is either:
• a relative/absolute path to a Python interpreter,
• a specifier identifying the Python implementation, version, architecture in the following format:
{python implementation name}{version}{architecture}
We have the following restrictions:
• the python implementation is all alphabetic characters (python means any implementation, and if is missing it defaults to python),
• the version is a dot separated version number,
• the architecture is either -64 or -32 (missing means any).
• python3.8.1 means any python implementation having the version 3.8.1,
• 3 means any python implementation having the major version 3,
• cpython3 means a CPython implementation having the version 3,
• pypy2 means a python interpreter with the PyPy implementation and major version 2.
Given the specifier virtualenv will apply the following strategy to discover/find the system executable:
• If we're on Windows look into the Windows registry, and check if we see any registered Python implementations that match the specification. This is in line with expectation laid out inside PEP-514
• Try to discover a matching python executable within the folders enumerated on the PATH environment variable.  In this case we'll try to find an executable that has a name roughly similar to the specification (for exact logic, please see the implementation code).
WARNING: As detailed above, virtual environments usually just borrow things from the system Python, they don't actually contain all the data from the system Python. The version of the python executable is hardcoded within the python exe itself.  Therefore, if you upgrade your system Python, your virtual environment will still report the version before the upgrade, even though now other than the executable all additional content (standard library, binary libs, etc) are of the new version.
Barring any major incompatibilities (rarely the case) the virtual environment will continue working, but other than the content embedded within the python executable it will behave like the upgraded version. If such a virtual environment python is specified as the target python interpreter, we will create virtual environments that match the new system Python version, not the version reported by the virtual environment.
Creators These are what actually setup the virtual environment, usually as a reference against the system python. virtualenv at the moment has two types of virtual environments:
• venv - this delegates the creation process towards the venv module, as described in PEP 405. This is only available on Python interpreters having version 3.5 or later, and also has the downside that virtualenv must create a process to invoke that module (unless virtualenv is installed in the system python), which can be an expensive operation (especially true on Windows).
• builtin - this means virtualenv is able to do the creation operation itself (by knowing exactly what files to create and what system files need to be referenced). The creator with name builtin is an alias on the first creator that's of this type (we provide creators for various target environments, that all differ in actual create operations, such as CPython 2 on Windows, PyPy2 on Windows, CPython3 on Posix, PyPy3 on Posix, and so on; for a full list see creator).
Seeders These will install for you some seed packages (one or more of: pip, setuptools, wheel) that enables you to install additional python packages into the created virtual environment (by invoking pip). There are two main seed mechanism available:
• pip - this method uses the bundled pip with virtualenv to install the seed packages (note, a new child process needs to be created to do this, which can be expensive especially on Windows).
• app-data - this method uses the user application data directory to create install images. These images are needed to be created only once, and subsequent virtual environments can just link/copy those images into their pure python library path (the site-packages folder). This allows all but the first virtual environment creation to be blazing fast (a pip mechanism takes usually 98% of the virtualenv creation time, so by creating this install image that we can just link into the virtual environments install directory we can achieve speedups of shaving the initial 1 minute and 10 seconds down to just 8 seconds in case of a copy, or 0.8 seconds in case symlinks are available - this is on Windows, Linux/macOS with symlinks this can be as low as 100ms from 3+ seconds).  To override the filesystem location of the seed cache, one can use the VIRTUALENV_OVERRIDE_APP_DATA environment variable.
Wheels To install a seed package via either pip or app-data method virtualenv needs to acquire a wheel of the target package. These wheels may be acquired from multiple locations as follows:
• virtualenv ships out of box with a set of embed wheels for all three seed packages (pip, setuptools, wheel). These are packaged together with the virtualenv source files, and only change upon upgrading virtualenv. Different Python versions require different versions of these, and because virtualenv supports a wide range of Python versions, the number of embedded wheels out of box is greater than 3. Whenever newer versions of these embedded packages are released upstream virtualenv project upgrades them, and does a new release. Therefore, upgrading virtualenv periodically will also upgrade the version of the seed packages.