neulab/tldr huggingface dataset:
none   Logs nothing. Suitable for debugging or checking the exit code.
LinkChecker accepts Python regular expressions. See https://docs.python.org/howto/regex.html for an introduction.  An addition is that a leading exclamation mark negates the regular expression.
A cookie file contains standard HTTP header (RFC 2616) data with the following possible names:
Host (required) Sets the domain the cookies are valid for.
Path (optional) Gives the path the cookies are value for; default path is /.
Set-cookie (required) Set cookie name/value. Can be given more than once.
Multiple entries are separated by a blank line. The example below will send two cookies to all URLs starting with http://example.com/hello/ and one to all URLs starting with https://example.org/:
Host: example.com Path: /hello Set-cookie: ID="smee" Set-cookie: spam="egg"
Host: example.org Set-cookie: baggage="elitist"; comment="hologram"
To use a proxy on Unix or Windows set the http_proxy, https_proxy or ftp_proxy environment variables to the proxy URL. The URL should be of the form http://[user:pass@]host[:port].  LinkChecker also detects manual proxy settings of Internet Explorer under Windows systems, and GNOME or KDE on Linux systems. On a Mac use the Internet Config to select a proxy. You can also set a comma-separated domain list in the no_proxy environment variables to ignore any proxy settings for these domains.
Setting a HTTP proxy on Unix for example looks like this:
$ export http_proxy="http://proxy.example.com:8080"
Proxy authentication is also supported:
$ export http_proxy="http://user1:mypass@proxy.example.org:8081"
Setting a proxy on the Windows command prompt:
C:\> set http_proxy=http://proxy.example.com:8080
All URLs have to pass a preliminary syntax test. Minor quoting mistakes will issue a warning, all other invalid syntax issues are errors. After the syntax check passes, the URL is queued for connection checking. All connection check types are described below.
HTTP links (http:, https:) After connecting to the given HTTP server the given path or query is requested. All redirections are followed, and if user/password is given it will be used as authorization when necessary. All final HTTP status codes other than 2xx are errors.
HTML page contents are checked for recursion.
Local files (file:) A regular, readable file that can be opened is valid. A readable directory is also valid. All other files, for example device files, unreadable or non-existing files are errors.
HTML or other parseable file contents are checked for recursion.
Mail links (mailto:) A mailto: link eventually resolves to a list of email addresses. If one address fails, the whole list will fail. For each mail address we check the following things:
1. Check the address syntax, both the parts before and after the @ sign.
2. Look up the MX DNS records. If we found no MX record, print an error.
3. Check if one of the mail hosts accept an SMTP connection. Check hosts with higher priority first. If no host accepts SMTP, we print a warning.
4. Try to verify the address with the VRFY command. If we got an answer, print the verified address as an info.
FTP links (ftp:) For FTP links we do:
1. connect to the specified host
2. try to login with the given user and password. The default user is anonymous, the default password is anonymous@.
3. try to change to the given directory
4. list the file with the NLST command
Telnet links (telnet:) We try to connect and if user/password are given, login to the given telnet server.
NNTP links (news:, snews:, nntp) We try to connect to the given NNTP server. If a news group or article is specified, try to request it from the server.
Unsupported links (javascript:, etc.) An unsupported link will only print a warning. No further checking will be made.
The complete list of recognized, but unsupported links can be found in the linkcheck/checker/unknownurl.py source file. The most prominent of them should be JavaScript links.
There are two plugin types: connection and content plugins. Connection plugins are run after a successful connection to the URL host. Content plugins are run if the URL type has content (mailto: URLs have no content for example) and if the check is not forbidden (ie. by HTTP robots.txt). Use the option --list-plugins for a list of plugins and their documentation. All plugins are enabled via the linkcheckerrc(5) configuration file.
Before descending recursively into a URL, it has to fulfill several conditions. They are checked in this order:
1. A URL must be valid.
2. A URL must be parseable. This currently includes HTML files, Opera bookmarks files, and directories. If a file type cannot be determined (for example it does not have a common HTML file extension, and the content does not look like HTML), it is assumed to be non-parseable.
3. The URL content must be retrievable. This is usually the case except for example mailto: or unknown URL types.
4. The maximum recursion level must not be exceeded. It is configured with the --recursion-level option and is unlimited per default.
5. It must not match the ignored URL list. This is controlled with the --ignore-url option.
6. The Robots Exclusion Protocol must allow links in the URL to be followed recursively. This is checked by searching for a "nofollow" directive in the HTML header data.
Note that the directory recursion reads all files in that directory, not just a subset like index.htm.
URLs on the commandline starting with ftp. are treated like ftp://ftp., URLs starting with www. are treated like http://www.. You can also give local files as arguments.  If you have your system configured to automatically establish a connection to the internet (e.g. with diald), it will connect when checking links not pointing to your local host. Use the --ignore-url option to prevent this.
Javascript links are not supported.
If your platform does not support threading, LinkChecker disables it automatically.
You can supply multiple user/password pairs in a configuration file.
When checking news: links the given NNTP host doesn't need to be the same as the host of the user browsing your pages.
NNTP_SERVER specifies default NNTP server
http_proxy specifies default HTTP proxy server
ftp_proxy specifies default FTP proxy server
no_proxy comma-separated list of domains to not contact over a proxy server
LC_MESSAGES, LANG, LANGUAGE specify output language
The return value is 2 when
• a program error occurred.
The return value is 1 when
• invalid links were found or
• link warnings were found and warnings are enabled
Else the return value is zero.
LinkChecker consumes memory for each queued URL to check. With thousands of queued URLs the amount of consumed memory can become quite large. This might slow down the program or even the whole system.
~/.linkchecker/linkcheckerrc - default configuration file
~/.linkchecker/failures - default failures logger output filename
linkchecker-out.TYPE - default logger file output name
linkcheckerrc(5)
https://docs.python.org/library/codecs.html#standard-encodings - valid output encodings
https://docs.python.org/howto/regex.html - regular expression documentation
Bastian Kleineidam <bastian.kleineidam@web.de>
2000-2016 Bastian Kleineidam, 2010-2021 LinkChecker Authors
E2LABEL(8)                   System Manager's Manual                  E2LABEL(8)
e2label - Change the label on an ext2/ext3/ext4 file system
e2label device [ volume-label ]
e2label will display or change the volume label on the ext2, ext3, or ext4 file system located on device.
If the optional argument volume-label is not present, e2label will simply display the current volume label.
If the optional argument volume-label is present, then e2label will set the volume label to be volume-label.  Ext2 volume labels can be at most 16 characters long; if volume-label is longer than 16 characters, e2label will truncate it and print a warning message.
It is also possible to set the volume label using the -L option of tune2fs(8).
e2label was written by Theodore Ts'o (tytso@mit.edu).
e2label is part of the e2fsprogs package and is available from http://e2fsprogs.sourceforge.net.
mke2fs(8), tune2fs(8)
GIT-CONTRIB(1)                     Git Extras                     GIT-CONTRIB(1)
git-contrib - Show user´s contributions
git-contrib [<username>|<email>]
Output a user´s contributions to a project, based on the author name or email. Returns multiple entries if there are more than one match.
The name or email of the user who owns the contributions.
Searching with a username
$ git contrib visionmedia visionmedia (18): Export STATUS_CODES Moved help msg to node-repl Added multiple arg support for sys.puts(), print(), etc. Fix stack output on socket error `...`
Searching with a partial email
$ git contrib tj@ visionmedia (18): Export STATUS_CODES Moved help msg to node-repl Added multiple arg support for sys.puts(), print(), etc. Fix stack output on socket error ...
DRUSH(1)                     General Commands Manual                    DRUSH(1)
drush - shell scripting interface for Drupal
drush [options] command...
drush is a veritable Swiss Army knife designed to make life easier for those of us who spend some of our working hours hacking away at the command prompt.
Drush core ships with lots of useful commands for interacting with code like modules/themes/profiles. Similarly, it runs update.php, executes sql queries and DB migrations, and misc utilities like run cron or clear cache.
-r path, --root=path Drupal root directory to use (default: current directory)
-l uri, --uri=uri URI of the drupal site to use (only needed in multisite environments)
-v, --verbose Display extra information about the command.
-q, --quiet Hide all output
-d, --debug Display even more information, including internal messages.
-y, --yes Assume 'yes' as answer to all prompts
-s, --simulate Simulate all relevant actions (don't actually change the system)
-p, --pipe Emit a compact representation of the command for scripting.
-h, --help A detailed help system, use drush help help for complete help.
--version Show drush version.
If you get tired of typing options all the time, you can add them to your drush.php alias or create a drushrc.php file. These provide additional options for your drush call. They provide great flexibility for a multi- site installation, for example. See example.drushrc.php.
Drush is all based around "commands" that are usually defined in various modules.
help   Print the help message. Use --filter to limit command list to one command file (e.g. --filter=pm).
cache-clear (cc) Clear a specific cache, or all drupal caches.
core-cli (cli) Enter a new shell optimized for Drush use.
core-cron (cron) Run all cron hooks.
core-status (st) Provides a birds-eye view of the current Drupal installation, if any.
php-eval (eval) Evaluate arbitrary php code after bootstrapping Drupal.
updatedb (updb) Apply any database updates required (as with running update.php).
variable-get (vget) Get a list of some or all site variables and values
variable-set (vset) Set a variable.
watchdog show Shows recent watchdog log messages. Optionally filter for a specific type.
pm-enable (en) Enable one or more extensions (modules or themes).
pm-disable (dis) Disable one or more extensions (modules or themes).
pm-download (dl) Download projects from drupal.org or other sources.
pm-uninstall Uninstall one or more modules.
pm-updatecode (upc) Update Drupal core and contrib projects to latest recommended releases.
pm-update (up) Update Drupal core and contrib projects and apply any pending database updates (Same as pm-updatecode + updatedb).
sql-cli (sqlc) Open a SQL command-line interface using Drupal's credentials.
sql-connect A string for connecting to the DB.
sql-dump Exports the Drupal DB as SQL using mysqldump.
This manual only lists a few of the most frequently used builtin commands shipped with the Drush core, since other Drupal modules and third-party "command files" may extend this list significantly. The canonical source of information for the available commands and their usage is the online help system.
More information on each command is also available through drush help <command>. Most commands have shortcuts indicated in parenthesis.
/etc/drush/drushrc.php /usr/share/doc/drush/examples/example.drushrc.php
cvs(1), svn(1), wget(1).
Drush was originally developed by Arto for Drupal 4.7 (this alpha code can still be found in the DRUPAL-4-7 branch). In May 2007, it was partly rewritten and redesigned for Drupal 5 by frando. Since 2008, the module has been maintained by Moshe Weitzman, Owen Barton and Adrian Rossouw.
This manual page was written by Antoine BeauprÃ© <anarcat@debian.org> in June 2009 for the Debian project (but may be used by others).
LEININGEN(1)                 General Commands Manual                LEININGEN(1)
lein - Automate Clojure projects
lein [-o] [-U] [TASK [ARGS]] lein [-h|--help] lein [-v|--version]
Leiningen is for automating Clojure projects without setting your hair on fire.
Working on Clojure projects with tools designed for Java can be an exercise in frustration. With Leiningen, you just write Clojure.
lein help will show the complete list of tasks, while lein help TASK shows usage for a specific one.
lein help tutorial has a detailed walk-through of the various tasks, but the most commonly-used are:
lein new NAME generate a new project skeleton
lein test [TESTS] run the tests in the TESTS namespaces, or all tests
lein repl launch an interactive REPL session in a networked REPL server
lein uberjar package up the project and its dependencies as a standalone .jar file
lein install install a project into your local repository
lein deploy [REPOSITORY] deploy a library to a remote repository
Other tasks available include:
lein change Rewrite project.clj by applying a function.
lein check Check syntax and warn on reflection.
lein classpath Print the classpath of the current project.
lein clean Remove all files from project's target-path.
lein compile Compile Clojure source into .class files.
lein deps Download all dependencies.
lein do [TASK], ... Higher-order task to perform other tasks in succession.
lein jar Package up all the project's files into a jar file.
lein javac Compile Java source files.
lein pom Write a pom.xml file to disk for Maven interoperability.
lein release Perform :release-tasks.
lein retest Run only the test namespaces which failed last time around.
lein run Run a -main function with optional command-line arguments.
lein search Search remote maven repositories for matching jars.
lein show-profiles List all available profiles or display one if given an argument.
lein trampoline [TASK] Run a task without nesting the project's JVM inside Leiningen's.
lein update-in Perform arbitrary transformations on your project map.
lein vcs Interact with the version control system.
lein version Print version for Leiningen and the current JVM.
lein with-profile [PROFILE] [TASK] Apply the given task with the profile(s) specified.
-o     Run a task offline.
-U     Run a task after forcing update of snapshots.
-h, --help Print this help or help for a specific task.
-v, --version Print Leiningen's version.
Leiningen reads its configuration from the project.clj file in your project root. Either use lein new to create a fresh project from which to work, or see the exhaustive list of configuration options with lein help sample.
You can customize your project map further with profiles; see lein help profiles.
Check https://github.com/technomancy/leiningen/issues to see if your problem is a known issue. If not, please open a new issue on that site. Please include the output of lein version as well as your project.clj file and as much of the relevant code from your project as possible.
Copyright (C) 2009-2017 Phil Hagelberg and contributors.
Distributed under the Eclipse Public License, the same as Clojure uses. See the file /usr/share/doc/leiningen/copyright.
This manpage is written by Phil Hagelberg <technomancy@gmail.com>
STRIP-NONDETERMINISM(1)User Contributed Perl DocumentatioSTRIP-NONDETERMINISM(1)
strip-nondeterminism - strip nondeterministic information from files
strip-nondeterminism [-t filetype] filename ...
strip-nondeterminism is a tool to strip bits of nondeterministic information, such as timestamps, from files.  It can be used as a post- processing step to make a build reproducible, when the build process itself cannot be made deterministic.
-t filetype, --type filetype Use the normalizer for the given file type (ar, gzip, jar, zip).  If this option is not specified, the file type is detected automatically based on the file name extension.
-T seconds, --timestamp seconds Instead of stripping timestamps from files, set them to the given number of seconds since January 1, 1970.
--clamp-timestamp Only replace timestamps if they are later than the time specified to --timestamp.  You can use this option to ensure that only timestamps introduced as part of the build process are replaced.  NOT YET IMPLEMENTED FOR ALL FILE FORMATS.
--normalizers SPEC Enable or disable specific normalizers separated by a comma (eg. +foo,-bar.  The magic values +all and -all will enable and disable all normalizers.
-h, --help Display this help message.
-V, --version Print only the version string and then quit.
Andrew Ayer Chris Lamb
strip-nondeterminism is free software.  You can redistribute it and/or modify it under the terms of the GNU General Public License, version 3.
Xdelta(1)                    General Commands Manual                   Xdelta(1)
xdelta - Invoke Xdelta
xdelta subcommand [ option...  ] [ operand...  ]
Xdelta provides the ability to generate deltas between a pair of files and later apply those deltas.  It operates similar to the diff and patch commands, but works on binary files and does not produce a human readable output.
Xdelta has three subcommands, delta, patch, and info.  Delta accepts two file versions and produces a delta, while patch accepts the original file version and delta and produces the second version.  The info command prints useful information about a delta.  Each subcommand will be detailed seperately.
Gzip processing Attempting to compute a delta between compressed input files usually results in poor compression.  This is because small differences between the original contents causes changes in the compression of whole blocks of data.  To simplify things, Xdelta implements a special case for gzip(1) compressed files.  If any version input to the delta command is recognized as having gzip compression, it will be automatically decompressed into a temporary location prior to comparison.  This temporary location is either the value of the TMPDIR environment variable, if set, otherwise "/tmp".
The Xdelta patch header contains a flag indicating that the reconstructed version should be recompressed after applying the patch.  In general, this allows Xdelta to operate transparently on gzip compressed inputs.
There is one potential problem when automatically processing gzip compressed files, which is that the recompressed content does not always match byte-for-byte with the original compressed content.  The uncompressed content still matches, but if there is an external integrity check such as cryptographic signature verification, it may fail.  To prevent this from happening, the --pristine option disables automatic gzip processing.
MD5 integrity check By default, Xdelta always verifies the MD5 checksum of the files it reconstructs.  This prevents you from supplying an incorrect input during patch, which would result in corrupt output.  Because of this feature, you can feel confident that patch has produced valid results.  The --noverify option disables MD5 verification, but this is only recommended for performance testing.
Compressed patch format Xdelta uses a fairly simple encoding for its delta, then applies zlib compression to the result.  You should not have to post-compress an Xdelta delta.
Delta The delta subcommand has the following synopsis:
xdelta delta [ option...  ] fromfile tofile patchout
Computes a delta from fromfile to tofile and writes it to patchout
Patch The patch subcommand has the following synopsis:
xdelta patch [ option...  ] patchin [ fromfile [ tofile ]]
Applies patchin to fromfile and produces a reconstructed version of tofile.
If fromfile was omitted, Xdelta attempts to use the original fromfile name, which is stored in the delta.  The from file must be identical to the one used to create the delta.  If its length or MD5 checksum differs, patch will abort with an error message.
If tofile was omitted, Xdelta attempts to use the original tofile name, which is also stored in the delta.  If the original tofile name already exists, a unique filename extension will be added to avoid destroying any existing data.
Info The info subcommand has the following synopsis:
xdelta info patchinfo
Prints information about patchinfo and the version it reconstructs, including file names, lengths, and MD5 checksums.
Options -0..9  Set the zlib compression level.  Zero indicates no compression. Nine indicates maximum compression.
-h, --help Print a short help message and exit.
-q, --quiet Quiet.  Surpresses several warning messages.
-v, --version Print the Xdelta version number and exit.
-V, --verbose Verbose.  Prints a bit of extra information.
-n, --noverify No verify.  Turns off MD5 checksum verification of the input and output files.
-m=SIZE, --maxmem=SIZE Set an upper bound on the size of an in-memory page cache.  For example, --maxmem=32M will use a 32 megabyte page cache.
-s=BLOCK_SIZE Set the block size, unless it was hard coded (20% speed improvement).  Should be a power of 2.
-p, --pristine Disable the automatic decompression of gzipped inputs, to prevent unexpected differences in the re-compressed content.
The delta command exits with status 0 to indicate that no differences were found, with status 1 to indicate that some differences were found, and with status 2 to indicate an error of some kind.  The patch and info commands exit with status 0 on success and 2 on failure.
Author: Joshua P. MacDonald, jmacd@cs.berkeley.edu Manual Page Revision: 1.6; Release Date: Sun, 28 Jan 2007 12:21:11 -0800. Copyright Â© 1997, 1998, 1999, 2000, 2001
GIT-DESCRIBE(1)                    Git Manual                    GIT-DESCRIBE(1)
git-describe - Give an object a human readable name based on an available ref
git describe [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>...] git describe [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>] git describe <blob>
The command finds the most recent tag that is reachable from a commit. If the tag points to the commit, then only the tag is shown. Otherwise, it suffixes the tag name with the number of additional commits on top of the tagged object and the abbreviated object name of the most recent commit. The result is a "human-readable" object name which can also be used to identify the commit to other git commands.
By default (without --all or --tags) git describe only shows annotated tags. For more information about creating annotated tags see the -a and -s options to git-tag(1).
If the given object refers to a blob, it will be described as <commit-ish>:<path>, such that the blob can be found at <path> in the <commit-ish>, which itself describes the first commit in which this blob occurs in a reverse revision walk from HEAD.
<commit-ish>... Commit-ish object names to describe. Defaults to HEAD if omitted.
--dirty[=<mark>], --broken[=<mark>] Describe the state of the working tree. When the working tree matches HEAD, the output is the same as "git describe HEAD". If the working tree has local modification "-dirty" is appended to it. If a repository is corrupt and Git cannot determine if there is local modification, Git will error out, unless ‘--broken’ is given, which appends the suffix "-broken" instead.
--all Instead of using only the annotated tags, use any ref found in refs/ namespace. This option enables matching any known branch, remote-tracking branch, or lightweight tag.
--tags Instead of using only the annotated tags, use any tag found in refs/tags namespace. This option enables matching a lightweight (non-annotated) tag.
--contains Instead of finding the tag that predates the commit, find the tag that comes after the commit, and thus contains it. Automatically implies --tags.
--abbrev=<n> Instead of using the default number of hexadecimal digits (which will vary according to the number of objects in the repository with a default of 7) of the abbreviated object name, use <n> digits, or as many digits as needed to form a unique object name. An <n> of 0 will suppress long format, only showing the closest tag.
--candidates=<n> Instead of considering only the 10 most recent tags as candidates to describe the input commit-ish consider up to <n> candidates. Increasing <n> above 10 will take slightly longer but may produce a more accurate result. An <n> of 0 will cause only exact matches to be output.
--exact-match Only output exact matches (a tag directly references the supplied commit). This is a synonym for --candidates=0.
--debug Verbosely display information about the searching strategy being employed to standard error. The tag name will still be printed to standard out.
--long Always output the long format (the tag, the number of commits and the abbreviated commit name) even when it matches a tag. This is useful when you want to see parts of the commit object name in "describe" output, even when the commit in question happens to be a tagged version. Instead of just emitting the tag name, it will describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2 that points at object deadbee....).
--match <pattern> Only consider tags matching the given glob(7) pattern, excluding the "refs/tags/" prefix. If used with --all, it also considers local branches and remote-tracking references matching the pattern, excluding respectively "refs/heads/" and "refs/remotes/" prefix; references of other types are never considered. If given multiple times, a list of patterns will be accumulated, and tags matching any of the patterns will be considered. Use --no-match to clear and reset the list of patterns.
--exclude <pattern> Do not consider tags matching the given glob(7) pattern, excluding the "refs/tags/" prefix. If used with --all, it also does not consider local branches and remote-tracking references matching the pattern, excluding respectively "refs/heads/" and "refs/remotes/" prefix; references of other types are never considered. If given multiple times, a list of patterns will be accumulated and tags matching any of the patterns will be excluded. When combined with --match a tag will be considered when it matches at least one --match pattern and does not match any of the --exclude patterns. Use --no-exclude to clear and reset the list of patterns.
--always Show uniquely abbreviated commit object as fallback.
--first-parent Follow only the first parent commit upon seeing a merge commit. This is useful when you wish to not match tags on branches merged in the history of the target commit.
With something like git.git current tree, I get:
[torvalds@g5 git]$ git describe parent v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721") at the end.
The number of additional commits is the number of commits which would be displayed by "git log v1.0.4..parent". The hash suffix is "-g" + an unambigous abbreviation for the tip commit of parent (which was 2414721b194453f058079d897d13c4e377f92dc6). The length of the abbreviation scales as the repository grows, using the approximate number of objects in the repository and a bit of math around the birthday paradox, and defaults to a minimum of 7. The "g" prefix stands for "git" and is used to allow describing the version of a software depending on the SCM the software is managed with. This is useful in an environment where people may use different SCMs.
Doing a git describe on a tag-name will just show the tag name:
[torvalds@g5 git]$ git describe v1.0.4 v1.0.4
With --all, the command can use branch heads as references, so the output shows the reference path as well:
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2 tags/v1.0.0-21-g975b
[torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^ heads/lt/describe-7-g975b
With --abbrev set to 0, the command can be used to find the closest tagname without any suffix:
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2 tags/v1.0.0
Note that the suffix you get if you type these commands today may be longer than what Linus saw above when he ran these commands, as your Git repository may have new commits whose object names begin with 975b that did not exist back then, and "-g975b" suffix alone may not be sufficient to disambiguate these commits.
For each commit-ish supplied, git describe will first look for a tag which tags exactly that commit. Annotated tags will always be preferred over lightweight tags, and tags with newer dates will always be preferred over tags with older dates. If an exact match is found, its name will be output and searching will stop.
If an exact match was not found, git describe will walk back through the commit history to locate an ancestor commit which has been tagged. The ancestor’s tag will be output along with an abbreviation of the input commit-ish’s SHA-1. If --first-parent was specified then the walk will only consider the first parent of each commit.
If multiple tags were found during the walk then the tag which has the fewest commits different from the input commit-ish will be selected and output. Here fewest commits different is defined as the number of commits which would be shown by git log tag..input will be the smallest number of commits possible.
Tree objects as well as tag objects not pointing at commits, cannot be described. When describing blobs, the lightweight tags pointing at blobs are ignored, but the blob is still described as <committ-ish>:<path> despite the lightweight tag being favorable.
NOLOGIN(5)                  Linux Programmer's Manual                 NOLOGIN(5)
nologin - prevent unprivileged users from logging into the system
If the file /etc/nologin exists and is readable, login(1) will allow access only to root.  Other users will be shown the contents of this file and their logins will be refused.  This provides a simple way of temporarily disabling all unprivileged logins.
/etc/nologin
login(1), shutdown(8)
ZILE(1)                           User Commands                          ZILE(1)
Zile - Zile Is Lossy Emacs
zile [OPTION-OR-FILENAME]...
Zile is a lightweight Emacs clone that provides a subset of Emacs's functionality suitable for basic editing.
Run Zile, the lightweight Emacs clone.
Initialization options:
--no-init-file, -q do not load ~/.zile
--funcall, -f FUNC call Zile Lisp function FUNC with no arguments
--load, -l FILE load Zile Lisp FILE using the load function
--help display this help message and exit
--version display version information and exit
Action options:
FILE   visit FILE using find-file
+LINE FILE visit FILE using find-file, then go to line LINE
Exit status is 0 if OK, 1 if it cannot start up, for example because of an invalid command-line argument, and 2 if it crashes or runs out of memory.
~/.zile — user's Zile init file
/usr/share/doc/zile/dotzile.sample — which contains some useful code for the init file.
Zile was written by Sandro Sigala, David A. Capello and Reuben Thomas. The Lisp interpreter is based on code by Scott Lawrence.
Report bugs to bug-zile@gnu.org.
Copyright © 2020 Free Software Foundation, Inc.  GNU Zile comes with ABSOLUTELY NO WARRANTY.  You may redistribute copies of Zile under the terms of the GNU General Public License.  For more information about these matters, see the file named COPYING.
emacs(1)
GIT-INIT(1)                        Git Manual                        GIT-INIT(1)
git-init - Create an empty Git repository or reinitialize an existing one
git init [-q | --quiet] [--bare] [--template=<template_directory>] [--separate-git-dir <git dir>] [--object-format=<format>] [-b <branch-name> | --initial-branch=<branch-name>] [--shared[=<permissions>]] [directory]
This command creates an empty Git repository - basically a .git directory with subdirectories for objects, refs/heads, refs/tags, and template files. An initial branch without any commits will be created (see the --initial-branch option below for its name).
If the $GIT_DIR environment variable is set then it specifies a path to use instead of ./.git for the base of the repository.
If the object storage directory is specified via the $GIT_OBJECT_DIRECTORY environment variable then the sha1 directories are created underneath - otherwise the default $GIT_DIR/objects directory is used.
Running git init in an existing repository is safe. It will not overwrite things that are already there. The primary reason for rerunning git init is to pick up newly added templates (or to move the repository to another place if --separate-git-dir is given).
-q, --quiet Only print error and warning messages; all other output will be suppressed.
--bare Create a bare repository. If GIT_DIR environment is not set, it is set to the current working directory.
--object-format=<format> Specify the given object format (hash algorithm) for the repository. The valid values are sha1 and (if enabled) sha256.  sha1 is the default.
THIS OPTION IS EXPERIMENTAL! SHA-256 support is experimental and still in an early stage. A SHA-256 repository will in general not be able to share work with "regular" SHA-1 repositories. It should be assumed that, e.g., Git internal file formats in relation to SHA-256 repositories may change in backwards-incompatible ways. Only use --object-format=sha256 for testing purposes.
--template=<template_directory> Specify the directory from which templates will be used. (See the "TEMPLATE DIRECTORY" section below.)
--separate-git-dir=<git dir> Instead of initializing the repository as a directory to either $GIT_DIR or ./.git/, create a text file there containing the path to the actual repository. This file acts as filesystem-agnostic Git symbolic link to the repository.
If this is reinitialization, the repository will be moved to the specified path.
-b <branch-name>, --initial-branch=<branch-name> Use the specified name for the initial branch in the newly created repository. If not specified, fall back to the default name (currently master, but this is subject to change in the future; the name can be customized via the init.defaultBranch configuration variable).
--shared[=(false|true|umask|group|all|world|everybody|0xxx)] Specify that the Git repository is to be shared amongst several users. This allows users belonging to the same group to push into that repository. When specified, the config variable "core.sharedRepository" is set so that files and directories under $GIT_DIR are created with the requested permissions. When not specified, Git will use permissions reported by umask(2).
The option can have the following values, defaulting to group if no value is given:
umask (or false) Use permissions reported by umask(2). The default, when --shared is not specified.
group (or true) Make the repository group-writable, (and g+sx, since the git group may be not the primary group of all users). This is used to loosen the permissions of an otherwise safe umask(2) value. Note that the umask still applies to the other permission bits (e.g. if umask is 0022, using group will not remove read privileges from other (non-group) users). See 0xxx for how to exactly specify the repository permissions.
all (or world or everybody) Same as group, but make the repository readable by all users.
0xxx 0xxx is an octal number and each file will have mode 0xxx.  0xxx will override users' umask(2) value (and not only loosen permissions as group and all does).  0640 will create a repository which is group-readable, but not group-writable or accessible to others.  0660 will create a repo that is readable and writable to the current user and group, but inaccessible to others.
By default, the configuration flag receive.denyNonFastForwards is enabled in shared repositories, so that you cannot force a non fast-forwarding push into it.
If you provide a directory, the command is run inside it. If this directory does not exist, it will be created.
Files and directories in the template directory whose name do not start with a dot will be copied to the $GIT_DIR after it is created.
The template directory will be one of the following (in order):
•   the argument given with the --template option;
•   the contents of the $GIT_TEMPLATE_DIR environment variable;
•   the init.templateDir configuration variable; or
•   the default template directory: /usr/share/git-core/templates.
The default template directory includes some directory structure, suggested "exclude patterns" (see gitignore(5)), and sample hook files.
The sample hooks are all disabled by default. To enable one of the sample hooks rename it by removing its .sample suffix.
See githooks(5) for more general info on hook execution.
Start a new Git repository for an existing code base
$ cd /path/to/my/codebase $ git init      (1) $ git add .     (2) $ git commit    (3)
1. Create a /path/to/my/codebase/.git directory. 2. Add all existing files to the index. 3. Record the pristine state as the first commit in the history.
PHYSLOCK(1)                  General Commands Manual                 PHYSLOCK(1)
physlock - lock all consoles / virtual terminals
physlock [-dhLlmsv] [-p MSG]
physlock is an alternative to vlock, it is equivalent to `vlock -an'. It is written because vlock blocks some linux kernel mechanisms like hibernate and suspend and can therefore only be used with some limitations.
physlock is designed to be lightweight, but highly depends on the kernels ioctl API.
The behaviour of physlock is completely controlled via command-line arguments, it does not rely on environment variables.  physlock uses the utmp file to identify the owner of the current session (i.e.  active tty) and prompts for her password to unlock the computer.
-d     Fork and detach physlock before prompting for authentication. The parent process returns right after everything is set up, so this option is useful for use in suspend/hibernate scripts.
-l     Only lock console switching and exit.
-L     Only enable (unlock) console switching and exit. This is useful when a prior instance of physlock has crashed and leaved the console switching mechanism locked.
-m     Mute kernel messages on console while physlock is running.
-p MSG Display MSG before the password prompt.
-s     Disable SysRq mechanism while physlock is running.
Bert Muennich <ber.t at gmx.com>
http://github.com/muennich/physlock
vlock(1)
SU(1)                        General Commands Manual                       SU(1)
su - zmienia ID użytkownika lub umożliwia stanie się superużytkownikiem
su [-] [nazwa_użytkownika [argumenty]]
su służy do stawania się innym użytkownikiem w trakcie własnej sesji pracy.  Wywołanie bez parametru - nazwy użytkownika, domyślnie oznacza dla su próbę stania się superużytkownikiem.  Opcjonalnym argumentem - można posłużyć się do zasymulowania rzeczywistego rozpoczynania sesji pracy. Pozwala to na utworzenie środowiska użytkownika podobnego do tego, jakie występuje przy bezpośrednim zgłoszeniu użytkownika w systemie.
Po nazwie użytkownika mogą wystąpić dodatkowe argumenty. Zostaną one dostarczone powłoce zgłoszeniowej użytkownika. W szczególności, argument -c spowoduje, że następny argument zostanie potraktowany jak polecenie przez większość interpretatorów poleceń.  Polecenie zostanie wykonane przez powłokę wymienioną w /etc/passwd dla docelowego użytkownika.
Użytkownik pytany jest o odpowiednie hasło, jeśli takowe istnieje. Błędne hasła powodują komunikat o błędzie. Wszystkie próby, udane i nieudane, są rejestrowane do celów wykrywania nadużyć systemu.
Do nowej powłoki przekazywane jest bieżące środowisko.  Wartość $PATH dla zwykłych użytkowników ustawiana jest jest na /bin:/usr/bin, zaś dla superużytkownika na /sbin:/bin:/usr/sbin:/usr/bin.  Można to zmienić przy pomocy definicji ENV_PATH i ENV_SUPATH w /etc/login.defs.
Niniejsza wersja su posiada wiele opcji kompilacji, z których tylko część będzie mieć zastosowanie w danej instalacji.
/etc/passwd - informacja o kontach użytkowników /etc/shadow - zakodowane hasła i informacja o ich ważności $HOME/.profile - plik startowy dla domyślnej powłoki
login(1), sh(1), suauth(5), login.defs(5)
MAIL(1)                    BSD General Commands Manual                   MAIL(1)
Mail [v14.9.22] — send and receive Internet mail
mail [-DdEFinv~#] [-: spec] [-A account] [:-a attachment:] [:-b bcc-addr:] [:-C "field: body":] [:-c cc-addr:] [-M type | -m file | -q file | -t] [-r from-addr] [:-S var[=value]:] [-s subject] [:-T "field: addr":] [:-X cmd:] [:-Y cmd:] [-.] :to-addr: [-- :mta-option:]
mail [-DdEeHiNnRv~#] [-: spec] [-A account] [:-C "field: body":] [-L spec] [-r from-addr] [:-S var[=value]:] [-u user] [:-X cmd:] [:-Y cmd:] [-- :mta-option:] mail [-DdEeHiNnRv~#] [-: spec] [-A account] [:-C "field: body":] -f [-L spec] [-r from-addr] [:-S var[=value]:] [:-X cmd:] [:-Y cmd:] [file] [-- :mta-option:]
mail -h | --help mail -V | --version
Note: S-nail (Mail) will see major changes in v15.0 (circa 2022). Some backward incompatibilities cannot be avoided.  COMMANDS change to Shell-style argument quoting, and shell metacharacters will become (more) meaningful.  Some commands accept new syntax today via wysh (Command modifiers).  Behaviour is flagged [v15-compat] and [no v15-compat], setting v15-compat (INTERNAL VARIABLES) will choose new behaviour when applicable; giving it a value makes wysh an implied default.  [Obsolete] flags what will vanish.
Warning! v15-compat (with value) will be a default in v14.10.0!
Mail provides a simple and friendly environment for sending and receiving mail.  It is intended to provide the functionality of the POSIX mailx(1) command, but is MIME capable and optionally offers extensions for line editing, S/MIME, SMTP and POP3, among others.  Mail divides incoming mail into its constituent messages and allows the user to deal with them in any order.  It offers many COMMANDS and INTERNAL VARIABLES for manipulating messages and sending mail.  It provides the user simple editing capabilities to ease the composition of outgoing messages, and increasingly powerful and reliable non-interactive scripting capabilities.
Options -: spec, --resource-files=.. Controls loading of (as via source) Resource files: spec is parsed case-insensitively, the letter ‘s’ corresponds to the system wide mail.rc, ‘u’ the user's personal file ~/.mailrc.  The (original) system wide resource is also compiled-in, accessible via ‘x’.  The letters ‘-’ and ‘/’ disable usage of resource files.  Order matters, default is ‘su’.  This option overrides -n.
-A name, --account=.. Activate user account name after program startup is complete (resource files loaded, only -X commands are to be executed), and switch to its primary system mailbox (most likely the inbox).  If activation fails the program exits if used non-interactively, or if any of errexit or posix are set.
-a file[=input-charset[#output-charset]], --attach=.. (Send mode) Attach file.  For (Compose mode) opportunities refer to ~@ and ~^.  file is subject to tilde expansion (see Filename transformations and folder); if it is not accessible but contains a ‘=’ character, anything before the last ‘=’ will be used as the filename, anything thereafter as a character set specification, as shown.
If only an input character set is specified, the input side is fixed, and no character set conversion will be applied; an empty or the special string hyphen-minus ‘-’ is taken for ttycharset (the default).  If an output character set has also been specified the desired conversion is performed immediately, not considering file type and content, except for an empty string or hyphen-minus ‘-’, which select the default conversion algorithm (see Character sets): no immediate conversion is performed, file and its contents will be MIME-classified (HTML mail and MIME attachments, The mime.types files) first — only the latter mode is available unless features includes ‘,+iconv,’.
-B        ([Obsolete]: Mail will always use line-buffered output, to gain line-buffered input even in batch mode enable batch mode via -#.)
-b addr, --bcc=.. (Send mode) Send a blind carbon copy to recipient addr.  The option may be used multiple times.  Also see the section On sending mail, and non-interactive mode.
-C "field: body", --custom-header=.. Create a custom header which persists for an entire session.  A custom header consists of the field name followed by a colon ‘:’ and the field content body, for example ‘-C "Blah: Neminem laede; imo omnes, quantum potes, juva"’.  Standard header field names cannot be overwritten by custom headers.  Runtime adjustable custom headers are available via the variable customhdr, and in (Compose mode) ~^, one of the COMMAND ESCAPES, as well as digmsg are the most flexible and powerful options to manage message headers.  This option may be used multiple times.
-c addr, --cc=.. (Send mode) Just like -b, except it places the argument in the list of carbon copies.
-D, --disconnected [Option] Startup with disconnected set.
-d, --debug Enter a debug-only sandbox mode by setting the internal variable debug; the same can be achieved via ‘-S debug’ or ‘set debug’. Also see -v.
-E, --discard-empty-messages (Send mode) set skipemptybody and thus discard messages with an empty message part body, successfully.
-e, --check-and-exit Just check if mail is present (in the system inbox or the one specified via -f): if yes, return an exit status of zero, a non- zero value otherwise.  To restrict the set of mails to consider in this evaluation a message specification can be added with the option -L.  Quickrun: does not open an interactive session.
-F        (Send mode) Save the message to send in a file named after the local part of the first recipient's address (instead of in record).
-f, --file Read in the contents of the user's secondary mailbox MBOX (or the specified file) for processing; when Mail is quit, it writes undeleted messages back to this file (but be aware of the hold option).  The optional file argument will undergo some special Filename transformations (as via folder).  Note that file is not an argument to the flag -f, but is instead taken from the command line after option processing has been completed.  In order to use a file that starts with a hyphen-minus, prefix with a relative path, as in ‘./-hyphenbox.mbox’.
-H, --header-summary Display a summary of headers for the given folder (depending on -u, inbox or MAIL, or as specified via -f), then exit.  A configurable summary view is available via the option -L.  This mode does not honour showlast.  Quickrun: does not open an interactive session.
-h, --help Show a brief usage summary; use --long-help for a list long options.
-i        set ignore to ignore tty interrupt signals.
-L spec, --search=.. Display a summary of headers of all messages that match the given spec in the folder found by the same algorithm used by -H, then exit.  See the section Specifying messages for the format of spec.  This mode does not honour showlast.
If the -e option has been given in addition no header summary is produced, but Mail will instead indicate via its exit status whether spec matched any messages (‘0’) or not (‘1’); note that any verbose output is suppressed in this mode and must instead be enabled explicitly (see -v).  Quickrun: does not open an interactive session.
-M type   (Send mode) Will flag standard input with the MIME ‘Content-Type:’ set to the given known type (HTML mail and MIME attachments, The mime.types files) and use it as the main message body.  [v15 behaviour may differ] Using this option will bypass processing of message-inject-head and message-inject-tail.  Also see -q, -m, -t.
-m file   (Send mode) MIME classify the specified file and use it as the main message body.  [v15 behaviour may differ] Using this option will bypass processing of message-inject-head and message-inject-tail.  Also see -q, -M, -t.
-N, --no-header-summary inhibit the initial display of message headers when reading mail or editing a mailbox folder by calling unset for the internal variable header.
-n        Standard flag that inhibits reading the system wide mail.rc upon startup.  The option -: allows more control over the startup sequence; also see Resource files.