neulab/tldr huggingface dataset:
PDF is a page description file that attempts to preserve a layout exactly.  A PDF can contain vector objects (such as text or lines) and raster objects (images).  A page might have multiple images.  OCRmyPDF is prepared to deal with the wide variety of PDFs that exist in the wild.
When a PDF page contains text, OCRmyPDF assumes that the page has already been OCRed or is a "born digital" page that should not be OCRed.  The default behavior is to exit in this case without producing a file.  You can use the option --skip-text to ignore pages with text, or --force-ocr to rasterize all objects on the page and produce an image-only PDF as output.
ocrmypdf --skip-text file_with_some_text_pages.pdf output.pdf
ocrmypdf --force-ocr word_document.pdf output.pdf
If you are concerned about long-term archiving of PDFs, use the default option --output-type pdfa which converts the PDF to a standardized PDF/A-2b.  This converts images to sRGB colorspace, removes some features from the PDF such as Javascript or forms. If you want to minimize the number of changes made to your PDF, use --output-type pdf.
If OCRmyPDF is given an image file as input, it will attempt to convert the image to a PDF before processing.  For more control over the conversion of images to PDF, use img2pdf, or other image to PDF software.
For example, this command uses img2pdf to convert all .png files beginning with the 'page' prefix to a PDF, fitting each image on A4-sized paper, and sending the result to OCRmyPDF through a pipe.
img2pdf --pagesize A4 page*.png | ocrmypdf - myfile.pdf
HTML documentation is located at: /usr/share/doc/ocrmypdf/html/index.html
after installing the ocrmypdf-doc package.
PHOTOREC(8)                   Administration Tools                   PHOTOREC(8)
photorec - Recover lost files from harddisk, digital camera and cdrom
photorec [/log] [/debug] [/d recup_dir] [device|image.dd|image.e01]
photorec /version
PhotoRec is file data recovery software designed to recover lost files including video, documents and archives from Hard Disks and CDRom and lost pictures (Photo Recovery) from digital camera memory. PhotoRec ignores the filesystem and goes after the underlying data, so it'll work even if your media's filesystem is severely damaged or formatted. PhotoRec is safe to use, it will never attempt to write to the drive or memory support you are about to recover lost data from. For more information on how to use, please visit the wiki pages on www.cgsecurity.org
/log   create a photorec.log file
/debug add debug information
testdisk(8), fdisk(8).
PhotoRec 7.1, Data Recovery Utility, July 2019 Christophe GRENIER <grenier@cgsecurity.org> https://www.cgsecurity.org
FDUPES(1)                    General Commands Manual                   FDUPES(1)
fdupes - finds duplicate files in a given set of directories
fdupes [ options ] DIRECTORY ...
Searches the given path for duplicate files. Such files are found by comparing file sizes and MD5 signatures, followed by a byte-by-byte comparison.
-r --recurse for every directory given follow subdirectories encountered within
-R --recurse: for each directory given after this option follow subdirectories encountered within (note the ':' at the end of option; see the Examples section below for further explanation)
-s --symlinks follow symlinked directories
-H --hardlinks normally, when two or more files point to the same disk area they are treated as non-duplicates; this option will change this behavior
-G --minsize=SIZE consider only files greater than or equal to SIZE
-L --maxsize==SIZE consider only files less than or equal to SIZE
-n --noempty exclude zero-length files from consideration
-A --nohidden exclude hidden files from consideration
-f --omitfirst omit the first file in each set of matches
-1 --sameline list each set of matches on a single line
-S --size show size of duplicate files
-t --time show modification time of duplicate files
-m --summarize summarize duplicate file information
-q --quiet hide progress indicator
-d --delete prompt user for files to preserve, deleting all others (see CAVEATS below)
-P --plain with --delete, use line-based prompt (as with older versions of fdupes) instead of screen-mode interface
-N --noprompt when used together with --delete, preserve the first file in each set of duplicates and delete the others without prompting the user
-I --immediate delete duplicates as they are encountered, without grouping into sets; implies --noprompt
-p --permissions don't consider files with different owner/group or permission bits as duplicates
-o --order=WORD order files according to WORD: time - sort by modification time, ctime - sort by status change time, name - sort by filename
-i --reverse reverse order while sorting
-l --log=LOGFILE log file deletion choices to LOGFILE
-v --version display fdupes version
-h --help displays help
Unless -1 or --sameline is specified, duplicate files are listed together in groups, each file displayed on a separate line. The groups are then separated from each other by blank lines.
When -1 or --sameline is specified, spaces and backslash characters  (\) appearing in a filename are preceded by a backslash character.
fdupes a --recurse: b will follow subdirectories under b, but not those under a.
fdupes a --recurse b will follow subdirectories under both a and b.
When using -d or --delete, care should be taken to insure against accidental data loss.
When used together with options -s or --symlink, a user could accidentally preserve a symlink while deleting the file it points to.
Furthermore, when specifying a particular directory more than once, all files within that directory will be listed as their own duplicates, leading to data loss should a user preserve a file without its "duplicate" (the file itself!).
Adrian Lopez <adrian2@caribe.net>
ANSIBLE-DOC(1)           System administration commands           ANSIBLE-DOC(1)
ansible-doc - plugin documentation tool
usage: ansible-doc [-h] [--version] [-v] [-M MODULE_PATH] [--playbook-dir BASEDIR] [-t {become,cache,callback,cliconf,connection,httpapi,inventory,lookup,netconf,shell,vars,module,strategy,role,keyword}] [-j] [-r ROLES_PATH] [-e ENTRY_POINT | -s | -F | -l | --metadata-dump] [plugin [plugin ...]]
displays information on modules installed in Ansible libraries.  It displays a terse listing of plugins and their short descriptions, provides a printout of their DOCUMENTATION strings, and it can create a short "snippet" which can be pasted into a playbook.
--metadata-dump For internal testing only Dump json metadata for all plugins.
-F, --list_files Show plugin names and their source files without summaries (implies --list). A supplied argument will be used for filtering, can be a namespace or full collection name.
-e 'ENTRY_POINT', --entry-point 'ENTRY_POINT' Select the entry point for role(s).
-j, --json Change output into json format.
-l, --list List available plugins. A supplied argument will be used for filtering, can be a namespace or full collection name.
-r, --roles-path The path to the directory containing your roles.
-s, --snippet Show playbook snippet for these plugin types: inventory, lookup, module
-t 'TYPE', --type 'TYPE' Choose which plugin type (defaults to "module"). Available plugin types are : ('become', 'cache', 'callback', 'cliconf', 'connection', 'httpapi', 'inventory', 'lookup', 'netconf', 'shell', 'vars', 'module', 'strategy', 'role', 'keyword')
ansible (1), ansible-config (1), ansible-console (1), ansible-galaxy (1), ansible-inventory (1), ansible-playbook (1), ansible-pull (1), ansible-vault (1)
HEAD(1P)                    POSIX Programmer's Manual                   HEAD(1P)
head — copy the first part of files
head [-n number] [file...]
The head utility shall copy its input files to the standard output, ending the output for each file at a designated point.
Copying shall end at the point in each input file indicated by the -n number option. The option-argument number shall be counted in units of lines.
The head utility shall conform to the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines.
-n number The first number lines of each input file shall be copied to standard output. The application shall ensure that the number option-argument is a positive decimal integer.
When a file contains less than number lines, it shall be copied to standard output in its entirety. This shall not be an error.
If no options are specified, head shall act as if -n 10 had been specified.
file      A pathname of an input file. If no file operands are specified, the standard input shall be used.
Input files shall be text files, but the line length is not restricted to {LINE_MAX} bytes.
The following environment variables shall affect the execution of head:
The standard output shall contain designated portions of the input files.
If multiple file operands are specified, head shall precede the output for each with the header:
"\n==> %s <==\n", <pathname>
except that the first header written shall not include the initial <newline>.
When using head to process pathnames, it is recommended that LC_ALL, or at least LC_CTYPE and LC_COLLATE, are set to POSIX or C in the environment, since pathnames can contain byte sequences that do not form valid characters in some locales, in which case the utility's behavior would be undefined. In the POSIX locale each byte is a valid single-byte character, and therefore this problem is avoided.
To write the first ten lines of all files (except those with a leading period) in the directory:
head -- *
Although it is possible to simulate head with sed 10q for a single file, the standard developers decided that the popularity of head on historical BSD systems warranted its inclusion alongside tail.
POSIX.1‐2008 version of head follows the Utility Syntax Guidelines. The -n option was added to this new interface so that head and tail would be more logically related. Earlier versions of this standard allowed a -number option. This form is no longer specified by POSIX.1‐2008 but may be present in some implementations.
There is no -c option (as there is in tail) because it is not historical practice and because other utilities in this volume of POSIX.1‐2017 provide similar functionality.
sed, tail
hub(1)                             hub manual                             hub(1)
hub - make git easier with GitHub
hub [--noop] COMMAND [OPTIONS] hub alias [-s] [SHELL] hub help hub-COMMAND
Hub is a tool that wraps git in order to extend it with extra functionality that makes it better when working with GitHub.
Available commands are split into two groups: those that are already present in git but that are extended through hub, and custom ones that hub provides.
Extended git commands hub-am(1) Replicate commits from a GitHub pull request locally.
hub-apply(1) Download a patch from GitHub and apply it locally.
hub-checkout(1) Check out the head of a pull request as a local branch.
hub-cherry-pick(1) Cherry-pick a commit from a fork on GitHub.
hub-clone(1) Clone a repository from GitHub.
hub-fetch(1) Add missing remotes prior to performing git fetch.
hub-init(1) Initialize a git repository and add a remote pointing to GitHub.
hub-merge(1) Merge a pull request locally with a message like the GitHub Merge Button.
hub-push(1) Push a git branch to each of the listed remotes.
hub-remote(1) Add a git remote for a GitHub repository.
hub-submodule(1) Add a git submodule for a GitHub repository.
New commands provided by hub hub-alias(1) Show shell instructions for wrapping git.
hub-api(1) Low-level GitHub API request interface.
hub-browse(1) Open a GitHub repository in a web browser.
hub-ci-status(1) Display status of GitHub checks for a commit.
hub-compare(1) Open a GitHub compare page in a web browser.
hub-create(1) Create a new repository on GitHub and add a git remote for it.
hub-delete(1) Delete a repository on GitHub.
hub-fork(1) Fork the current repository on GitHub and add a git remote for it.
hub-gist(1) Create and print GitHub Gists.
hub-pull-request(1) Create a GitHub Pull Request.
hub-pr(1) Manage GitHub Pull Requests for the current repository.
hub-issue(1) Manage GitHub Issues for the current repository.
hub-release(1) Manage GitHub Releases for the current repository.
hub-sync(1) Fetch git objects from upstream and update local branches.
Most hub commands are supposed to be run in a context of an existing local git repository. Hub will automatically detect the GitHub repository that the current working directory belongs to by scanning its git remotes.
In case there are multiple git remotes that are all pointing to GitHub, hub assumes that the main one is named "upstream", "github", or "origin", in that order of preference.
When working with forks, it´s recommended that the git remote for your own fork is named "origin" and that the git remote for the upstream repository is named "upstream". See ⟨https://help.github.com/articles/configuring-a-remote-for-a-fork/⟩
The default branch (usually "master") for the current repository is detected like so:
git symbolic-ref refs/remotes/origin/HEAD
where origin is the name of the git remote for the upstream repository.
The destination where the currently checked out branch is considered to be pushed to depends on the git config push.default setting. If the value is "upstream" or "tracking", the tracking information for a branch is read like so:
git rev-parse --symbolic-full-name BRANCH@{upstream}
Otherwise, hub scans git remotes to find the first one for which refs/remotes/REMOTE/BRANCH exists. The "origin", "github", and "upstream" remotes are searched last because hub assumes that it´s more likely that the current branch is pushed to your fork rather than to the canonical repo.
GitHub OAuth authentication Hub will prompt for GitHub username  password the first time it needs to access the API and exchange it for an OAuth token, which it saves in ~/.config/hub.
To avoid being prompted, use GITHUB_USER and GITHUB_PASSWORD environment variables.
Alternatively, you may provide GITHUB_TOKEN, an access token with repo permissions. This will not be written to ~/.config/hub.
HTTPS instead of git protocol If you prefer the HTTPS protocol for git operations, you can configure hub to generate all URLs with https: instead of git: or ssh::
$ git config --global hub.protocol https
This will affect clone, fork, remote add and other hub commands that expand shorthand references to GitHub repo URLs.
GitHub Enterprise By default, hub will only work with repositories that have remotes which point to github.com. GitHub Enterprise hosts need to be whitelisted to configure hub to treat such remotes same as github.com:
$ git config --global --add hub.host MY.GIT.ORG
The default host for commands like init and clone is still github.com, but this can be affected with the GITHUB_HOST environment variable:
$ GITHUB_HOST=my.git.org git clone myproject
Environment variables HUB_VERBOSE If this environment variable is set, verbose logging will be printed to stderr.
HUB_CONFIG The file path where hub configuration is read from and stored. If XDG_CONFIG_HOME is present, the default is $XDG_CONFIG_HOME/hub; otherwise it´s $HOME/.config/hub. The configuration file is also searched for in XDG_CONFIG_DIRS per XDG Base Directory Specification.
HUB_PROTOCOL One of "https", "ssh", or "git" as preferred protocol for git clone/push.
GITHUB_HOST The GitHub hostname to default to instead of "github.com".
GITHUB_TOKEN OAuth token to use for GitHub API requests.
GITHUB_USER The GitHub username of the actor of GitHub API operations.
GITHUB_PASSWORD The GitHub password used to exchange user credentials for an OAuth token that gets stored in hub configuration. If not set, it may be interactively prompted for on first run.
GITHUB_REPOSITORY A value in "OWNER/REPO" format that specifies the repository that API operations should be performed against. Currently only used to infer the default value of GITHUB_USER for API requests.
⟨https://github.com/github/hub/issues⟩
⟨https://github.com/github/hub/contributors⟩
git(1), git-clone(1), git-remote(1), git-init(1), ⟨https://github.com/github/hub⟩
DIFF3(1)                          User Commands                         DIFF3(1)
diff3 - compare three files line by line
diff3 [OPTION]... MYFILE OLDFILE YOURFILE
Compare three files line by line.
-A, --show-all output all changes, bracketing conflicts
-e, --ed output ed script incorporating changes from OLDFILE to YOURFILE into MYFILE
-E, --show-overlap like -e, but bracket conflicts
-3, --easy-only like -e, but incorporate only nonoverlapping changes
-x, --overlap-only like -e, but incorporate only overlapping changes
-X     like -x, but bracket conflicts
-i     append 'w' and 'q' commands to ed scripts
-m, --merge output actual merged file, according to -A if no other options are given
-T, --initial-tab make tabs line up by prepending a tab
-L, --label=LABEL use LABEL instead of file name (can be repeated up to three times)
The default output format is a somewhat human-readable representation of the changes.
The -e, -E, -x, -X (and corresponding long) options cause an ed script to be output instead of the default.
Finally, the -m (--merge) option causes diff3 to do the merge internally and output the actual merged file.  For unusual input, this is more robust than using ed.
If a FILE is '-', read standard input.  Exit status is 0 if successful, 1 if conflicts, 2 if trouble.
Written by Randy Smith.
cmp(1), diff(1), sdiff(1)
The full documentation for diff3 is maintained as a Texinfo manual.  If the info and diff3 programs are properly installed at your site, the command
info diff3
TIG(1)                             Tig Manual                             TIG(1)
tig - text-mode interface for Git
tig        [options] [revisions] [--] [paths] tig log    [options] [revisions] [--] [paths] tig show   [options] [revisions] [--] [paths] tig reflog [options] [revisions] tig blame  [options] [rev] [--] path tig grep   [options] [pattern] tig refs   [options] tig stash  [options] tig status tig <      [Git command output]
Tig is an ncurses-based text-mode interface for git(1). It functions mainly as a Git repository browser, but can also assist in staging changes for commit at chunk level and act as a pager for output from various Git commands.
Command line options recognized by Tig include all valid git-log(1) and git-diff(1) options, as well as the following subcommands and Tig-specific options. The first command line parameter not starting with "-" is interpreted as being either a revision specification or a path and will end the option parsing. All additional options will be passed to the underlying Git command.
show Open diff view using the given git-show(1) options.
blame Show given file annotated by commits. Takes zero or more git-blame(1) options. Optionally limited from given revision.
status Start up in status view.
log Start up in log view, displaying git-log(1) output.
reflog Start up in reflog view.
refs Start up in refs view.
stash Start up in stash view.
grep Open the grep view. Supports the same options as git-grep(1).
+<number> Show the first view with line <number> visible and selected.
-v, --version Show version and exit.
-C <path> Run as if Tig was started in <path> instead of the current working directory.
Tig enters pager mode when input is provided via stdin and supports the following subcommands and options:
•   When the show subcommand is specified and the --stdin option is given, stdin is assumed to be a list of commit IDs and will be forwarded to the diff view’s underlying git-show(1) command. For example:
$ git rev-list --author=vivien HEAD | tig show --stdin
•   When --stdin is given, stdin is assumed to be a list of commit IDs and will be forwarded to the main view’s underlying git-log(1) command. For example:
$ tig --no-walk --stdin < cherry-picks.txt
•   When --pretty=raw is given, stdin is assumed to be a "pretty=raw" formatted output similar to that of git-log(1). For example:
$ git reflog --pretty=raw | tig --pretty=raw
When no subcommands nor options are given, the pager view will be used for displaying the Git command input given on stdin. The pager view assumes the input is either from git-log(1) or git-diff(1) and will highlight it similar to the log and diff views. For example:
$ git log -Schange -p --raw | tig
Display the list of commits for the current branch:
$ tig
Display commits from one or more branches:
$ tig test master
Pretend as if all the refs in refs/ are listed on the command line:
$ tig --all
Display differences between two branches:
$ tig test..master
Display changes for sub-module versions:
$ tig --submodule
Display changes for a single file:
$ tig -- README
Display contents of the README file in a specific revision:
$ tig show tig-0.8:README
Display revisions between two dates for a specific file:
$ tig --after="2004-01-01" --before="2006-05-16" -- README
Blame file with copy detection enabled:
$ tig blame -C README
Display the list of stashes:
$ tig stash
Grep all files for lines containing DEFINE_ENUM:
$ tig grep -p DEFINE_ENUM
Show references (branches, remotes and tags):
$ tig refs
Use word diff in the diff view:
$ tig --word-diff=plain
In addition to environment variables used by Git (e.g. GIT_DIR), Tig defines the ones below. The command related environment variables have access to the internal state of Tig via replacement variables, such as %(commit) and %(blob). See tigrc(5) for a full list.
TIGRC_USER Path of the user configuration file (defaults to ~/.tigrc or $XDG_CONFIG_HOME/tig/config).
TIGRC_SYSTEM Path of the system wide configuration file (defaults to {sysconfdir}/tigrc). Define to empty string to use built-in configuration.
TIG_LS_REMOTE Command for retrieving all repository references. The command should output data in the same format as git-ls-remote(1).
TIG_DIFF_OPTS The diff options to use in the diff view. The diff view uses git-show(1) for formatting and always passes --patch-with-stat. You may also set the diff-options setting in the configuration file.
TIG_TRACE Path for trace file where information about Git commands are logged.
TIG_SCRIPT Path to script that should be executed automatically on startup. If this environment variable is defined to the empty string, the script is read from stdin. The script is interpreted line-by-line and can contain prompt commands and key mappings.
E.g. TIG_SCRIPT=<(echo :set main-view-commit-title-graph = no) tig
TIG_NO_DISPLAY Open Tig without rendering anything to the terminal. This force Ncurses to write to /dev/null. The main use is for automated testing of Tig.
TIG_EDITOR The editor command to use when visiting files. This environment variable overrides $GIT_EDITOR, $EDITOR and $VISUAL, so it allows to use a different editor from the one Git uses.
$XDG_CONFIG_HOME/tig/config, ~/.config/tig/config, ~/.tigrc The Tig user configuration file is loaded in the following way. If $XDG_CONFIG_HOME is set, read user configuration from $XDG_CONFIG_HOME/tig/config. If $XDG_CONFIG_HOME is empty or undefined, read user configuration from ~/.config/tig/config if it exists and fall back to ~/.tigrc if it does not exist. See tigrc(5) for examples.
/etc/tigrc System wide configuration file.
$GIT_DIR/config, ~/.gitconfig, /etc/gitconfig Git configuration files. Read on start-up with the help of git-config(1).
$XDG_DATA_HOME/tig/history, ~/.local/share/tig/history, ~/.tig_history When compiled with readline support, Tig writes a persistent command and search history. The location of the history file is determined in the following way. If $XDG_DATA_HOME is set and $XDG_DATA_HOME/tig/ exists, store history to $XDG_DATA_HOME/tig/history. If $XDG_DATA_HOME is empty or undefined, store history to ~/.local/share/tig/history if the directory ~/.local/share/tig/ exists, and fall back to ~/.tig_history if it does not exist.
Please visit Tig’s home page[1] or main Git repository[2] for information about new releases and how to report bugs or feature request.
Copyright (c) 2006-2014 Jonas Fonseca <jonas.fonseca@gmail.com[3]>
tigrc(5), tigmanual(7), git(7)
1. home page https://jonas.github.io/tig
2. main Git repository https://github.com/jonas/tig
3. jonas.fonseca@gmail.com mailto:jonas.fonseca@gmail.com
ELINKS(1)                    The Elinks text-browser                   ELINKS(1)
elinks - lynx-like alternative character mode WWW browser
elinks [OPTION]... [URL]...
ELinks is a text mode WWW browser, supporting colors, table rendering, background downloading, menu driven configuration interface, tabbed browsing and slim code.
Frames are supported. You can have different file formats associated with external viewers. mailto: and telnet: are supported via external clients.
ELinks can handle both local files and remote URLs. The main supported remote URL protocols are HTTP, HTTPS (with SSL support compiled in) and FTP. Additional protocol support exists for BitTorrent finger, Gopher, SMB and NNTP.
The homepage of ELinks can be found at <http://elinks.cz/>, where the ELinks manual is also hosted.
Most options can be set in the user interface or config file, so usually you do not need to care about them. Note that this list is roughly equivalent to the output of running ELinks with the option --long-help.
-anonymous [0|1] (default: 0) Restricts ELinks so it can run on an anonymous account. Local file browsing, downloads, and modification of options will be disabled. Execution of viewers is allowed, but entries in the association table can´t be added or modified.
-auto-submit [0|1] (default: 0) Automatically submit the first form in the given URLs.
-base-session <num> (default: 0) Used internally when opening ELinks instances in new windows. The ID maps to information that will be used when creating the new instance. You don´t want to use it.
-config-dir <str> (default: "") Path of the directory ELinks will read and write its config and runtime state files to instead of ~/.elinks. If the path does not begin with a ´/´ it is assumed to be relative to your HOME directory.
-config-dump Print a configuration file with options set to the built-in defaults to stdout.
-config-file <str> (default: "elinks.conf") Name of the configuration file that all configuration options will be read from and written to. It should be relative to config-dir.
-config-help Print help for configuration options and exit.
-default-mime-type (alias for mime.default_type) The default MIME type used for documents of unknown type.
-default-keys [0|1] (default: 0) When set, all keybindings from configuration files will be ignored. It forces use of default keybindings and will reset user-defined ones on save.
-dump [0|1] (default: 0) Print formatted plain-text versions of given URLs to stdout.
-dump-charset (alias for document.dump.codepage) Codepage used when formatting dump output.
-dump-color-mode (alias for document.dump.color_mode) Color mode used with -dump.
-dump-width (alias for document.dump.width) Width of the dump output.
-eval Specify configuration file directives on the command-line which will be evaluated after all configuration files has been read. Example usage: -eval ´set protocol.file.allow_special_files = 1´
-force-html Makes ELinks assume documents of unknown types are HTML. Useful when using ELinks as an external viewer from MUAs. This is equivalent to -default-mime-type text/html.
-?, -h, -help Print usage help and exit.
-localhost [0|1] (default: 0) Restricts ELinks to work offline and only connect to servers with local addresses (ie. 127.0.0.1). No connections to remote servers will be permitted.
-long-help Print detailed usage help and exit.
-lookup Look up specified host and print all DNS resolved IP addresses.
-no-connect [0|1] (default: 0) Run ELinks as a separate instance instead of connecting to an existing instance. Note that normally no runtime state files (bookmarks, history, etc.) are written to the disk when this option is used. See also -touch-files.
-no-home [0|1] (default: 0) Disables creation and use of files in the user specific home configuration directory (~/.elinks). It forces default configuration values to be used and disables saving of runtime state files.
-no-numbering (alias for document.dump.numbering) Prevents printing of link number in dump output.
Note that this really affects only -dump, nothing else.
-no-references (alias for document.dump.references) Prevents printing of references (URIs) of document links in dump output.
-remote Control a remote ELinks instance by passing commands to it. The option takes an additional argument containing the method which should be invoked and any parameters that should be passed to it. For ease of use, the additional method argument can be omitted in which case any URL arguments will be opened in new tabs in the remote instance.
Following is a list of the supported methods:
•   ping(): look for a remote instance
•   openURL(): prompt URL in current tab
•   openURL(URL): open URL in current tab
•   openURL(URL, new-tab): open URL in new tab
•   openURL(URL, new-window): open URL in new window
•   addBookmark(URL): bookmark URL
•   infoBox(text): show text in a message box
•   reload(): reload the document in the current tab
•   search(string): search in the current tab
•   xfeDoCommand(openBrowser): open new window
-session-ring <num> (default: 0) ID of session ring this ELinks session should connect to.  ELinks works in so-called session rings, whereby all instances of ELinks are interconnected and share state (cache, bookmarks, cookies, and so on). By default, all ELinks instances connect to session ring 0. You can change that behaviour with this switch and form as many session rings as you want. Obviously, if the session-ring with this number doesn´t exist yet, it´s created and this ELinks instance will become the master instance (that usually doesn´t matter for you as a user much).
Note that you usually don´t want to use this unless you´re a developer and you want to do some testing - if you want the ELinks instances each running standalone, rather use the -no-connect command-line option. Also note that normally no runtime state files are written to the disk when this option is used. See also -touch-files.
-source [0|1] (default: 0) Print given URLs in source form to stdout.
-touch-files [0|1] (default: 0) When enabled, runtime state files (bookmarks, history, etc.) are written to disk, even when -no-connect or -session-ring is used. The option has no effect if not used in conjunction with any of these options.
-verbose <num> (default: 1) The verbose level controls what messages are shown at start up and while running:
•   0 means only show serious errors
•   1 means show serious errors and warnings
•   2 means show all messages
-version Print ELinks version information and exit. Generated using output from ELinks version 0.13.GIT.
COMSPEC, SHELL The shell used for File -> OS Shell on DOS/Windows and UNIX, respectively.
EDITOR The program to use for external editor (when editing textareas).
ELINKS_CONFDIR The location of the directory containing configuration files. If not set the default is ~/.elinks/.
ELINKS_TWTERM, LINKS_TWTERM The command to run when selecting File -> New window and if TWDISPLAY is defined (default twterm -e).
ELINKS_XTERM, LINKS_XTERM The command to run when selecting File -> New window and if DISPLAY is defined (default xterm -e).
FTP_PROXY, HTTP_PROXY, HTTPS_PROXY The host to proxy the various protocol traffic through.
NO_PROXY A comma separated list of URLs which should not be proxied.
HOME The path to the users home directory. Used when expanding ~/.
WWW_HOME Homepage location (as in lynx(1)).
Configuration files controlled by ELinks are located in the user configuration directory, defaulting to ~/.elinks/. In addition to the files listed below, a user defined CSS stylesheet can be defined using the document.css.stylesheet option.
/etc/elinks.conf Site-wide configuration file.
~/.elinks/elinks.conf Per-user config file, loaded after site-wide configuration.
~/.elinks/bookmarks Bookmarks file.
~/.elinks/cookies Cookies file.
~/.elinks/exmodehist Exmode history file.
~/.elinks/formhist Form history file.
~/.elinks/globhist History file containing most recently visited URLs.
~/.elinks/gotohist GoTo URL dialog history file.
~/.elinks/hooks.{js,lua,pl,py,rb,scm} Browser scripting hooks.
~/.elinks/searchhist Search history file.
~/.elinks/socket Internal ELinks socket for communication between its instances.
~/.mailcap, /etc/mailcap Mappings of MIME types to external handlers.
~/.mime.types, /etc/mime.types Mappings of file extensions to MIME types.
Please report any other bugs you find to the either the ELinks mailing list at <elinks-users@linuxfromscratch.org> or if you prefer enter them into the bug tracking system <http://bugzilla.elinks.cz/>. More information about how to get in contact with developers and getting help can be found on the community page <http://elinks.cz/community.html>.
ELinks is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License <http://www.gnu.org/copyleft/gpl.html> as published by the Free Software Foundation; version 2 of the License.
The Links browser - on which ELinks is based - was written by Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>. ELinks was written by Petr Baudis <pasky@ucw.cz>. See file AUTHORS in the source tree for a list of people contributing to this project.
This manual page was written by Peter Gervai <grin@tolna.net>, using excerpts from a (yet?) unknown Links fan for the Debian GNU/Linux system (but may be used by others). Contributions from Francis A. Holop. Extended, clarified and made more up-to-date by Petr Baudis <pasky@ucw.cz>. Updated by Zas <zas@norz.org>. The conversion to Asciidoc and trimming was done by Jonas Fonseca <fonseca@diku.dk>.
elinkskeys(5), elinks.conf(5), links(1), lynx(1), w3m(1), wget(1)
fakeroot(1)                       Debian manual                      fakeroot(1)
fakeroot - run a command in an environment faking root privileges for file manipulation
fakeroot [-l|--lib library] [--faked faked-binary] [-i load-file] [-s save-file] [-u|--unknown-is-real ] [-b|--fd-base ] [-h|--help ] [-v|--version ] [--] [command]
fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation.  This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership.  Without fakeroot one would need to have root privileges to create the constituent files of the archives with the correct permissions and ownership, and then pack them up, or one would have to construct the archives directly, without using the archiver.
fakeroot works by replacing the file manipulation library functions (chmod(2), stat(2) etc.) by ones that simulate the effect the real library functions would have had, had the user really been root. These wrapper functions are in a shared library /usr/lib/*/libfakeroot-*.so or similar location on your platform.  The shared object is loaded through the LD_PRELOAD mechanism of the dynamic loader. (See ld.so(8))
If you intend to build packages with fakeroot, please try building the fakeroot package first: the "debian/rules build" stage has a few tests (testing mostly for bugs in old fakeroot versions). If those tests fail (for example because you have certain libc5 programs on your system), other packages you build with fakeroot will quite likely fail too, but possibly in much more subtle ways.
Also, note that it's best not to do the building of the binaries themselves under fakeroot. Especially configure and friends don't like it when the system suddenly behaves differently from what they expect. (or, they randomly unset some environment variables, some of which fakeroot needs).
-l library, --lib library Specify an alternative wrapper library.
--faked binary Specify an alternative binary to use as faked.
[--] command Any command you want to be ran as fakeroot. Use ‘--’ if in the command you have other options that may confuse fakeroot's option parsing.
-s save-file Save the fakeroot environment to save-file on exit. This file can be used to restore the environment later using -i. However, this file will leak and fakeroot will behave in odd ways unless you leave the files touched inside the fakeroot alone when outside the environment. Still, this can be useful. For example, it can be used with rsync(1) to back up and restore whole directory trees complete with user, group and device information without needing to be root. See /usr/share/doc/fakeroot/README.saving for more details.
-i load-file Load a fakeroot environment previously saved using -s from load- file.  Note that this does not implicitly save the file, use -s as well for that behaviour. Using the same file for both -i and -s in a single fakeroot invocation is safe.
-u, --unknown-is-real Use the real ownership of files previously unknown to fakeroot instead of pretending they are owned by root:root.
-b fd  Specify fd base (TCP mode only). fd is the minimum file descriptor number to use for TCP connections; this may be important to avoid conflicts with the file descriptors used by the programs being run under fakeroot.
-h     Display help.
-v     Display version.
Here is an example session with fakeroot.  Notice that inside the fake root environment file manipulation that requires root privileges succeeds, but is not really happening.
$  whoami joost $ fakeroot /bin/bash #  whoami root # mknod hda3 b 3 1 # ls -ld hda3 brw-r--r--   1 root     root       3,   1 Jul  2 22:58 hda3 # chown joost:root hda3 # ls -ld hda3 brw-r--r--   1 joost    root       3,   1 Jul  2 22:58 hda3 # ls -ld / drwxr-xr-x  20 root     root         1024 Jun 17 21:50 / # chown joost:users / # chmod a+w / # ls -ld / drwxrwxrwx  20 joost    users        1024 Jun 17 21:50 / # exit $ ls -ld / drwxr-xr-x  20 root     root         1024 Jun 17 21:50 // $ ls -ld hda3 -rw-r--r--   1 joost    users           0 Jul  2 22:58 hda3
Only the effects that user joost could do anyway happen for real.
fakeroot was specifically written to enable users to create Debian GNU/Linux packages (in the deb(5) format) without giving them root privileges.  This can be done by commands like dpkg-buildpackage -rfakeroot or debuild -rfakeroot (actually, -rfakeroot is default in debuild nowadays, so you don't need that argument).
fakeroot is a regular, non-setuid program. It does not enhance a user's privileges, or decrease the system's security.
/usr/lib/*/libfakeroot-*.so The shared library containing the wrapper functions.
FAKEROOTKEY The key used to communicate with the fakeroot daemon. Any program started with the right LD_PRELOAD and a FAKEROOTKEY of a running daemon will automatically connect to that daemon, and have the same "fake" view of the file system's permissions/ownerships. (assuming the daemon and connecting program were started by the same user).
LD_PRELOAD Fakeroot is implemented by wrapping system calls.  This is accomplished by setting LD_LIBRARY_PATH=/usr/lib/fakeroot and LD_PRELOAD=libfakeroot.so.0.  That library is loaded before the system's C library, and so most of the library functions are intercepted by it.  If you need to set either LD_LIBRARY_PATH or LD_PRELOAD from within a fakeroot environment, it should be set relative to the given paths, as in LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/foo/bar/
Library versions Every command executed within fakeroot needs to be linked to the same version of the C library as fakeroot itself.
open()/create() fakeroot doesn't wrap open(), create(), etc. So, if user joost does either
touch foo fakeroot ls -al foo
or the other way around,
fakeroot touch foo ls -al foo
fakeroot has no way of knowing that in the first case, the owner of foo really should be joost while the second case it should have been root.  For the Debian packaging, defaulting to giving all "unknown" files uid=gid=0, is always OK. The real way around this is to wrap open() and create(), but that creates other problems, as demonstrated by the libtricks package. This package wrapped many more functions, and tried to do a lot more than fakeroot . It turned out that a minor upgrade of libc (from one where the stat() function didn't use open() to one with a stat() function that did (in some cases) use open()), would cause unexplainable segfaults (that is, the libc6 stat() called the wrapped open(), which would then call the libc6 stat(), etc).  Fixing them wasn't all that easy, but once fixed, it was just a matter of time before another function started to use open(), never mind trying to port it to a different operating system. Thus I decided to keep the number of functions wrapped by fakeroot as small as possible, to limit the likelihood of ‘collisions’.
GNU configure (and other such programs) fakeroot, in effect, is changing the way the system behaves. Programs that probe the system like GNU configure may get confused by this (or if they don't, they may stress fakeroot so much that fakeroot itself becomes confused). So, it's advisable not to run "configure" from within fakeroot. As configure should be called in the "debian/rules build" target, running "dpkg-buildpackage -rfakeroot" correctly takes care of this.
It doesn't wrap open(). This isn't bad by itself, but if a program does open("file", O_WRONLY, 000), writes to file "file", closes it, and then again tries to open to read the file, then that open fails, as the mode of the file will be 000. The bug is that if root does the same, open() will succeed, as the file permissions aren't checked at all for root. I choose not to wrap open(), as open() is used by many other functions in libc (also those that are already wrapped), thus creating loops (or possible future loops, when the implementation of various libc functions slightly change).
fakeroot is distributed under the GNU General Public License.  (GPL 2.0 or greater).
joost witteveen <joostje@debian.org>
Clint Adams <clint@debian.org>
Timo Savola
mostly by J.H.M. Dassen <jdassen@debian.org> Rather a lot mods/additions by joost and Clint.
faked(1) dpkg-buildpackage(1), debuild(1) /usr/share/doc/fakeroot/DEBUG
SPEED(1)                             OpenSSL                            SPEED(1)
openssl-speed, speed - test library performance
openssl speed [-help] [-engine id] [-elapsed] [-evp algo] [-decrypt] [-rand file...]  [-writerand file] [-primes num] [-seconds num] [-bytes num] [algorithm...]
This command is used to test the performance of cryptographic algorithms. To see the list of supported algorithms, use the list --digest-commands or list --cipher-commands command. The global CSPRNG is denoted by the rand algorithm name.
-engine id Specifying an engine (by its unique id string) will cause speed to attempt to obtain a functional reference to the specified engine, thus initialising it if needed. The engine will then be set as the default for all available algorithms.
-elapsed When calculating operations- or bytes-per-second, use wall-clock time instead of CPU user time as divisor. It can be useful when testing speed of hardware engines.
-evp algo Use the specified cipher or message digest algorithm via the EVP interface.  If algo is an AEAD cipher, then you can pass <-aead> to benchmark a TLS-like sequence. And if algo is a multi-buffer capable cipher, e.g.  aes-128-cbc-hmac-sha1, then -mb will time multi-buffer operation.
-decrypt Time the decryption instead of encryption. Affects only the EVP testing.
-primes num Generate a num-prime RSA key and use it to run the benchmarks. This option is only effective if RSA algorithm is specified to test.
-seconds num Run benchmarks for num seconds.
-bytes num Run benchmarks on num-byte buffers. Affects ciphers, digests and the CSPRNG.
[zero or more test algorithms] If any options are given, speed tests those algorithms, otherwise a pre-compiled grand selection is tested.
BLUETOOTHCTL(1)              General Commands Manual             BLUETOOTHCTL(1)
bluetoothctl: - interactive bluetooth control tool
bluetoothctl ver 5.49 Usage:
bluetoothctl [options]
--agent Register agent handler: <capability>
--timeout Timeout in seconds for non-interactive mode
--version Display version
CHOOSE(3)                   libdill Library Functions                  CHOOSE(3)
choose - performs one of multiple channel operations
#include <libdill.h>
struct chclause { int op; int ch; void *val; size_t len; };
int choose( struct chclause* clauses, int nclauses, int64_t deadline);
Accepts a list of channel operations.  Performs one that can be done first.  If multiple operations can be done immediately, the one that comes earlier in the array is executed.
clauses: Operations to choose from.  See below.
nclauses: Number of clauses.
deadline: A point in time when the operation should time out, in milliseconds.  Use the now function to get your current point in time.  0 means immediate timeout, i.e., perform the operation if possible or return without blocking if not.  -1 means no deadline, i.e., the call will block forever if the operation cannot be performed.
The fields in chclause structure are as follows:
• op: Operation to perform.  Either CHSEND or CHRECV.
• ch: The channel to perform the operation on.
• val: Buffer containing the value to send or receive.
• len: Size of the buffer.
In case of success the function returns index of the clause that caused the function to exit.  In case of error it returns -1 and sets errno to one of the values below.
Even if an index is returned, errno may still be set to an error value. The operation was successfull only if errno is set to zero.
• ECANCELED: Current coroutine was canceled.
• EINVAL: Invalid argument.
• ETIMEDOUT: Deadline was reached.
Additionally, if the function returns an index it can set errno to one of the following values:
• 0: Operation was completed successfully.
• EBADF: Invalid handle.
• EINVAL: Invalid parameter.
• EMSGSIZE: The peer expected a message with different size.
• ENOTSUP: Operation not supported.  Presumably, the handle isn't a channel.
• EPIPE: Channel has been closed with chdone.
int val1 = 0; int val2; struct chclause clauses[] = { {CHSEND, ch, &val1, sizeof(val1)}, {CHRECV, ch, &val2, sizeof(val2)} }; int rc = choose(clauses, 2, now() + 1000); if(rc == -1) { perror("Choose failed"); exit(1); } if(rc == 0) { printf("Value %d sent.\n", val1); } if(rc == 1) { printf("Value %d received.\n", val2); }
chdone(3) chmake(3) chmake_mem(3) chrecv(3) chsend(3) now(3)
SQLMAP(1)                         User Commands                        SQLMAP(1)
sqlmap - automatic SQL injection tool
python sqlmap [options]
-h, --help Show basic help message and exit
-hh    Show advanced help message and exit
-v VERBOSE Verbosity level: 0-6 (default 1)
At least one of these options has to be provided to define the target(s)
-d DIRECT Connection string for direct database connection
-u URL, --url=URL Target URL (e.g. "http://www.site.com/vuln.php?id=1")
-l LOGFILE Parse target(s) from Burp or WebScarab proxy log file
-x SITEMAPURL Parse target(s) from remote sitemap(.xml) file
-m BULKFILE Scan multiple targets given in a textual file
-r REQUESTFILE Load HTTP request from a file
-g GOOGLEDORK Process Google dork results as target URLs
-c CONFIGFILE Load options from a configuration INI file
These options can be used to specify how to connect to the target URL
--method=METHOD Force usage of given HTTP method (e.g. PUT)
--data=DATA Data string to be sent through POST
--param-del=PARA.. Character used for splitting parameter values
--cookie=COOKIE HTTP Cookie header value
--cookie-del=COO.. Character used for splitting cookie values
--load-cookies=L.. File containing cookies in Netscape/wget format
--drop-set-cookie Ignore Set-Cookie header from response
--user-agent=AGENT HTTP User-Agent header value
--random-agent Use randomly selected HTTP User-Agent header value
--host=HOST HTTP Host header value
--referer=REFERER HTTP Referer header value
-H HEADER, --hea.. Extra header (e.g. "X-Forwarded-For: 127.0.0.1")
--headers=HEADERS Extra headers (e.g. "Accept-Language: fr\nETag: 123")
--auth-type=AUTH.. HTTP authentication type (Basic, Digest, NTLM or PKI)
--auth-cred=AUTH.. HTTP authentication credentials (name:password)
--auth-file=AUTH.. HTTP authentication PEM cert/private key file
--ignore-401 Ignore HTTP Error 401 (Unauthorized)
--proxy=PROXY Use a proxy to connect to the target URL
--proxy-cred=PRO.. Proxy authentication credentials (name:password)
--proxy-file=PRO.. Load proxy list from a file
--ignore-proxy Ignore system default proxy settings
--tor  Use Tor anonymity network
--tor-port=TORPORT Set Tor proxy port other than default
--tor-type=TORTYPE Set Tor proxy type (HTTP (default), SOCKS4 or SOCKS5)
--check-tor Check to see if Tor is used properly
--delay=DELAY Delay in seconds between each HTTP request
--timeout=TIMEOUT Seconds to wait before timeout connection (default 30)