neulab/tldr huggingface dataset:
H The computer will fill in one number for you. If you are pretty close to finishing he might not want to help you.  And if you did something wrong so far, he will not say anything.
-h Print help.
-v Display version information.
-c Do not use colors. Black and white mode. Some terminals don't support colors, use this option in this case.
-d Choose difficulty.  Available options are: easy, normal, hard
-s User provided stream.  The user can provide a sudoku himself. Nudoku won't generate it in this case. Notation is in stream format, meaning everthing in one line. Use dots (.) for empy fields.  Example: nudoku -s 4.....8.5.3..........7......2.....6.....8.4......1.......6.3.7.5..2.....1.4......
No known bugs.
Michael Vetter (jubalh@openmailbox.org)
SYSCTL(2)                   Linux Programmer's Manual                  SYSCTL(2)
sysctl - read/write system parameters
#include <unistd.h> #include <linux/sysctl.h>
int _sysctl(struct __sysctl_args *args);
This system call no longer exists on current kernels!  See NOTES.
The _sysctl() call reads and/or writes kernel parameters.  For example, the hostname, or the maximum number of open files.  The argument has the form
struct __sysctl_args { int    *name;    /* integer vector describing variable */ int     nlen;    /* length of this vector */ void   *oldval;  /* 0 or address where to store old value */ size_t *oldlenp; /* available room for old value, overwritten by actual size of old value */ void   *newval;  /* 0 or address of new value */ size_t  newlen;  /* size of new value */ };
This call does a search in a tree structure, possibly resembling a directory tree under /proc/sys, and if the requested item is found calls some appropriate routine to read or modify the value.
Upon successful completion, _sysctl() returns 0.  Otherwise, a value of -1 is returned and errno is set to indicate the error.
EACCES, EPERM No search permission for one of the encountered "directories", or no read permission where oldval was nonzero, or no write permission where newval was nonzero.
EFAULT The invocation asked for the previous value by setting oldval non- NULL, but allowed zero room in oldlenp.
ENOTDIR name was not found.
This system call first appeared in Linux 1.3.57.  It was removed in Linux 5.5; glibc support was removed in version 2.32.
This call is Linux-specific, and should not be used in programs intended to be portable.  It originated in 4.4BSD.  Only Linux has the /proc/sys mirror, and the object naming schemes differ between Linux and 4.4BSD, but the declaration of the sysctl() function is the same in both.
Use of this system call was long discouraged: since Linux 2.6.24, uses of this system call result in warnings in the kernel log, and in Linux 5.5, the system call was finally removed.  Use the /proc/sys interface instead.
Note that on older kernels where this system call still exists, it is available only if the kernel was configured with the CONFIG_SYSCTL_SYSCALL option.  Furthermore, glibc does not provide a wrapper for this system call, necessitating the use of syscall(2).
The object names vary between kernel versions, making this system call worthless for applications.
Not all available objects are properly documented.
It is not yet possible to change operating system by writing to /proc/sys/kernel/ostype.
#define _GNU_SOURCE #include <unistd.h> #include <sys/syscall.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <linux/sysctl.h>
int _sysctl(struct __sysctl_args *args );
#define OSNAMESZ 100
int main(void) { struct __sysctl_args args; char osname[OSNAMESZ]; size_t osnamelth; int name[] = { CTL_KERN, KERN_OSTYPE };
memset(&args, 0, sizeof(args)); args.name = name; args.nlen = sizeof(name)/sizeof(name[0]); args.oldval = osname; args.oldlenp = &osnamelth;
osnamelth = sizeof(osname);
if (syscall(SYS__sysctl, &args) == -1) { perror("_sysctl"); exit(EXIT_FAILURE); } printf("This machine is running %*s\n", osnamelth, osname); exit(EXIT_SUCCESS); }
proc(5)
This page is part of release 5.13 of the Linux man-pages project.  A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/.
GNUCASH(1)                    GnuCash Manual Pages                    GNUCASH(1)
gnucash-cli - command line tool to go with GnuCash
gnucash-cli [options] [ accounts.gnucash ]
gnucash-cli enables certain intraction with a gnucash datafile directly from the command line.
It has two modes: quotes mode and report mode.
Quotes Mode (activated with --quotes <cmd>) This mode has options to get online quotes for foreign currencies and stocks in the given data file. It supports the following command:
get    Retrieves online quotes. Note this requires Finance::Quote to be properly configured for your system.
The get command takes the following options:
--namespace=REGEXP Regular expression determining which namespace commodities will be retrieved.
Report Mode (activated with --report <cmd>) This mode has options to work with reports in the given data file.  It supports the following command:
run    Runs a report on the given data file.
The run command takes the following options:
--name=REPORT_NAME Name of the report to run
--export-type=TYPE Specify export type
General Options --version Show GnuCash version
--help Show this help message
--debug Enable debugging mode: increasing logging to provide deep detail.
--extra Enable extra/development/debugging features.
--log  Log level overrides, of the form "log.ger.path={debug,info,warn,crit,error}" This option can be specified multiple times.
--logto File to log into; defaults to "/tmp/gnucash.trace"; can be "stderr" or "stdout".
~/.gnucash/config.auto Automatically generated per-user configuration file.  DO NOT EDIT MANUALLY!
GNC_DEBUG Enable debugging output.  This allows you to turn on the debugging earlier in the startup process than you can with --debug.
GUILE_LOAD_PATH An override for the GnuCash scheme load path. You shouldn't need to alter this.  For more information see the README file.
GNC_MODULE_PATH An override for the GnuCash scheme load path for Gnucash modules. You shouldn't need to alter this.  For more information see the README file.
Please report any bugs using the bug reporting form on the GnuCash web site.
GnuCash has extensive on-line help available from the "help" menu.
Additional information and the latest version is available at the web site: https://www.gnucash.org
Robert Merkel <rgmerk@mira.net> wrote this manpage.
GnuCash was written by Robin Clark, Linas Vepstas, and a cast of thousands.
GIT-TAG(1)                         Git Manual                         GIT-TAG(1)
git-tag - Create, list, delete or verify a tag object signed with GPG
git tag [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e] <tagname> [<commit> | <object>] git tag -d <tagname>... git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>] [--points-at <object>] [--column[=<options>] | --no-column] [--create-reflog] [--sort=<key>] [--format=<format>] [--merged <commit>] [--no-merged <commit>] [<pattern>...] git tag -v [--format=<format>] <tagname>...
Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags.
Unless -f is given, the named tag must not yet exist.
If one of -a, -s, or -u <keyid> is passed, the command creates a tag object, and requires a tag message. Unless -m <msg> or -F <file> is given, an editor is started for the user to type in the tag message.
If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied.
Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created.
A GnuPG signed tag object will be created when -s or -u <keyid> is used. When -u <keyid> is not used, the committer identity for the current user is used to find the GnuPG key for signing. The configuration variable gpg.program is used to specify custom GnuPG binary.
Tag objects (created with -a, -s, or -u) are called "annotated" tags; they contain a creation date, the tagger name and e-mail, a tagging message, and an optional GnuPG signature. Whereas a "lightweight" tag is simply a name for an object (usually a commit object).
Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like git describe) will ignore lightweight tags by default.
-a, --annotate Make an unsigned, annotated tag object
-s, --sign Make a GPG-signed tag, using the default e-mail address’s key. The default behavior of tag GPG-signing is controlled by tag.gpgSign configuration variable if it exists, or disabled otherwise. See git- config(1).
--no-sign Override tag.gpgSign configuration variable that is set to force each and every tag to be signed.
-u <keyid>, --local-user=<keyid> Make a GPG-signed tag, using the given key.
-f, --force Replace an existing tag with the given name (instead of failing)
-d, --delete Delete existing tags with the given names.
-v, --verify Verify the GPG signature of the given tag names.
-n<num> <num> specifies how many lines from the annotation, if any, are printed when using -l. Implies --list.
The default is not to print any annotation lines. If no number is given to -n, only the first line is printed. If the tag is not annotated, the commit message is displayed instead.
-l, --list List tags. With optional <pattern>..., e.g.  git tag --list 'v-*', list only the tags that match the pattern(s).
Running "git tag" without arguments also lists all tags. The pattern is a shell wildcard (i.e., matched using fnmatch(3)). Multiple patterns may be given; if any of them matches, the tag is shown.
This option is implicitly supplied if any other list-like option such as --contains is provided. See the documentation for each of those options for details.
--sort=<key> Sort based on the key given. Prefix - to sort in descending order of the value. You may use the --sort=<key> option multiple times, in which case the last key becomes the primary key. Also supports "version:refname" or "v:refname" (tag names are treated as versions). The "version:refname" sort order can also be affected by the "versionsort.suffix" configuration variable. The keys supported are the same as those in git for-each-ref. Sort order defaults to the value configured for the tag.sort variable if it exists, or lexicographic order otherwise. See git-config(1).
--color[=<when>] Respect any colors specified in the --format option. The <when> field must be one of always, never, or auto (if <when> is absent, behave as if always was given).
-i, --ignore-case Sorting and filtering tags are case insensitive.
--column[=<options>], --no-column Display tag listing in columns. See configuration variable column.tag for option syntax.  --column and --no-column without options are equivalent to always and never respectively.
This option is only applicable when listing tags without annotation lines.
--contains [<commit>] Only list tags which contain the specified commit (HEAD if not specified). Implies --list.
--no-contains [<commit>] Only list tags which don’t contain the specified commit (HEAD if not specified). Implies --list.
--merged [<commit>] Only list tags whose commits are reachable from the specified commit (HEAD if not specified).
--no-merged [<commit>] Only list tags whose commits are not reachable from the specified commit (HEAD if not specified).
--points-at <object> Only list tags of the given object (HEAD if not specified). Implies --list.
-m <msg>, --message=<msg> Use the given tag message (instead of prompting). If multiple -m options are given, their values are concatenated as separate paragraphs. Implies -a if none of -a, -s, or -u <keyid> is given.
-F <file>, --file=<file> Take the tag message from the given file. Use - to read the message from the standard input. Implies -a if none of -a, -s, or -u <keyid> is given.
-e, --edit The message taken from file with -F and command line with -m are usually used as the tag message unmodified. This option lets you further edit the message taken from these sources.
--cleanup=<mode> This option sets how the tag message is cleaned up. The <mode> can be one of verbatim, whitespace and strip. The strip mode is default. The verbatim mode does not change message at all, whitespace removes just leading/trailing whitespace lines and strip removes both whitespace and commentary.
--create-reflog Create a reflog for the tag. To globally enable reflogs for tags, see core.logAllRefUpdates in git-config(1). The negated form --no-create-reflog only overrides an earlier --create-reflog, but currently does not negate the setting of core.logAllRefUpdates.
--format=<format> A string that interpolates %(fieldname) from a tag ref being shown and the object it points at. The format is the same as that of git- for-each-ref(1). When unspecified, defaults to %(refname:strip=2).
<tagname> The name of the tag to create, delete, or describe. The new tag name must pass all checks defined by git-check-ref-format(1). Some of these checks may restrict the characters allowed in a tag name.
<commit>, <object> The object that the new tag will refer to, usually a commit. Defaults to HEAD.
By default, git tag in sign-with-default mode (-s) will use your committer identity (of the form Your Name <your@email.address>) to find a key. If you want to use a different default key, you can specify it in the repository configuration as follows:
[user] signingKey = <gpg-keyid>
pager.tag is only respected when listing tags, i.e., when -l is used or implied. The default is to use a pager. See git-config(1).
On Re-tagging What should you do when you tag a wrong commit and you would want to re-tag?
If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you’re done.
But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:
1. The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.
2. The insane thing. You really want to call the new version "X" too, even though others have already seen the old one. So just use git tag -f again, as if you hadn’t already published the old one.
However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.
If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying:
Ok, I messed up, and I pushed out an earlier version tagged as X. I then fixed something, and retagged the *fixed* tree as X again.
If you got the wrong tag, and want the new one, please delete the old one and fetch the new one by doing:
git tag -d X git fetch origin tag X
to get my updated tag.
You can test which tag you have by doing
git rev-parse X
which should return 0123456789abcdef.. if you have the new version.
Does this seem a bit complicated? It should be. There is no way that it would be correct to just "fix" it automatically. People need to know that their tags might have been changed.
On Automatic following If you are following somebody else’s tree, you are most likely using remote-tracking branches (eg. refs/remotes/origin/master). You usually want the tags from the other end.
On the other hand, if you are fetching because you would want a one-shot merge from somebody else, you typically do not want to get tags from there. This happens more often for people near the toplevel but not limited to them. Mere mortals when pulling from each other do not necessarily want to automatically get private anchor point tags from the other person.
Often, "please pull" messages on the mailing list just provide two pieces of information: a repo URL and a branch name; this is designed to be easily cut&pasted at the end of a git fetch command line:
Linus, please pull from
git://git..../proj.git master
to get the following updates...
$ git pull git://git..../proj.git master
In such a case, you do not want to automatically follow the other person’s tags.
One important aspect of Git is its distributed nature, which largely means there is no inherent "upstream" or "downstream" in the system. On the face of it, the above example might seem to indicate that the tag namespace is owned by the upper echelon of people and that tags only flow downwards, but that is not the case. It only shows that the usage pattern determines who are interested in whose tags.
A one-shot pull is a sign that a commit history is now crossing the boundary between one circle of people (e.g. "people who are primarily interested in the networking part of the kernel") who may have their own set of tags (e.g. "this is the third release candidate from the networking group to be proposed for general consumption with 2.6.21 release") to another circle of people (e.g. "people who integrate various subsystem improvements"). The latter are usually not interested in the detailed tags used internally in the former group (that is what "internal" means). That is why it is desirable not to follow tags automatically in this case.
It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking each other’s progress by having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.
On Backdating Tags If you have imported some changes from another VCS and would like to add tags for major releases of your work, it is useful to be able to specify the date to embed inside of the tag object; such data in the tag object affects, for example, the ordering of tags in the gitweb interface.
To set the date used in future tag objects, set the environment variable GIT_COMMITTER_DATE (see the later discussion of possible values; the most common form is "YYYY-MM-DD HH:MM").
$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
git-check-ref-format(1). git-config(1).
HEXDUMP(1)                        User Commands                       HEXDUMP(1)
hexdump - display file contents in hexadecimal, decimal, octal, or ascii
hexdump options file ...
hd options file ...
The hexdump utility is a filter which displays the specified files, or standard input if no files are specified, in a user-specified format.
Below, the length and offset arguments may be followed by the multiplicative suffixes KiB (=1024), MiB (=1024*1024), and so on for GiB, TiB, PiB, EiB, ZiB and YiB (the "iB" is optional, e.g., "K" has the same meaning as "KiB"), or the suffixes KB (=1000), MB (=1000*1000), and so on for GB, TB, PB, EB, ZB and YB.
-b, --one-byte-octal One-byte octal display. Display the input offset in hexadecimal, followed by sixteen space-separated, three-column, zero-filled bytes of input data, in octal, per line.
-c, --one-byte-char One-byte character display. Display the input offset in hexadecimal, followed by sixteen space-separated, three-column, space-filled characters of input data per line.
-C, --canonical Canonical hex+ASCII display. Display the input offset in hexadecimal, followed by sixteen space-separated, two-column, hexadecimal bytes, followed by the same sixteen bytes in %_p format enclosed in '|' characters. Invoking the program as hd implies this option.
-d, --two-bytes-decimal Two-byte decimal display. Display the input offset in hexadecimal, followed by eight space-separated, five-column, zero-filled, two-byte units of input data, in unsigned decimal, per line.
-e, --format format_string Specify a format string to be used for displaying data.
-f, --format-file file Specify a file that contains one or more newline-separated format strings. Empty lines and lines whose first non-blank character is a hash mark (#) are ignored.
-L, --color[=when] Accept color units for the output. The optional argument when can be auto, never or always. If the when argument is omitted, it defaults to auto. The colors can be disabled; for the current built-in default see the --help output. See also the Colors subsection and the COLORS section below.
-n, --length length Interpret only length bytes of input.
-o, --two-bytes-octal Two-byte octal display. Display the input offset in hexadecimal, followed by eight space-separated, six-column, zero-filled, two-byte quantities of input data, in octal, per line.
-s, --skip offset Skip offset bytes from the beginning of the input.
-v, --no-squeezing The -v option causes hexdump to display all input data. Without the -v option, any number of groups of output lines which would be identical to the immediately preceding group of output lines (except for the input offsets), are replaced with a line comprised of a single asterisk.
-x, --two-bytes-hex Two-byte hexadecimal display. Display the input offset in hexadecimal, followed by eight space-separated, four-column, zero-filled, two-byte quantities of input data, in hexadecimal, per line.
For each input file, hexdump sequentially copies the input to standard output, transforming the data according to the format strings specified by the -e and -f options, in the order that they were specified.
A format string contains any number of format units, separated by whitespace. A format unit contains up to three items: an iteration count, a byte count, and a format.
The iteration count is an optional positive integer, which defaults to one. Each format is applied iteration count times.
The byte count is an optional positive integer. If specified it defines the number of bytes to be interpreted by each iteration of the format.
If an iteration count and/or a byte count is specified, a single slash must be placed after the iteration count and/or before the byte count to disambiguate them. Any whitespace before or after the slash is ignored.
The format is required and must be surrounded by double quote (" ") marks. It is interpreted as a fprintf-style format string (see fprintf(3), with the following exceptions:
1. An asterisk (*) may not be used as a field width or precision.
2. A byte count or field precision is required for each s conversion character (unlike the fprintf3 default which prints the entire string if the precision is unspecified).
3. The conversion characters h, l, n, p, and q are not supported.
4. The single character escape sequences described in the C standard are supported:
┌──────────────────┬────┐ │                  │    │ │NULL              │ \0 │ ├──────────────────┼────┤ │                  │    │ │<alert character> │ \a │ ├──────────────────┼────┤ │                  │    │ │<backspace>       │ \b │ ├──────────────────┼────┤ │                  │    │ │<form-feed>       │ \f │ ├──────────────────┼────┤ │                  │    │ │<newline>         │ \n │ ├──────────────────┼────┤ │                  │    │ │<carriage return> │ \r │ ├──────────────────┼────┤ │                  │    │ │<tab>             │ \t │ ├──────────────────┼────┤ │                  │    │ │<vertical tab>    │ \v │ └──────────────────┴────┘
Conversion strings The hexdump utility also supports the following additional conversion strings.
_a[dox] Display the input offset, cumulative across input files, of the next byte to be displayed. The appended characters d, o, and x specify the display base as decimal, octal or hexadecimal respectively.
_A[dox] Identical to the _a conversion string except that it is only performed once, when all of the input data has been processed.
_c Output characters in the default character set. Non-printing characters are displayed in three-character, zero-padded octal, except for those representable by standard escape notation (see above), which are displayed as two-character strings.
_p Output characters in the default character set. Non-printing characters are displayed as a single '.'.
_u Output US ASCII characters, with the exception that control characters are displayed using the following, lower-case, names. Characters greater than 0xff, hexadecimal, are displayed as hexadecimal strings.
┌────────┬─────────┬─────────┬─────────┬─────────┬─────────┐ │        │         │         │         │         │         │ │000 nul │ 001 soh │ 002 stx │ 003 etx │ 004 eot │ 005 enq │ ├────────┼─────────┼─────────┼─────────┼─────────┼─────────┤ │        │         │         │         │         │         │ │006 ack │ 007 bel │ 008 bs  │ 009 ht  │ 00A lf  │ 00B vt  │ ├────────┼─────────┼─────────┼─────────┼─────────┼─────────┤ │        │         │         │         │         │         │ │00C ff  │ 00D cr  │ 00E so  │ 00F si  │ 010 dle │ 011 dc1 │ ├────────┼─────────┼─────────┼─────────┼─────────┼─────────┤ │        │         │         │         │         │         │ │012 dc2 │ 013 dc3 │ 014 dc4 │ 015 nak │ 016 syn │ 017 etb │ ├────────┼─────────┼─────────┼─────────┼─────────┼─────────┤ │        │         │         │         │         │         │ │018 can │ 019 em  │ 01A sub │ 01B esc │ 01C fs  │ 01D gs  │ ├────────┼─────────┼─────────┼─────────┼─────────┼─────────┤ │        │         │         │         │         │         │ │01E rs  │ 01F us  │ 0FF del │         │         │         │ └────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
Colors When put at the end of a format specifier, hexdump highlights the respective string with the color specified. Conditions, if present, are evaluated prior to highlighting.
_L[color_unit_1,color_unit_2,...,color_unit_n]
The full syntax of a color unit is as follows:
[!]COLOR[:VALUE][@OFFSET_START[-END]]
! Negate the condition. Please note that it only makes sense to negate a unit if both a value/string and an offset are specified. In that case the respective output string will be highlighted if and only if the value/string does not match the one at the offset.
COLOR One of the 8 basic shell colors.
VALUE A value to be matched specified in hexadecimal, or octal base, or as a string. Please note that the usual C escape sequences are not interpreted by hexdump inside the color_units.
OFFSET An offset or an offset range at which to check for a match. Please note that lone OFFSET_START uses the same value as END offset.
Counters The default and supported byte counts for the conversion characters are as follows:
%_c, %_p, %_u, %c One byte counts only.
%d, %i, %o, %u, %X, %x Four byte default, one, two and four byte counts supported.
%E, %e, %f, %G, %g Eight byte default, four byte counts supported.
The amount of data interpreted by each format string is the sum of the data required by each format unit, which is the iteration count times the byte count, or the iteration count times the number of bytes required by the format if the byte count is not specified.
The input is manipulated in blocks, where a block is defined as the largest amount of data specified by any format string. Format strings interpreting less than an input block’s worth of data, whose last format unit both interprets some number of bytes and does not have a specified iteration count, have the iteration count incremented until the entire input block has been processed or there is not enough data remaining in the block to satisfy the format string.
If, either as a result of user specification or hexdump modifying the iteration count as described above, an iteration count is greater than one, no trailing whitespace characters are output during the last iteration.
It is an error to specify a byte count as well as multiple conversion characters or strings unless all but one of the conversion characters or strings is _a or _A.
If, as a result of the specification of the -n option or end-of-file being reached, input data only partially satisfies a format string, the input block is zero-padded sufficiently to display all available data (i.e., any format units overlapping the end of data will display some number of the zero bytes).
Further output by such format strings is replaced by an equivalent number of spaces. An equivalent number of spaces is defined as the number of spaces output by an s conversion character with the same field width and precision as the original conversion character or conversion string but with any '+', ' ', '#' conversion flag characters removed, and referencing a NULL string.
If no format strings are specified, the default display is very similar to the -x output format (the -x option causes more space to be used between format units than in the default output).
hexdump exits 0 on success and > 0 if an error occurred.
The hexdump utility is expected to be IEEE Std 1003.2 ("POSIX.2") compatible.
Display the input in perusal format:
"%06.6_ao "  12/1 "%3_u " "\t" "%_p " "\n"
Implement the -x option:
"%07.7_Ax\n" "%07.7_ax  " 8/2 "%04x " "\n"
MBR Boot Signature example: Highlight the addresses cyan and the bytes at offsets 510 and 511 green if their value is 0xAA55, red otherwise.
"%07.7_Ax_L[cyan]\n" "%07.7_ax_L[cyan]  " 8/2 "   %04x_L[green:0xAA55@510-511,!red:0xAA55@510-511] " "\n"
Implicit coloring can be disabled by an empty file /etc/terminal-colors.d/hexdump.disable.
See terminal-colors.d(5) for more details about colorization configuration.
The hexdump command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
PYGMENTIZE(1)                General Commands Manual               PYGMENTIZE(1)
pygmentize - highlights the input file
pygmentize [-l <lexer> | -g] [-F <filter>[:<options>]] [-f <formatter>] [-O <options>] [-P <option=value>] [-o <outfile>] [<infile>] pygmentize -S <style> -f <formatter> [-a <arg>] [-O <options>] [-P <option=value>] pygmentize -L [<which> ...] pygmentize -N <filename> pygmentize -C pygmentize -H <type> <name> pygmentize -h | -V
Pygments is a generic syntax highlighter for general use in all kinds of software such as forum systems, wikis or other applications that need to prettify source code.
Its highlights are: * a wide range of common languages and markup formats is supported * special attention is paid to details, increasing quality by a fair amount * support for new languages and formats are added easily * a number of output formats, presently HTML, LaTeX and ANSI sequences * it is usable as a command-line tool and as a library * ... and it highlights even Brainfuck!
pygmentize is a command that uses Pygments to highlight the input file and write the result to <outfile>. If no <infile> is given, stdin is used.
-l <lexer> Set the lexer name. If not given, the lexer is guessed from the extension of the input file name (this obviously doesn't work if the input is stdin).
-g     Attempt to guess the lexer from the file contents, or pass through as plain text if this fails (this option works for highlighting standard input).
-F <filter>[:<options>] Add a filter to the token stream. You can give options in the same way as for -O after a colon (note: there must not be spaces around the colon).  This option can be given multiple times.
-f <formatter> Set the formatter name. If not given, it will be guessed from the extension of the output file name. If no output file is given, the terminal formatter will be used by default.
-o <outfile> Set output file. If not given, stdout is used.
-O <options> With this option, you can give the lexer and formatter a comma- separated list of options, e.g. "-O bg=light,python=cool". Which options are valid for which lexers and formatters can be found in the documentation.  This option can be given multiple times.
-P <option=value> This option adds lexer and formatter options like the -O option, but you can only give one option per -P. That way, the option value may contain commas and equals signs, which it can't with -O.
-S <style> Print out style definitions for style <style> and for formatter <formatter>.  The meaning of the argument given by -a <arg> is formatter dependent and can be found in the documentation.
-L [<which> ...] List lexers, formatters, styles or filters. Set <which> to the thing you want to list (e.g. "styles"), or omit it to list everything.
-N <filename> Guess and print out a lexer name based solely on the given filename.  Does not take input or highlight anything.  If no specific lexer can be found, "text" is printed.
-C     Like -N, but guess a lexer based on content read from standard input.
-H <type> <name> Print detailed help for the object <name> of type <type>, where <type> is one of "lexer", "formatter" or "filter".
-h     Show help screen.
-V     Show version of the Pygments package.
/usr/share/doc/python-pygments/index.html
pygmentize was written by Georg Brandl <g.brandl@gmx.net>.
This manual page was written by Piotr Ozarowski <ozarow@gmail.com>, for the Debian project (but may be used by others).
ICONV(1P)                   POSIX Programmer's Manual                  ICONV(1P)
iconv — codeset conversion
iconv [-cs] -f frommap -t tomap [file...]
iconv -f fromcode [-cs] [-t tocode] [file...]
iconv -t tocode [-cs] [-f fromcode] [file...]
iconv -l
The iconv utility shall convert the encoding of characters in file from one codeset to another and write the results to standard output.
When the options indicate that charmap files are used to specify the codesets (see OPTIONS), the codeset conversion shall be accomplished by performing a logical join on the symbolic character names in the two charmaps. The implementation need not support the use of charmap files for codeset conversion unless the POSIX2_LOCALEDEF symbol is defined on the system.
The iconv utility shall conform to the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines.
-c        Omit any characters that are invalid in the codeset of the input file from the output. When -c is not used, the results of encountering invalid characters in the input stream (either those that are not characters in the codeset of the input file or that have no corresponding character in the codeset of the output file) shall be specified in the system documentation. The presence or absence of -c shall not affect the exit status of iconv.
-f fromcodeset Identify the codeset of the input file. The implementation shall recognize the following two forms of the fromcodeset option-argument:
fromcode  The fromcode option-argument must not contain a <slash> character. It shall be interpreted as the name of one of the codeset descriptions provided by the implementation in an unspecified format. Valid values of fromcode are implementation-defined.
frommap   The frommap option-argument must contain a <slash> character. It shall be interpreted as the pathname of a charmap file as defined in the Base Definitions volume of POSIX.1‐2017, Section 6.4, Character Set Description File.  If the pathname does not represent a valid, readable charmap file, the results are undefined.
If this option is omitted, the codeset of the current locale shall be used.
-l        Write all supported fromcode and tocode values to standard output in an unspecified format.
-s        Suppress any messages written to standard error concerning invalid characters. When -s is not used, the results of encountering invalid characters in the input stream (either those that are not valid characters in the codeset of the input file or that have no corresponding character in the codeset of the output file) shall be specified in the system documentation. The presence or absence of -s shall not affect the exit status of iconv.
-t tocodeset Identify the codeset to be used for the output file. The implementation shall recognize the following two forms of the tocodeset option-argument:
tocode    The semantics shall be equivalent to the -f fromcode option.
tomap     The semantics shall be equivalent to the -f frommap option.
If either -f or -t represents a charmap file, but the other does not (or is omitted), or both -f and -t are omitted, the results are undefined.
file      A pathname of an input file. If no file operands are specified, or if a file operand is '-', the standard input shall be used.
The standard input shall be used only if no file operands are specified, or if a file operand is '-'.
The following environment variables shall affect the execution of iconv:
LC_CTYPE  Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments). During translation of the file, this variable is superseded by the use of the fromcode option-argument.
When the -l option is used, the standard output shall contain all supported fromcode and tocode values, written in an unspecified format.
When the -l option is not used, the standard output shall contain the sequence of characters read from the input files, translated to the specified codeset. Nothing else shall be written to the standard output.
The user must ensure that both charmap files use the same symbolic names for characters the two codesets have in common.
The following example converts the contents of file mail.x400 from the ISO/IEC 6937:2001 standard codeset to the ISO/IEC 8859‐1:1998 standard codeset, and stores the results in file mail.local:
iconv -f IS6937 -t IS8859 mail.x400 > mail.local
The iconv utility can be used portably only when the user provides two charmap files as option-arguments. This is because a single charmap provided by the user cannot reliably be joined with the names in a system-provided character set description. The valid values for fromcode and tocode are implementation-defined and do not have to have any relation to the charmap mechanisms. As an aid to interactive users, the -l option was adopted from the Plan 9 operating system. It writes information concerning these implementation-defined values. The format is unspecified because there are many possible useful formats that could be chosen, such as a matrix of valid combinations of fromcode and tocode. The -l option is not intended for shell script usage; conforming applications will have to use charmaps.
The iconv utility may support the conversion between ASCII and EBCDIC- based encodings, but is not required to do so. In an XSI-compliant implementation, the dd utility is the only method guaranteed to support conversion between these two character sets.
dd, gencat
The Base Definitions volume of POSIX.1‐2017, Section 6.4, Character Set Description File, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines
UNEXPAND(1)                       User Commands                      UNEXPAND(1)
unexpand - convert spaces to tabs
unexpand [OPTION]... [FILE]...
Convert blanks in each FILE to tabs, writing to standard output.
-a, --all convert all blanks, instead of just initial blanks
--first-only convert only leading sequences of blanks (overrides -a)
-t, --tabs=N have tabs N characters apart instead of 8 (enables -a)
-t, --tabs=LIST use comma separated list of tab positions.  The last specified position can be prefixed with '/' to specify a tab size to use after the last explicitly specified tab stop.  Also a prefix of '+' can be used to align remaining tab stops relative to the last specified tab stop instead of the first column
Full documentation <https://www.gnu.org/software/coreutils/unexpand> or available locally via: info '(coreutils) unexpand invocation'
conky(1)                                                                conky(1)
conky - A system monitor for X originally based on the torsmo code, but more kickass. It just keeps on given'er. Yeah.
conky [ options ]
Conky is a system monitor for X originally based on torsmo.  Since its inception, Conky has changed significantly from its predecessor, while maintaining simplicity and configurability. Conky can display just about anything, either on your root desktop or in its own window. Not only does Conky have many built-in objects, it can also display just about any piece of information by using scripts and other external programs.
Conky has more than 250 built in objects, including support for a plethora of OS stats (uname, uptime, CPU usage, mem usage, disk usage, "top" like process stats, and network monitoring, just to name a few), built in IMAP and POP3 support, built in support for many popular music players (MPD, XMMS2, Audacious), and much much more. Conky can display this info either as text, or using simple progress bars and graph widgets, with different fonts and colours.
We are always looking for help, whether its reporting bugs, writing patches, or writing docs. Please use the facilities at SourceForge to make bug reports, feature requests, and submit patches, or stop by #conky on irc.freenode.net if you have questions or want to contribute.
Thanks for your interest in Conky.
For users compiling from source on a binary distro, make sure you have the X development libraries installed (Unless you configure your build without X11). This should be a package along the lines of "libx11-dev" or "xorg-x11-dev" for X11 libs, and similar "-dev" format for the other libs required (depending on your build options). You should be able to see which extra packages you need to install by reading errors that you get from running `cmake'. The easiest way to view the available build options is to run `ccmake' or `cmake-gui' from the source tree, but be careful when disabling certain features as you may lose desired functionality. E.g., with BUILD_MATH disabled you won't get errors but logarithmic graphs will be normal graphs and gauges will miss their line.
Conky has (for some time) been available in the repositories of most popular distributions. Here are some installation instructions for a few:
Gentoo users -- Conky is in Gentoo's Portage... simply use "emerge app- admin/conky" for installation.
Debian, etc. users -- Conky should be in your repositories, and can be installed by doing "aptitude install conky".
Example to compile and run Conky with default components (note that some build options may differ for your system):
cmake -D CMAKE_INSTALL_PREFIX:string=/usr .
make install # Optional
src/conky
Conky has been tested to be compatible with C99 C and C++0x C++, however it has not been tested with anything other than gcc, and is not guaranteed to work with other compilers.
TIP: Try configuring Conky with `ccmake' or `cmake-gui' instead of just `cmake'.
Conky is generally very good on resources. That said, the more you try to make Conky do, the more resources it is going to consume.
An easy way to force Conky to reload your ~/.config/conky/conky.conf: "killall -SIGUSR1 conky". Saves you the trouble of having to kill and then restart.
Command line options override configurations defined in configuration file.
-a | --alignment= ALIGNMENT Text alignment on screen, {top,bottom,middle}_{left,right,middle} or none. Can also be abbreviated with first chars of position, ie. tr for top_right. Only available with build flag BUILD_X11 enabled.
-b | --double-buffer Use double buffering (eliminates "flicker"). Only available with build flag BUILD_X11 enabled.
-c | --config= FILE Config file to load instead of ~/.config/conky/conky.conf.
-C | --print-config Print builtin default config to stdout. See also the section EXAMPLES for more information. Only available with build flag BUILD_BUILTIN_CONFIG enabled.
-d | --daemonize Daemonize Conky, aka fork to background.
-D | --debug Increase debugging output, ie. -DD for more debugging.
-f | --font= FONT Font to use. Only available with build flag BUILD_X11 enabled.
-h | --help Prints command line help and exits.
-i COUNT Number of times to update Conky (and quit).
-o | --own-window Create own window to draw. Only available with build flag BUILD_X11 enabled.
-p | --pause= SECONDS Time to pause/wait before actually starting Conky.
-q | --quiet Run Conky in 'quiet mode' (ie. no output).
-t | --text= TEXT Text to render, remember single quotes, like -t ' $uptime '.
-u | --interval= SECONDS Update interval.
-v | -V | --version Prints version, build information and general info. Exits after printing.
-w | --window-id= WIN_ID Window id to draw. Only available with build flag BUILD_X11 enabled.
-x X_COORDINATE X position.
-X | --display= DISPLAY X11 display to use. Only available with build flag BUILD_X11 enabled.
-y Y_COORDINATE Y position.
Default configuration file location is ~/.config/conky/conky.conf or ${sysconfdir}/conky/conky.conf. On most systems, sysconfdir is /etc, and you can find the sample config file there in /etc/conky/conky.conf.
You might want to copy it to ~/.config/conky/conky.conf and then start modifying it. Other configs can be found at https://github.com/brndnmtthws/conky.
alignment Aligned position on screen, may be top_left, top_right, top_middle, bottom_left, bottom_right, bottom_middle, middle_left, middle_middle, middle_right, or none (also can be abbreviated as tl, tr, tm, bl, br, bm, ml, mm, mr). See also gap_x and gap_y.
append_file Append the file given as argument.
background Boolean value, if true, Conky will be forked to background when started.
forced_redraw Boolean value, if true, Conky will redraw everything when you switch the workspace. This may cause delays/flickering on some WMs.
border_inner_margin Inner border margin in pixels (the margin between the border and text).
border_outer_margin Outer border margin in pixels (the margin between the border and the edge of the window).
border_width Border width in pixels.
colorN Predefine a color for use inside conky.text segments.  Substitute N by a digit between 0 and 9, inclusively. When specifying the color value in hex, omit the leading hash (#).
console_bar_fill A character to fill the console bars. (default: '#')
console_bar_unfill A character to unfill the console bars. (default: '.')
console_graph_ticks A comma-separated list of strings to use as the bars of a graph output to console/shell. The first list item is used for the minimum bar height and the last item is used for the maximum, e.g. " ,_,=,#".
cpu_avg_samples The number of samples to average for CPU monitoring.
default_bar_height Specify a default height for bars. If not specified, the default value is 6.
default_bar_width Specify a default width for bars. If not specified, the default value is 0, which causes the bar to expand to fit the width of your Conky window. If you set out_to_console = true, the default value will be 10 for the text version of the bar.
default_color Default color and border color.
default_gauge_height Specify a default height for gauges. If not specified, the default value is 25.
default_gauge_width Specify a default width for gauges. If not specified, the default value is 40.
default_graph_height Specify a default height for graphs. If not specified, the default value is 25.
default_graph_width Specify a default width for graphs. If not specified, the default value is 0, which causes the graph to expand to fit the width of your Conky window. If you set out_to_console = true, the text version of the graph will actually have no width and you will need to set a sensible default or set the height and width of each graph individually.
default_outline_color Default outline color.
default_shade_color Default shading color and border's shading color.
disable_auto_reload Enable to disable the inotify-based auto config reload feature.
diskio_avg_samples The number of samples to average for disk I/O monitoring.
display Specify an X display to connect to.
xinerama_head Specify a Xinerama head.
double_buffer Use the Xdbe extension? (eliminates flicker) It is highly recommended to use own window with this one so double buffer won't be so big.
draw_blended Boolean, blend when rendering drawn image? Some images blend incorrectly breaking alpha with ARBG visuals. This provides a possible work around by disabling blending. Defaults to true.
draw_borders Draw borders around text.
draw_graph_borders Draw borders around graphs.
draw_outline Draw outlines.
draw_shades Draw shades.
extra_newline Put an extra newline at the end when writing to stdout, useful for writing to awesome's wiboxes.
font   Font name in X, xfontsel can be used to get a nice font.
fontN  Predefine a font to be used in conky.text segments.  Substitute N by a number between 0 and 9 inclusive. Use the same format as a font variable.
format_human_readable If enabled, values which are in bytes will be printed in human readable format (i.e., KiB, MiB, etc). If disabled, the number of bytes is printed instead.