neulab/tldr huggingface dataset:
CursorProximity distance Set the distance at which a relative tool is treated as being out of proximity.  Beyond this distance the cursor will stop responding to tool motion. The default value for pucks is 10 (Intuos Pro) or 42 (Intuos/Bamboo). The default value for pens is 30.
Threshold level Set the minimum pressure necessary to generate a Button event for the stylus tip, eraser, or touch.  The pressure levels of all tablets are normalized to 2048 levels irregardless of the actual hardware supported levels.  This parameter is independent of the PressureCurve parameter.  Default:  27, range of 0 to 2047.
ToolDebugLevel level Set the debug level for this tool to the given level. This only affects code paths that are specific to a given tool. A higher level means more fine-grained debug messages, a level of 0 turns debugging off for this tool. Requires the driver to be built with debugging enabled. See also TabletDebugLevel.  Default:  0, range of 0 to 12.
PressureRecalibration on|off If the initial pressure of a device is != 0 the driver recalibrates the pressure range. This is to account for worn out devices.  The downside is that when the user hits the tablet very hard the initial pressure reading may be unequal to zero even for a perfectly good pen. If the consecutive pressure readings are not higher than the initial pressure by a threshold no button event will be generated.  This option allows to disable the recalibration.  Default:  on
PanScrollThreshold distance This specifies the distance the pen must move (in tablet units) before a scroll event is generated when using the "pan" action. Smaller values will require less distance and be more sensitive. Larger values will require more distance and be less sensitive. Default: 1300 or 2600 depending on tablet resolution (corresponds to 13 mm of distance).
This tool provides access to the device properties implemented in the xf86-input-wacom X server input module. It does not work under a Wayland compositor as the input module is not active.
See https://github.com/linuxwacom/xf86-input-wacom/wiki/Wayland for details.
Peter Hutterer <peter.hutterer@redhat.com>
Xorg(1), wacom(4), xorg.conf(5), X(7)
More information is available at https://github.com/linuxwacom/xf86-input-wacom
CheckInstall(8)              System Manager's Manual             CheckInstall(8)
checkinstall â€”       Track installation of local software, and produce a binary manageable with your package management software.
checkinstall [options]  [install command]
checkinstall is a program that monitors an installation procedure (such as make install, install.sh ), and creates a standard package for your distribution (currently deb, rpm and tgz packages are supported) that you can install through your distribution's package management system (dpkg, rpm or installpkg).
Note that for most useful actions, checkinstall must be run as root.
These programs follow the usual GNU command line syntax, with long options starting with two dashes ('-').  A summary of options is included below.
All the options that toggle a switch default to activate the option.  To force activation or deactivation, call them with '=yes' or '=no'. As an example, to disable stripping use --strip=no.
-h           --help Show summary of options.
--version Show version information.
--copyright Show Copyright information
--type    Choose packaging system. Can be one of 'slackware', 'debian' or 'rpm'.
-D        Create a Debian package.
-R        Create a RPM package.
-S        Create a Slackware Package.
--install Toggle installation of the created package.
--fstrans Enable/disable filesystem translation. Filesystem translation enabled causes the install to proceed in a temporary directory, thus not actually touching your system.
-y   --default Accept default answers to all questions.
--pkgname Set the package name.
--pkgversion Set package version.
-A   --arch    --pkgarch Set package architecture.
--pkgrelease Set the package release.
--pkglicense Set package license.
--pkggroup Set the package group.
--pkgsource Set source location
--pkgaltsource Set alternate source location
--pakdir  Where to save the new package.
--maintainer Set the package maintainer. Be careful to correctly quote/escape the name, to prevent shell expansion
--provides Features provided by this package (currently only on RPM and Deb).
--requires Dependencies required by this package.
--rpmflags Pass this flags to the rpm installer.
--rpmi    Use the -i flag when installing a rpm.
--rpmu    Use the -U flag when installing a rpm.
--dpkgflags Pass this flags to the dpkg installer
--spec    Where the .spec file is located
--nodoc   Do not include documentation files.
-d        Set debug level. Must be one of 0, 1 and 2.
-si       Run an interactive install command
--showinstall Toggle interactive install command.
-ss       Run an interactive Slackware installation script.
--showslack Toggle interactive Slackware installation script.
--autodoinst Toggle creation of a doinst.sh script.
--strip   Toggle stripping any ELF binaries found inside the package.
--stripso Toggle stripping any ELF libraries (.so) found inside the package.
--addso   Search for any shared libs and add them to /etc/ld.so.conf
--reset-uids Reset perms for all files/dirs to 755 and the owner/group for all dirs to root.root
--gzman   Compress any man pages found inside the package.
--docdir  Where to put documentation files.
--umask   Set the umask value.
--exclude Exclude these files/directories from the package.
--include Force the inclusion in the package of the files/dirs listed in the argument (a file).
--inspect Inspect the package's file list
--review-spec Review the spec file before creating a .rpm.
--review-control Review the control file before creating a .deb.
--newslack Use the new (8.1+) Slackware description format ("--newslack" implies "-S")
--with-tar Manually set the path to the tar binary.
--deldoc  Toggle deletion of doc-pak upon termination.
--deldesc Toggle deletion of description-pak upon termination.
--delspec Toggle deletion of spec file upon termination.
--bk      Backup any overwritten files
--backup  Toggle backup
This program reads its configuration from /etc/checkinstallrc, which can be used to override defaults.  Command line arguments override settings in the configuration file.
This manual page was written by Felipe Sateler <fsateler@gmail.com> for the Debian system (but may be used by others).  Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2.
GIT-CHECK-IGNORE(1)                Git Manual                GIT-CHECK-IGNORE(1)
git-check-ignore - Debug gitignore / exclude files
git check-ignore [<options>] <pathname>... git check-ignore [<options>] --stdin
For each pathname given via the command-line or from a file via --stdin, check whether the file is excluded by .gitignore (or other input files to the exclude mechanism) and output the path if it is excluded.
By default, tracked files are not shown at all since they are not subject to exclude rules; but see ‘--no-index’.
-q, --quiet Don’t output anything, just set exit status. This is only valid with a single pathname.
-v, --verbose Instead of printing the paths that are excluded, for each path that matches an exclude pattern, print the exclude pattern together with the path. (Matching an exclude pattern usually means the path is excluded, but if the pattern begins with !  then it is a negated pattern and matching it means the path is NOT excluded.)
For precedence rules within and between exclude sources, see gitignore(5).
--stdin Read pathnames from the standard input, one per line, instead of from the command-line.
-z The output format is modified to be machine-parsable (see below). If --stdin is also given, input paths are separated with a NUL character instead of a linefeed character.
-n, --non-matching Show given paths which don’t match any pattern. This only makes sense when --verbose is enabled, otherwise it would not be possible to distinguish between paths which match a pattern and those which don’t.
--no-index Don’t look in the index when undertaking the checks. This can be used to debug why a path became tracked by e.g.  git add .  and was not ignored by the rules as expected by the user or when developing patterns including negation to match a path previously added with git add -f.
By default, any of the given pathnames which match an ignore pattern will be output, one per line. If no pattern matches a given path, nothing will be output for that path; this means that path will not be ignored.
If --verbose is specified, the output is a series of lines of the form:
<source> <COLON> <linenum> <COLON> <pattern> <HT> <pathname>
<pathname> is the path of a file being queried, <pattern> is the matching pattern, <source> is the pattern’s source file, and <linenum> is the line number of the pattern within that source. If the pattern contained a ! prefix or / suffix, it will be preserved in the output. <source> will be an absolute path when referring to the file configured by core.excludesFile, or relative to the repository root when referring to .git/info/exclude or a per-directory exclude file.
If -z is specified, the pathnames in the output are delimited by the null character; if --verbose is also specified then null characters are also used instead of colons and hard tabs:
<source> <NULL> <linenum> <NULL> <pattern> <NULL> <pathname> <NULL>
If -n or --non-matching are specified, non-matching pathnames will also be output, in which case all fields in each output record except for <pathname> will be empty. This can be useful when running non-interactively, so that files can be incrementally streamed to STDIN of a long-running check-ignore process, and for each of these files, STDOUT will indicate whether that file matched a pattern or not. (Without this option, it would be impossible to tell whether the absence of output for a given file meant that it didn’t match any pattern, or that the output hadn’t been generated yet.)
Buffering happens as documented under the GIT_FLUSH option in git(1). The caller is responsible for avoiding deadlocks caused by overfilling an input buffer or reading from an empty output buffer.
0 One or more of the provided paths is ignored.
1 None of the provided paths are ignored.
128 A fatal error was encountered.
gitignore(5) git-config(1) git-ls-files(1)
VIM(1)                       General Commands Manual                      VIM(1)
vim - Vi IMproved, a programmer's text editor
vim [options] [file ..] vim [options] - vim [options] -t tag vim [options] -q [errorfile]
ex view gvim gview evim eview rvim rview rgvim rgview
Vim is a text editor that is upwards compatible to Vi.  It can be used to edit all kinds of plain text.  It is especially useful for editing programs.
There are a lot of enhancements above Vi: multi level undo, multi windows and buffers, syntax highlighting, command line editing, filename completion, on-line help, visual selection, etc..  See ":help vi_diff.txt" for a summary of the differences between Vim and Vi.
While running Vim a lot of help can be obtained from the on-line help system, with the ":help" command.  See the ON-LINE HELP section below.
Most often Vim is started to edit a single file with the command
More generally Vim is started with:
vim [options] [filelist]
If the filelist is missing, the editor will start with an empty buffer. Otherwise exactly one out of the following four may be used to choose one or more files to be edited.
file ..     A list of filenames.  The first one will be the current file and read into the buffer.  The cursor will be positioned on the first line of the buffer.  You can get to the other files with the ":next" command.  To edit a file that starts with a dash, precede the filelist with "--".
-           The file to edit is read from stdin.  Commands are read from stderr, which should be a tty.
-t {tag}    The file to edit and the initial cursor position depends on a "tag", a sort of goto label.  {tag} is looked up in the tags file, the associated file becomes the current file and the associated command is executed.  Mostly this is used for C programs, in which case {tag} could be a function name.  The effect is that the file containing that function becomes the current file and the cursor is positioned on the start of the function.  See ":help tag-commands".
-q [errorfile] Start in quickFix mode.  The file [errorfile] is read and the first error is displayed.  If [errorfile] is omitted, the filename is obtained from the 'errorfile' option (defaults to "AztecC.Err" for the Amiga, "errors.err" on other systems). Further errors can be jumped to with the ":cn" command.  See ":help quickfix".
Vim behaves differently, depending on the name of the command (the executable may still be the same file).
vim       The "normal" way, everything is default.
ex        Start in Ex mode.  Go to Normal mode with the ":vi" command. Can also be done with the "-e" argument.
view      Start in read-only mode.  You will be protected from writing the files.  Can also be done with the "-R" argument.
gvim gview The GUI version.  Starts a new window.  Can also be done with the "-g" argument.
evim eview The GUI version in easy mode.  Starts a new window.  Can also be done with the "-y" argument.
rvim rview rgvim rgview Like the above, but with restrictions.  It will not be possible to start shell commands, or suspend Vim.  Can also be done with the "-Z" argument.
The options may be given in any order, before or after filenames. Options without an argument can be combined after a single dash.
+[num]      For the first file the cursor will be positioned on line "num".  If "num" is missing, the cursor will be positioned on the last line.
+/{pat}     For the first file the cursor will be positioned in the line with the first occurrence of {pat}.  See ":help search-pattern" for the available search patterns.
+{command}
-c {command} {command} will be executed after the first file has been read.  {command} is interpreted as an Ex command.  If the {command} contains spaces it must be enclosed in double quotes (this depends on the shell that is used).  Example: vim "+set si" main.c Note: You can use up to 10 "+" or "-c" commands.
-S {file}   {file} will be sourced after the first file has been read. This is equivalent to -c "source {file}".  {file} cannot start with '-'.  If {file} is omitted "Session.vim" is used (only works when -S is the last argument).
--cmd {command} Like using "-c", but the command is executed just before processing any vimrc file.  You can use up to 10 of these commands, independently from "-c" commands.
-A          If Vim has been compiled with ARABIC support for editing right-to-left oriented files and Arabic keyboard mapping, this option starts Vim in Arabic mode, i.e. 'arabic' is set. Otherwise an error message is given and Vim aborts.
-b          Binary mode.  A few options will be set that makes it possible to edit a binary or executable file.
-C          Compatible.  Set the 'compatible' option.  This will make Vim behave mostly like Vi, even though a .vimrc file exists.
-d          Start in diff mode.  There should between two to eight file name arguments.  Vim will open all the files and show differences between them.  Works like vimdiff(1).
-d {device} Open {device} for use as a terminal.  Only on the Amiga. Example: "-d con:20/30/600/150".
-D          Debugging.  Go to debugging mode when executing the first command from a script.
-e          Start Vim in Ex mode, just like the executable was called "ex".
-E          Start Vim in improved Ex mode, just like the executable was called "exim".
-f          Foreground.  For the GUI version, Vim will not fork and detach from the shell it was started in.  On the Amiga, Vim is not restarted to open a new window.  This option should be used when Vim is executed by a program that will wait for the edit session to finish (e.g. mail).  On the Amiga the ":sh" and ":!" commands will not work.
--nofork    Foreground.  For the GUI version, Vim will not fork and detach from the shell it was started in.
-F          If Vim has been compiled with FKMAP support for editing right-to-left oriented files and Farsi keyboard mapping, this option starts Vim in Farsi mode, i.e. 'fkmap' and 'rightleft' are set.  Otherwise an error message is given and Vim aborts.
-g          If Vim has been compiled with GUI support, this option enables the GUI.  If no GUI support was compiled in, an error message is given and Vim aborts.
-h          Give a bit of help about the command line arguments and options.  After this Vim exits.
-H          If Vim has been compiled with RIGHTLEFT support for editing right-to-left oriented files and Hebrew keyboard mapping, this option starts Vim in Hebrew mode, i.e. 'hkmap' and 'rightleft' are set.  Otherwise an error message is given and Vim aborts.
-i {viminfo} Specifies the filename to use when reading or writing the viminfo file, instead of the default "~/.viminfo".  This can also be used to skip the use of the .viminfo file, by giving the name "NONE".
-L          Same as -r.
-l          Lisp mode.  Sets the 'lisp' and 'showmatch' options on.
-m          Modifying files is disabled.  Resets the 'write' option.  You can still modify the buffer, but writing a file is not possible.
-M          Modifications not allowed.  The 'modifiable' and 'write' options will be unset, so that changes are not allowed and files can not be written.  Note that these options can be set to enable making modifications.
-N          No-compatible mode.  Resets the 'compatible' option.  This will make Vim behave a bit better, but less Vi compatible, even though a .vimrc file does not exist.
-n          No swap file will be used.  Recovery after a crash will be impossible.  Handy if you want to edit a file on a very slow medium (e.g. floppy).  Can also be done with ":set uc=0". Can be undone with ":set uc=200".
-nb         Become an editor server for NetBeans.  See the docs for details.
-o[N]       Open N windows stacked.  When N is omitted, open one window for each file.
-O[N]       Open N windows side by side.  When N is omitted, open one window for each file.
-p[N]       Open N tab pages.  When N is omitted, open one tab page for each file.
-R          Read-only mode.  The 'readonly' option will be set.  You can still edit the buffer, but will be prevented from accidentally overwriting a file.  If you do want to overwrite a file, add an exclamation mark to the Ex command, as in ":w!".  The -R option also implies the -n option (see above). The 'readonly' option can be reset with ":set noro".  See ":help 'readonly'".
-r          List swap files, with information about using them for recovery.
-r {file}   Recovery mode.  The swap file is used to recover a crashed editing session.  The swap file is a file with the same filename as the text file with ".swp" appended.  See ":help recovery".
-s          Silent mode.  Only when started as "Ex" or when the "-e" option was given before the "-s" option.
-s {scriptin} The script file {scriptin} is read.  The characters in the file are interpreted as if you had typed them.  The same can be done with the command ":source! {scriptin}".  If the end of the file is reached before the editor exits, further characters are read from the keyboard.
-T {terminal} Tells Vim the name of the terminal you are using.  Only required when the automatic way doesn't work.  Should be a terminal known to Vim (builtin) or defined in the termcap or terminfo file.
-u {vimrc}  Use the commands in the file {vimrc} for initializations. All the other initializations are skipped.  Use this to edit a special kind of files.  It can also be used to skip all initializations by giving the name "NONE".  See ":help initialization" within vim for more details.
-U {gvimrc} Use the commands in the file {gvimrc} for GUI initializations.  All the other GUI initializations are skipped.  It can also be used to skip all GUI initializations by giving the name "NONE".  See ":help gui-init" within vim for more details.
-V[N]       Verbose.  Give messages about which files are sourced and for reading and writing a viminfo file.  The optional number N is the value for 'verbose'.  Default is 10.
-v          Start Vim in Vi mode, just like the executable was called "vi".  This only has effect when the executable is called "ex".
-w {scriptout} All the characters that you type are recorded in the file {scriptout}, until you exit Vim.  This is useful if you want to create a script file to be used with "vim -s" or ":source!".  If the {scriptout} file exists, characters are appended.
-W {scriptout} Like -w, but an existing file is overwritten.
-x          Use encryption when writing files.  Will prompt for a crypt key.
-X          Don't connect to the X server.  Shortens startup time in a terminal, but the window title and clipboard will not be used.
-y          Start Vim in easy mode, just like the executable was called "evim" or "eview".  Makes Vim behave like a click-and-type editor.
-Z          Restricted mode.  Works like the executable starts with "r".
--          Denotes the end of the options.  Arguments after this will be handled as a file name.  This can be used to edit a filename that starts with a '-'.
--clean     Do not use any personal configuration (vimrc, plugins, etc.). Useful to see if a problem reproduces with a clean Vim setup.
--echo-wid  GTK GUI only: Echo the Window ID on stdout.
--help      Give a help message and exit, just like "-h".
--literal   Take file name arguments literally, do not expand wildcards. This has no effect on Unix where the shell expands wildcards.
--noplugin  Skip loading plugins.  Implied by -u NONE.
--remote    Connect to a Vim server and make it edit the files given in the rest of the arguments.  If no server is found a warning is given and the files are edited in the current Vim.
--remote-expr {expr} Connect to a Vim server, evaluate {expr} in it and print the result on stdout.
--remote-send {keys} Connect to a Vim server and send {keys} to it.
--remote-silent As --remote, but without the warning when no server is found.
--remote-wait As --remote, but Vim does not exit until the files have been edited.
--remote-wait-silent As --remote-wait, but without the warning when no server is found.
--serverlist List the names of all Vim servers that can be found.
--servername {name} Use {name} as the server name.  Used for the current Vim, unless used with a --remote argument, then it's the name of the server to connect to.
--socketid {id} GTK GUI only: Use the GtkPlug mechanism to run gvim in another window.
--startuptime {file} During startup write timing messages to the file {fname}.
--version   Print version information and exit.
ON-LINE HELP Type ":help" in Vim to get started.  Type ":help subject" to get help on a specific subject.  For example: ":help ZZ" to get help for the "ZZ" command.  Use <Tab> and CTRL-D to complete subjects (":help cmdline-completion").  Tags are present to jump from one place to another (sort of hypertext links, see ":help").  All documentation files can be viewed in this way, for example ":help syntax.txt".
/usr/share/vim/vim82/doc/*.txt The Vim documentation files.  Use ":help doc-file-list" to get the complete list.
/usr/share/vim/vim82/doc/tags The tags file used for finding information in the documentation files.
/usr/share/vim/vim82/syntax/syntax.vim System wide syntax initializations.
/usr/share/vim/vim82/syntax/*.vim Syntax files for various languages.
/etc/vimrc     System wide Vim initializations.
~/.vimrc       Your personal Vim initializations.
/etc/gvimrc    System wide gvim initializations.
~/.gvimrc      Your personal gvim initializations.
/usr/share/vim/vim82/optwin.vim Script used for the ":options" command, a nice way to view and set options.
/usr/share/vim/vim82/menu.vim System wide menu initializations for gvim.
/usr/share/vim/vim82/bugreport.vim Script to generate a bug report.  See ":help bugs".
/usr/share/vim/vim82/filetype.vim Script to detect the type of a file by its name.  See ":help 'filetype'".
/usr/share/vim/vim82/scripts.vim Script to detect the type of a file by its contents.  See ":help 'filetype'".
/usr/share/vim/vim82/print/*.ps Files used for PostScript printing.
For recent info read the VIM home page: <URL:http://www.vim.org/>
vimtutor(1)
Most of Vim was made by Bram Moolenaar, with a lot of help from others. See ":help credits" in Vim. Vim is based on Stevie, worked on by: Tim Thompson, Tony Andrews and G.R. (Fred) Walter.  Although hardly any of the original code remains.
Probably.  See ":help todo" for a list of known problems.
Note that a number of things that may be regarded as bugs by some, are in fact caused by a too-faithful reproduction of Vi's behaviour.  And if you think other things are bugs "because Vi does it differently", you should take a closer look at the vi_diff.txt file (or type :help vi_diff.txt when in Vim).  Also have a look at the 'compatible' and 'cpoptions' options.
ANSIBLE-INVENTORY(1)     System administration commands     ANSIBLE-INVENTORY(1)
ansible-inventory - None
usage: ansible-inventory [-h] [--version] [-v] [-i INVENTORY] [--vault-id VAULT_IDS] [--ask-vault-password | --vault-password-file VAULT_PASSWORD_FILES] [--playbook-dir BASEDIR] [-e EXTRA_VARS] [--list] [--host HOST] [--graph] [-y] [--toml] [--vars] [--export] [--output OUTPUT_FILE] [host|group]
used to display or dump the configured inventory as Ansible sees it
--ask-vault-password, --ask-vault-pass ask for vault password
--export When doing an --list, represent in a way that is optimized for export,not as an accurate representation of how Ansible has processed it
--graph create inventory graph, if supplying pattern it must be a valid group name
--host 'HOST' Output specific host info, works as inventory script
--list Output all hosts info, works as inventory script
--list-hosts ==SUPPRESS==
--output 'OUTPUT_FILE' When doing --list, send the inventory to a file instead of to the screen
--playbook-dir 'BASEDIR' Since this tool does not use playbooks, use this as a substitute playbook directory.This sets the relative path for many features including roles/ group_vars/ etc.
--toml Use TOML format instead of default JSON, ignored for --graph
--vars Add vars to graph display, ignored unless used with --graph
--vault-id the vault identity to use
--vault-password-file, --vault-pass-file vault password file
--version show program's version number, config file location, configured module search path, module location, executable location and exit
-e, --extra-vars set additional variables as key=value or YAML/JSON, if filename prepend with @
-i, --inventory, --inventory-file specify inventory host path or comma separated host list. --inventory-file is deprecated
-l, --limit ==SUPPRESS==
-v, --verbose verbose mode (-vvv for more, -vvvv to enable connection debugging)
-y, --yaml Use YAML format instead of default JSON, ignored for --graph
The following environment variables may be specified.
ANSIBLE_CONFIG -- Specify override location for the ansible config file
Many more are available for most options in ansible.cfg
For a full list check https://docs.ansible.com/. or use the ansible-config command.
/etc/ansible/ansible.cfg -- Config file, used if present
~/.ansible.cfg -- User config file, overrides the default config if present
./ansible.cfg -- Local config file (in current working directory) assumed to be 'project specific' and overrides the rest if present.
As mentioned above, the ANSIBLE_CONFIG environment variable will override all others.
Ansible was originally written by Michael DeHaan.
Copyright © 2018 Red Hat, Inc | Ansible.  Ansible is released under the terms of the GPLv3 license.
ansible (1), ansible-config (1), ansible-console (1), ansible-doc (1), ansible-galaxy (1), ansible-playbook (1), ansible-pull (1), ansible-vault (1)
Extensive documentation is available in the documentation site: <‐ https://docs.ansible.com>.  IRC and mailing list info can be found in file CONTRIBUTING.md, available in: <https://github.com/ansible/ansible>
nginx(1)                                                                nginx(1)
nginx - small, powerful, scalable web/proxy server
nginx [options] <configuration file>
Nginx ("engine X") is a high-performance web and reverse proxy server created by Igor Sysoev. It can be used both as a standalone web server and as a proxy to reduce the load on back-end HTTP or mail servers.
A summary of options is included below:
-?,-h  Show this help.
-v     Show version and exit.
-V     Show version and configure options then exit.
-s signal Send signal to a master process: stop, quit, reopen, reload.
-p prefix Set prefix path.
-g directives Set global directives out of configuration file.
-c <configuration file> Specifies a particular configuration file for nginx to load.
-t     Tests nginx configuration and exit.
SEE ALSO Website: <http://nginx.org/>
AUTHORS nginx was written by Igor Sysoev <igor@sysoev.ru>.
This manual page was written by Jose Parrella <joseparrella@cantv.net> and Kartik Mistry <kartik@debian.org>, for the Debian project (but may be used by others).
SBCL(1)                      General Commands Manual                     SBCL(1)
SBCL -- Steel Bank Common Lisp
SBCL is an implementation of ANSI Common Lisp, featuring a high- performance native compiler, native threads on several platforms, a socket interface, a source-level debugger, a statistical profiler, and much more.
It is free software, mostly in the public domain, but with some subsystems under BSD-style licenses which allow modification and reuse as long as credit is given. It is provided "as is", with no warranty of any kind.
For more information about license issues, see the COPYING file in the distribution. For more information about history, see the CREDITS file in the distribution.
To run SBCL, type "sbcl". After startup messages a prompt ("*") appears. Enter a Lisp expression, and SBCL will read and execute it, print any values returned, give you another prompt, and wait for your next input.
$ sbcl ...[startup messages elided]... * (+ 1 2 3)
6 * (exit)
Most people like to run SBCL as a subprocess under Emacs. The Emacs "Slime" mode provides many convenient features, like command line editing, tab completion, and various kinds of coupling between Common Lisp source files and the interactive SBCL subprocess.
For information on creating "standalone executables" using SBCL, see SB-EXT:SAVE-LISP-AND-DIE in the User Manual.
For ordinary interactive use, no command line arguments should be necessary.
In order to understand the SBCL command line syntax, it is helpful to understand that the system is composed of two parts: a runtime environment, and the Common Lisp system it supports. Some command line arguments are processed during the initialization of the runtime, and some during the initialization of the Lisp system -- any remaining command line arguments are passed on to user code.
The overall command line syntax is:
sbcl [runtime options] --end-runtime-options [toplevel options] --end-toplevel-options [user options]
Both --end-runtime-options and --end-toplevel-options are optional, and may be omitted. They are intended for use in situations where any command line options are under user control (e.g. in batch files): by using them you can prevent options intended for your program being accidentally processed by SBCL.
Supported runtime options are
--core <corefilename> Use the specified Lisp core file instead of the default. (See the FILES section for the standard core, or the system documentation for SB-EXT:SAVE-LISP-AND-DIE for information about how to create a custom core.) Note that if the Lisp core file is a user-created core file, it may run a nonstandard toplevel which does not recognize the standard toplevel options.
--dynamic-space-size <megabytes> Size of the dynamic space reserved on startup in megabytes. Default value is platform dependent.
--control-stack-size <megabytes> Size of control stack reserved for each thread in megabytes. Default value is 2.
--noinform Suppress the printing of any banner or other informational message at startup. (This makes it easier to write Lisp programs which work cleanly in Unix pipelines. See also the "--noprint" and "--disable-debugger" options.)
--disable-ldb Disable the low-level debugger. Only effective if SBCL is compiled with LDB.
--lose-on-corruption There are some dangerous low level errors (for instance, control stack exhausted, memory fault) that (or whose handlers) can corrupt the image. By default SBCL prints a warning, then tries to continue and handle the error in Lisp, but this will not always work and SBCL may malfunction or even hang. With this option, upon encountering such an error SBCL will invoke ldb (if present and enabled) or else exit.
--script <filename> As a runtime option equivalent to --noinform --disable-ldb --lose-on-corruption --end-runtime-options --script <filename>. See the description of --script as a toplevel option below.
--merge-core-pages When platform support is present, provide hints to the operating system that identical pages may be shared between processes until they are written to. This can be useful to reduce the memory usage on systems with multiple SBCL processes started from similar but differently-named core files, or from compressed cores. Without platform support, do nothing. By default only compressed cores trigger hinting.
--no-merge-core-pages Ensures that no sharing hint is provided to the operating system.
--help Print some basic information about SBCL, then exit.
--version Print SBCL's version information, then exit.
In the future, runtime options may be added to control behavior such as lazy allocation of memory.
Runtime options, including any --end-runtime-options option, are stripped out of the command line before the Lisp toplevel logic gets a chance to see it.
The toplevel options supported by the standard SBCL core are
--sysinit <filename> Load filename instead of the default system-wide initialization file. (See the FILES section.)
--no-sysinit Do not load a system-wide initialization file. If this option is given, the --sysinit option is ignored.
--userinit <filename> Load filename instead of the default user initialization file. (See the FILES section.)
--no-userinit Do not load a user initialization file. If this option is given, the --userinit option is ignored.
--eval <command> After executing any initialization file, but before starting the read- eval-print loop on standard input, read and evaluate the command given. More than one --eval option can be used, and all will be read and executed, in the order they appear on the command line.
--load <filename> This is equivalent to --eval '(load "<filename>")'. The special syntax is intended to reduce quoting headaches when invoking SBCL from shell scripts.
--noprint When ordinarily the toplevel "read-eval-print loop" would be executed, execute a "read-eval loop" instead, i.e. don't print a prompt and don't echo results. Combined with the --noinform runtime option, this makes it easier to write Lisp "scripts" which work cleanly in Unix pipelines.
--disable-debugger By default when SBCL encounters an error, it enters the builtin debugger, allowing interactive diagnosis and possible intercession. This option disables the debugger, causing errors to print a backtrace and exit with status 1 instead -- which is a mode of operation better suited for batch processing. See the User Manual on SB-EXT:DISABLE-DEBUGGER for details.
--quit At the end of toplevel option processing, exit SBCL with a successful code of zero.  Note that the effect of this option is delayed until after toplevel options following this one.
--non-interactive This option disables the read-eval-print loop for both exceptional and non-exceptional reasons.  It is short for --disable-debugger and --quit in combination and is useful for batch uses where the special option processing implied by --script is not desired.
--script <filename> Implies --no-sysinit --no-userinit --disable-debugger --end-toplevel-options.
Causes the system to load the specified file and exit immediately afterwards, instead of entering the read-eval-print loop. If the file begins with a shebang line, it is ignored.
Regardless of the order in which toplevel options appear on the command line, the order of actions is:
1. Debugger is disabled, if requested.
2. Any system initialization file is loaded, unless prohibited.
3. Any user initialization file is loaded, unless prohibited.
4. --eval and --load options are processed in the order given.
Finally, either the read-eval-print loop is entered or the file specified with --script option is loaded.
When running in the read-eval-print loop the system exits on end of file. Similarly, the system exits immediately after processing the file specified with --script.
Note that when running SBCL with the --core option, using a core file created by a user call to the SB-EXT:SAVE-LISP-AND-DIE, the toplevel options may be under the control of user code passed as arguments to SB-EXT:SAVE-LISP-AND-DIE. For this purpose, the --end-toplevel-options option itself can be considered a toplevel option, i.e. the user core, at its option, may not support it.
In the standard SBCL startup sequence (i.e. with no user core involved) toplevel options and any --end-toplevel-options option are stripped out of the command line argument list before user code gets a chance to see it.
SBCL is derived from the CMU CL. (The name is intended to acknowledge the connection: steel and banking are the industries where Carnegie and Mellon made the big bucks.)
SBCL compiles by default: even functions entered in the read-eval-print loop are compiled to native code, unless the evaluator has been explicitly turned on. (Even today, some 40 years after the MacLisp compiler, people will tell you that Lisp is an interpreted language. Ignore them.)
SBCL aims for but has not completely achieved compliance with the ANSI standard for Common Lisp. More information about this is available in the BUGS section below.
SBCL also includes various non-ANSI extensions, described more fully in the User Manual.  Some of these are in the base system and others are "contrib" modules loaded on request using REQUIRE.  For example, to load the SB-BSD-SOCKETS module that provides TCP/IP connectivity, * (require 'asdf) * (require 'sb-bsd-sockets)
For more information, see the User Manual.
SBCL inherits from CMU CL the "Python" native code compiler. (Though we often avoid that name in order to avoid confusion with the scripting language also called Python.) This compiler is very clever about understanding the type system of Common Lisp and using it to optimize code, and about producing notes to let the user know when the compiler doesn't have enough type information to produce efficient code. It also tries (almost always successfully) to follow the unusual but very useful principle that "declarations are assertions", i.e.  type declarations should be checked at runtime unless the user explicitly tells the system that speed is more important than safety.
The compiled code uses garbage collection to automatically manage memory. The garbage collector implementation varies considerably from CPU to CPU. In particular, on some CPUs the GC is nearly exact, while on others it's more conservative, and on some CPUs the GC is generational, while on others simpler stop and copy strategies are used.
For more information about the compiler, see the user manual.
SBCL currently runs on X86 (Linux, FreeBSD, OpenBSD, and NetBSD), X86-64 (Linux), PPC (Linux), SPARC (Linux and Solaris 2.x), and MIPS (Linux). For information on other ongoing and possible ports, see the sbcl-devel mailing list, and/or the web site.
SBCL requires on the order of 16Mb RAM to run on X86 systems, though all but the smallest programs would be happier with 32Mb or more.
This section attempts to list the most serious and long-standing bugs. For more detailed and current information on bugs, see the BUGS file in the distribution.
It is possible to get in deep trouble by exhausting heap memory.  The SBCL system overcommits memory at startup, so, on typical Unix-alikes like Linux and FreeBSD, this means that if the SBCL system turns out to use more virtual memory than the system has available for it, other processes tend to be killed randomly (!).
The compiler's handling of function return values unnecessarily violates the "declarations are assertions" principle that it otherwise adheres to. Using PROCLAIM or DECLAIM to specify the return type of a function causes the compiler to believe you without checking. Thus compiling a file containing (DECLAIM (FTYPE (FUNCTION (T) NULL) SOMETIMES)) (DEFUN SOMETIMES (X) (ODDP X)) (DEFUN FOO (X) (IF (SOMETIMES X) 'THIS-TIME 'NOT-THIS-TIME)) then running (FOO 1) gives NOT-THIS-TIME, because the compiler relied on the truth of the DECLAIM without checking it.
Some things are implemented very inefficiently.
-- Multidimensional arrays are inefficient, especially multidimensional arrays of floating point numbers.
-- SBCL, like most (maybe all?) implementations of Common Lisp on stock hardware, has trouble passing floating point numbers around efficiently, because a floating point number, plus a few extra bits to identify its type, is larger than a machine word. (Thus, they get "boxed" in heap-allocated storage, causing GC overhead.) Within a single compilation unit, or when doing built-in operations like SQRT and AREF, or some special operations like structure slot accesses, this is avoidable: see the user manual for some efficiency hints. But for general function calls across the boundaries of compilation units, passing the result of a floating point calculation as a function argument (or returning a floating point result as a function value) is a fundamentally slow operation.
To report a bug, please send mail to the mailing lists sbcl-help or sbcl- devel. You can find the complete mailing list addresses on the web pages at <http://sbcl.sourceforge.net/>; note that as a spam reduction measure you must subscribe to the lists before you can post. (You may also find fancy SourceForge bug-tracking machinery there, but don't be fooled. As of 2002-07-25 anyway, we don't actively monitor that machinery, and it exists only because we haven't been able to figure out how to turn it off.)
As with any software bug report, it's most helpful if you can provide enough information to reproduce the symptoms reliably, and if you say clearly what the symptoms are.  For example, "There seems to be something wrong with TAN of very small negative arguments. When I execute (TAN LEAST-NEGATIVE-SINGLE-FLOAT) interactively on sbcl-1.2.3 on my Linux 4.5 X86 box, I get an UNBOUND-VARIABLE error."
SBCL can be built from scratch using a plain vanilla ANSI Common Lisp system and a C compiler, and all of its properties are specified by the version of the source code that it was created from. This clean bootstrappability was the immediate motivation for forking off of the CMU CL development tree. A variety of implementation differences are motivated by this design goal.
Maintenance work in SBCL since the fork has diverged somewhat from the maintenance work in CMU CL. Many but not all bug fixes and improvements have been shared between the two projects, and sometimes the two projects disagree about what would be an improvement.
Most extensions supported by CMU CL have been unbundled from SBCL, including Motif support, the Hemlock editor, search paths, the WIRE protocol, various user-level macros and functions (e.g.  LETF, ITERATE, MEMQ, REQUIRED-ARGUMENT), and many others.
(Why doesn't SBCL support more extensions natively? Why drop all those nice extensions from CMU CL when the code already exists? This is a frequently asked question on the mailing list. There are two principal reasons. First, it's a design philosophy issue: arguably SBCL has done its job by supplying a stable FFI, and the right design decision is to move functionality derived from that, like socket support, into separate libraries. Some of these are distributed with SBCL as "contrib" modules, others are distributed as separate software packages by separate maintainers. Second, it's a practical decision - focusing on a smaller number of things will, we hope, let us do a better job on them.)
Various information about SBCL is available at <http://www.sbcl.org/>. The mailing lists there are the recommended place to look for support.
Dozens of people have made substantial contributions to SBCL and its subsystems, and to the CMU CL system on which it was based, over the years. See the CREDITS file in the distribution for more information.
SBCL_HOME This variable controls where files like "sbclrc", "sbcl.core", and the add-on "contrib" systems are searched for. If it is not set, then sbcl looks in ../lib/sbcl/ relative to the location of the executable, or in the current directory. If your executable is in the default location /usr/local/bin/ then it will look in /usr/local/lib/sbcl/.
sbcl   executable program containing some low-level runtime support and a loader, used to read sbcl.core
sbcl.core dumped memory image containing most of SBCL, to be loaded by the `sbcl' executable.  Looked for in $SBCL_HOME, unless overridden by the --core option.
sbclrc optional system-wide startup script, looked for in $SBCL_HOME then /etc, unless overridden by the --sysinit command line option.
.sbclrc optional per-user customizable startup script (in user's home directory, or as specified by  --userinit)
Full SBCL documentation is maintained as a Texinfo manual. If it has been installed, the command
info sbcl
should give you access to the complete manual. Depending on your installation it may also be available in HTML and PDF formats in e.g.
/usr/local/share/doc/sbcl/
See the SBCL homepage
<http://www.sbcl.org/>
for more information, including directions on how to subscribe to the sbcl-devel and sbcl-help mailing-lists.
GIT-CLONE(1)                       Git Manual                       GIT-CLONE(1)
git-clone - Clone a repository into a new directory
git clone [--template=<template_directory>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] [--dissociate] [--separate-git-dir <git dir>] [--depth <depth>] [--[no-]single-branch] [--no-tags] [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] [--filter=<filter>] [--] <repository> [<directory>]
Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch --remotes), and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch.
After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the current master branch, if any (this is untrue when "--single-branch" is given; see below).
This default configuration is achieved by creating references to the remote branch heads under refs/remotes/origin and by initializing remote.origin.url and remote.origin.fetch configuration variables.
-l, --local When the repository to clone from is on a local machine, this flag bypasses the normal "Git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible.
If the repository is specified as a local path (e.g., /path/to/repo), this is the default, and --local is essentially a no-op. If the repository is specified as a URL, then this flag is ignored (and we never use the local optimizations). Specifying --no-local will override the default when /path/to/repo is given, using the regular Git transport instead.
NOTE: this operation can race with concurrent modification to the source repository, similar to running cp -r src dst while modifying src.
--no-hardlinks Force the cloning process from a repository on a local filesystem to copy the files under the .git/objects directory instead of using hardlinks. This may be desirable if you are trying to make a back-up of your repository.
-s, --shared When the repository to clone is on the local machine, instead of using hard links, automatically setup .git/objects/info/alternates to share the objects with the source repository. The resulting repository starts out without any object of its own.