neulab/tldr huggingface dataset:
It uses showbranch.default multi-valued configuration items if no <rev> or <glob> is given on the command line.
<rev> Arbitrary extended SHA-1 expression (see gitrevisions(7)) that typically names a branch head or a tag.
<glob> A glob pattern that matches branch or tag names under refs/. For example, if you have many topic branches under refs/heads/topic, giving topic/* would show all of them.
-r, --remotes Show the remote-tracking branches.
-a, --all Show both remote-tracking branches and local branches.
--current With this option, the command includes the current branch to the list of revs to be shown when it is not given on the command line.
--topo-order By default, the branches and their commits are shown in reverse chronological order. This option makes them appear in topological order (i.e., descendant commits are shown before their parents).
--date-order This option is similar to --topo-order in the sense that no parent comes before all of its children, but otherwise commits are ordered according to their commit date.
--sparse By default, the output omits merges that are reachable from only one tip being shown. This option makes them visible.
--more=<n> Usually the command stops output upon showing the commit that is the common ancestor of all the branches. This flag tells the command to go <n> more common commits beyond that. When <n> is negative, display only the <reference>s given, without showing the commit ancestry tree.
--list Synonym to --more=-1
--merge-base Instead of showing the commit list, determine possible merge bases for the specified commits. All merge bases will be contained in all specified commits. This is different from how git-merge-base(1) handles the case of three or more commits.
--independent Among the <reference>s given, display only the ones that cannot be reached from any other <reference>.
--no-name Do not show naming strings for each commit.
--sha1-name Instead of naming the commits using the path to reach them from heads (e.g. "master~2" to mean the grandparent of "master"), name them with the unique prefix of their object names.
--topics Shows only commits that are NOT on the first branch given. This helps track topic branches by hiding any commit that is already in the main line of development. When given "git show-branch --topics master topic1 topic2", this will show the revisions given by "git rev-list ^master topic1 topic2"
-g, --reflog[=<n>[,<base>]] [<ref>] Shows <n> most recent ref-log entries for the given ref. If <base> is given, <n> entries going back from that entry. <base> can be specified as count or date. When no explicit <ref> parameter is given, it defaults to the current branch (or HEAD if it is detached).
--color[=<when>] Color the status sign (one of these: * !  + -) of each commit corresponding to the branch itâ€™s in. The value must be always (the default), never, or auto.
--no-color Turn off colored output, even when the configuration file gives the default to color output. Same as --color=never.
Note that --more, --list, --independent and --merge-base options are mutually exclusive.
Given N <references>, the first N lines are the one-line description from their commit message. The branch head that is pointed at by $GIT_DIR/HEAD is prefixed with an asterisk * character while other heads are prefixed with a ! character.
Following these N lines, one-line log for each commit is displayed, indented N places. If a commit is on the I-th branch, the I-th indentation character shows a + sign; otherwise it shows a space. Merge commits are denoted by a - sign. Each commit shows a short name that can be used as an extended SHA-1 to name that commit.
The following example shows three branches, "master", "fixes" and "mhf":
$ git show-branch master fixes mhf * [master] Add 'git show-branch'. ! [fixes] Introduce "reset type" flag to "git reset" ! [mhf] Allow "+remote:local" refspec to cause --force when fetching. --- + [mhf] Allow "+remote:local" refspec to cause --force when fetching. + [mhf~1] Use git-octopus when pulling more than one heads. +  [fixes] Introduce "reset type" flag to "git reset" + [mhf~2] "git fetch --force". + [mhf~3] Use .git/remote/origin, not .git/branches/origin. + [mhf~4] Make "git pull" and "git fetch" default to origin + [mhf~5] Infamous 'octopus merge' + [mhf~6] Retire git-parse-remote. + [mhf~7] Multi-head fetch. + [mhf~8] Start adding the $GIT_DIR/remotes/ support. *++ [master] Add 'git show-branch'.
These three branches all forked from a common commit, [master], whose commit message is "Add 'git show-branch'". The "fixes" branch adds one commit "Introduce "reset type" flag to "git reset"". The "mhf" branch adds many other commits. The current branch is "master".
If you keep your primary branches immediately under refs/heads, and topic branches in subdirectories of it, having the following in the configuration file may help:
[showbranch] default = --topo-order default = heads/*
With this, git show-branch without extra parameters would show only the primary branches. In addition, if you happen to be on your topic branch, it is shown as well.
$ git show-branch --reflog="10,1 hour ago" --list master
shows 10 reflog entries going back from the tip as of 1 hour ago. Without --list, the output also shows how these tips are topologically related with each other.
CARGO-TEST(1)                General Commands Manual               CARGO-TEST(1)
cargo-test - Execute unit and integration tests of a package
cargo test [options] [testname] [-- test-options]
Compile and execute unit and integration tests.
The test filtering argument TESTNAME and all the arguments following the two dashes (--) are passed to the test binaries and thus to libtest (rustc's built in unit-test and micro-benchmarking framework). If you're passing arguments to both Cargo and the binary, the ones after -- go to the binary, the ones before go to Cargo. For details about libtest's arguments see the output of cargo test -- --help and check out the rustc book's chapter on how tests work at <https://doc.rust-lang.org/rustc/tests/index.html>.
As an example, this will filter for tests with foo in their name and run them on 3 threads in parallel:
cargo test foo -- --test-threads 3
Tests are built with the --test option to rustc which creates an executable with a main function that automatically runs all functions annotated with the #[test] attribute in multiple threads. #[bench] annotated functions will also be run with one iteration to verify that they are functional.
The libtest harness may be disabled by setting harness = false in the target manifest settings, in which case your code will need to provide its own main function to handle running tests.
Documentation tests are also run by default, which is handled by rustdoc. It extracts code samples from documentation comments and executes them. See the rustdoc book <https://doc.rust-lang.org/rustdoc/> for more information on writing doc tests.
Test Options --no-run Compile, but don't run tests.
--no-fail-fast Run all tests regardless of failure. Without this flag, Cargo will exit after the first executable fails. The Rust test harness will run all tests within the executable to completion, this flag only applies to the executable as a whole.
Package Selection By default, when no package selection options are given, the packages selected depend on the selected manifest file (based on the current working directory if --manifest-path is not given). If the manifest is the root of a workspace then the workspaces default members are selected, otherwise only the package defined by the manifest will be selected.
The default members of a workspace can be set explicitly with the workspace.default-members key in the root manifest. If this is not set, a virtual workspace will include all workspace members (equivalent to passing --workspace), and a non-virtual workspace will include only the root crate itself.
-p spec..., --package spec... Test only the specified packages. See cargo-pkgid(1) for the SPEC format. This flag may be specified multiple times and supports common Unix glob patterns like *, ? and []. However, to avoid your shell accidentally expanding glob patterns before Cargo handles them, you must use single quotes or double quotes around each pattern.
--workspace Test all members in the workspace.
--all Deprecated alias for --workspace.
--exclude SPEC... Exclude the specified packages. Must be used in conjunction with the --workspace flag. This flag may be specified multiple times and supports common Unix glob patterns like *, ? and []. However, to avoid your shell accidentally expanding glob patterns before Cargo handles them, you must use single quotes or double quotes around each pattern.
Target Selection When no target selection options are given, cargo test will build the following targets of the selected packages:
•  lib — used to link with binaries, examples, integration tests, and doc tests
•  bins (only if integration tests are built and required features are available)
•  examples — to ensure they compile
•  lib as a unit test
•  bins as unit tests
•  integration tests
•  doc tests for the lib target
The default behavior can be changed by setting the test flag for the target in the manifest settings. Setting examples to test = true will build and run the example as a test. Setting targets to test = false will stop them from being tested by default. Target selection options that take a target by name ignore the test flag and will always test the given target.
Doc tests for libraries may be disabled by setting doctest = false for the library in the manifest.
Binary targets are automatically built if there is an integration test or benchmark. This allows an integration test to execute the binary to exercise and test its behavior. The CARGO_BIN_EXE_<name> environment variable <https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates> is set when the integration test is built so that it can use the env macro <https://doc.rust-lang.org/std/macro.env.html> to locate the executable.
Passing target selection flags will test only the specified targets.
Note that --bin, --example, --test and --bench flags also support common Unix glob patterns like *, ? and []. However, to avoid your shell accidentally expanding glob patterns before Cargo handles them, you must use single quotes or double quotes around each glob pattern.
--lib Test the package's library.
--bin name... Test the specified binary. This flag may be specified multiple times and supports common Unix glob patterns.
--bins Test all binary targets.
--example name... Test the specified example. This flag may be specified multiple times and supports common Unix glob patterns.
--examples Test all example targets.
--test name... Test the specified integration test. This flag may be specified multiple times and supports common Unix glob patterns.
--tests Test all targets in test mode that have the test = true manifest flag set. By default this includes the library and binaries built as unittests, and integration tests. Be aware that this will also build any required dependencies, so the lib target may be built twice (once as a unittest, and once as a dependency for binaries, integration tests, etc.). Targets may be enabled or disabled by setting the test flag in the manifest settings for the target.
--bench name... Test the specified benchmark. This flag may be specified multiple times and supports common Unix glob patterns.
--benches Test all targets in benchmark mode that have the bench = true manifest flag set. By default this includes the library and binaries built as benchmarks, and bench targets. Be aware that this will also build any required dependencies, so the lib target may be built twice (once as a benchmark, and once as a dependency for binaries, benchmarks, etc.). Targets may be enabled or disabled by setting the bench flag in the manifest settings for the target.
--all-targets Test all targets. This is equivalent to specifying --lib --bins --tests --benches --examples.
--doc Test only the library's documentation. This cannot be mixed with other target options.
Feature Selection The feature flags allow you to control which features are enabled. When no feature options are given, the default feature is activated for every selected package.
See the features documentation <https://doc.rust-lang.org/cargo/reference/features.html#command-line-feature-options> for more details.
--features features Space or comma separated list of features to activate. Features of workspace members may be enabled with package-name/feature-name syntax. This flag may be specified multiple times, which enables all specified features.
--all-features Activate all available features of all selected packages.
--no-default-features Do not activate the default feature of the selected packages.
Compilation Options --target triple Test for the given architecture. The default is the host architecture. The general format of the triple is <arch><sub>-<vendor>-<sys>-<abi>. Run rustc --print target-list for a list of supported targets.
This may also be specified with the build.target config value <https://doc.rust-lang.org/cargo/reference/config.html>.
Note that specifying this flag makes Cargo run in a different mode where the target artifacts are placed in a separate directory. See the build cache <https://doc.rust-lang.org/cargo/guide/build-cache.html> documentation for more details.
--release Test optimized artifacts with the release profile. See also the --profile option for choosing a specific profile by name.
--profile name Test with the given profile. See the the reference <https://doc.rust-lang.org/cargo/reference/profiles.html> for more details on profiles.
--ignore-rust-version Test the target even if the selected Rust compiler is older than the required Rust version as configured in the project's rust-version field.
Output Options --target-dir directory Directory for all generated artifacts and intermediate files. May also be specified with the CARGO_TARGET_DIR environment variable, or the build.target-dir config value <https://doc.rust-lang.org/cargo/reference/config.html>. Defaults to target in the root of the workspace.
Display Options By default the Rust test harness hides output from test execution to keep results readable. Test output can be recovered (e.g., for debugging) by passing --nocapture to the test binaries:
cargo test -- --nocapture
-v, --verbose Use verbose output. May be specified twice for "very verbose" output which includes extra output such as dependency warnings and build script output. May also be specified with the term.verbose config value <https://doc.rust-lang.org/cargo/reference/config.html>.
-q, --quiet No output printed to stdout.
--color when Control when colored output is used. Valid values:
•  auto (default): Automatically detect if color support is available on the terminal.
•  always: Always display colors.
•  never: Never display colors.
May also be specified with the term.color config value <https://doc.rust-lang.org/cargo/reference/config.html>.
--message-format fmt The output format for diagnostic messages. Can be specified multiple times and consists of comma-separated values. Valid values:
•  human (default): Display in a human-readable text format. Conflicts with short and json.
•  short: Emit shorter, human-readable text messages. Conflicts with human and json.
•  json: Emit JSON messages to stdout. See the reference <https://doc.rust-lang.org/cargo/reference/external-tools.html#json-messages> for more details. Conflicts with human and short.
•  json-diagnostic-short: Ensure the rendered field of JSON messages contains the "short" rendering from rustc. Cannot be used with human or short.
•  json-diagnostic-rendered-ansi: Ensure the rendered field of JSON messages contains embedded ANSI color codes for respecting rustc's default color scheme. Cannot be used with human or short.
•  json-render-diagnostics: Instruct Cargo to not include rustc diagnostics in in JSON messages printed, but instead Cargo itself should render the JSON diagnostics coming from rustc. Cargo's own JSON diagnostics and others coming from rustc are still emitted. Cannot be used with human or short.
Manifest Options --manifest-path path Path to the Cargo.toml file. By default, Cargo searches for the Cargo.toml file in the current directory or any parent directory.
--frozen, --locked Either of these flags requires that the Cargo.lock file is up-to-date. If the lock file is missing, or it needs to be updated, Cargo will exit with an error. The --frozen flag also prevents Cargo from attempting to access the network to determine if it is out-of-date.
These may be used in environments where you want to assert that the Cargo.lock file is up-to-date (such as a CI build) or want to avoid network access.
--offline Prevents Cargo from accessing the network for any reason. Without this flag, Cargo will stop with an error if it needs to access the network and the network is not available. With this flag, Cargo will attempt to proceed without the network if possible.
Beware that this may result in different dependency resolution than online mode. Cargo will restrict itself to crates that are downloaded locally, even if there might be a newer version as indicated in the local copy of the index. See the cargo-fetch(1) command to download dependencies before going offline.
May also be specified with the net.offline config value <https://doc.rust-lang.org/cargo/reference/config.html>.
Common Options +toolchain If Cargo has been installed with rustup, and the first argument to cargo begins with +, it will be interpreted as a rustup toolchain name (such as +stable or +nightly). See the rustup documentation <https://rust-lang.github.io/rustup/overrides.html> for more information about how toolchain overrides work.
-h, --help Prints help information.
-Z flag Unstable (nightly-only) flags to Cargo. Run cargo -Z help for details.
Miscellaneous Options The --jobs argument affects the building of the test executable but does not affect how many threads are used when running the tests. The Rust test harness includes an option to control the number of threads used:
cargo test -j 2 -- --test-threads=2
-j N, --jobs N Number of parallel jobs to run. May also be specified with the build.jobs config value <https://doc.rust-lang.org/cargo/reference/config.html>. Defaults to the number of CPUs.
See the reference <https://doc.rust-lang.org/cargo/reference/environment-variables.html> for details on environment variables that Cargo reads.
•  0: Cargo succeeded.
•  101: Cargo failed to complete.
1. Execute all the unit and integration tests of the current package:
2. Run only tests whose names match against a filter string:
cargo test name_filter
3. Run only a specific test within a specific integration test:
cargo test --test int_test_name -- modname::test_name
cargo(1), cargo-bench(1)
STACK(3)                    Library Functions Manual                    STACK(3)
stack_init, stack_push, stack_pop, stack_top, stack_size, stack_empty, stack_free -- generic list-based stack routines
cc [ flags ] files -llist [ libraries ]
STACK *stack_init()
char *stack_push(stack, data, bytes) STACK *stack; char *data; int bytes;
char *stack_pop(stack) STACK *stack;
char *stack_top(stack) STACK *stack;
int stack_size(stack) STACK *stack;
int stack_empty(stack) STACK *stack;
void stack_free(stack, dealloc) STACK *stack; void (*dealloc)();
These routines provide generic stack manipulation of (potentially) multiple stacks.  Each stack can hold arbitrarily sized elements, with individual elements within a stack varying in size.  It is the programmer's responsibility to account for such differences.
Stacks are referred to by variables declared as STACK *; the type STACK is defined in <stack.h> to be a C structure.
These routines are based upon the list(3) library.  Although this list- based implementation requires minimal additional space overhead versus a dedicated stack library, greater flexibility and likely overall improved space performance is offerred, since the list(3) library implements this and other data structuring models with a common set of primitives.
stack_init initializes and returns a stack descriptor.
stack_push pushes an element, pointed to by data and of size bytes, onto stack, and returns a pointer to the pushed data.  If bytes is greater than 0, then data is copied onto the stack, otherwise only the reference data is copied onto the stack.  This allows the suer to determine the memory allocation policy.
stack_pop pops (removes) the element at the top of stack and returns a pointer to the removed data.
stack_top returns a pointer to the element at the top of stack, but does not remove the element.  This routine is implemented as a macro.
stack_size returns the number of elements on stack as an integer.  This routine is implemented as a macro.
stack_empty returns 1 (TRUE) if stack is empty, 0 (FALSE) otherwise. This routine is implemented as a macro.
stack_free deallocates stack, applying the user-supplied function dealloc to the data portion of each element remaining in the stack.  If dealloc is STACK_DEALLOC, then the package will apply its own deallocation routine.  This, however, should only be done if the package has been responsible for data element allocation, i.e., the push routine has been invoked with bytes greater than 0.  If dealloc is STACK_NODEALLOC, no per-element deallocation will be performed.
Both stack_init and stack_push allocate memory during their execution. As such, stack_push pushes a copy of the data onto the stack when bytes is greater than 0.  If bytes is 0, then only the reference is copied onto the stack.  This allows the user to control the memory allocation policy. Both functions may fail during memory allocation; see DIAGNOSTICS below for more information.
Note that stack_pop does not allocate memory for the popping data.  It simply disassociates the data fron the stack, and thus returns a pointer to data that was previously allocated by the package.  It is the programmer's responsibility to deallocate such popped data.
If the user has been responsile for data element storage allocation, i.e. the push routine has been called with bytes equal to 0, then the user must be responsible for storage deallocation as well.  A user-supplied deallocation function should be passed to stack_free for this purpose. The deallocation function should be declared as:
void dealloc(data) char *data;
and will be sent the data element reference of each element in the stack when stack_free is invoked.  If the package has been responsible for data element allocation, stack_free can be invoked with STACK_DEALLOC for dealloc,; the stack package will apply its own deallocation routine, or STACK_NODEALLOC if no per-element deallocation is required.  It is the programmer's responsibility to insure that the memory allocation policy is applied properly.
A NULL returned by stack_init or stack_push indicates a failure in allocating memory for the new stack or element.  See malloc(3) for more information.
stack_pop, and stack_top return a NULL for an empty stack.
A core dump indicates a bug ;-)
Both stack_pop and stack_free do not physically reclaim storage space, although they do make it available for reuse.  While this is a function of free(3), its application here could be considered a bug.
list(3), queue(3), cache(3)
Bradley C. Spatz (bcs@ufl.edu), University of Florida.
GIT-CLEAR-SOFT(1)                  Git Extras                  GIT-CLEAR-SOFT(1)
git-clear-soft - Soft clean up a repository
git-clear-soft
Clears the repository to a state that it looks as if it was freshly cloned with the current HEAD, however, preserving all changes that are located in files and directories listed in .gitignore. It is a git-reset --hard together with deletion of all untracked files that reside inside the working directory, excluding those in .gitignore.
$ git clear-soft
Modified version of script written by Daniel ´grindhold´ Brendle <grindhold@gmx.net> by Matiss Treinis <mrtreinis@gmail.com>
NASM(1)                   The Netwide Assembler Project                  NASM(1)
nasm - the Netwide Assembler, a portable 80x86 assembler
nasm [-@ response file] [-f format] [-o outfile] [-l listfile] [options...] filename
The nasm command assembles the file filename and directs output to the file outfile if specified. If outfile is not specified, nasm will derive a default output file name from the name of its input file, usually by appending ‘.o’ or ‘.obj’, or by removing all extensions for a raw binary file. Failing that, the output file name will be ‘nasm.out’.
-@ filename Causes nasm to process options from filename as if they were included on the command line.
-a Causes nasm to assemble the given input file without first applying the macro preprocessor.
-D|-d macro[=value] Pre-defines a single-line macro.
-E|-e Causes nasm to preprocess the given input file, and write the output to stdout (or the specified output file name), and not actually assemble anything.
-f format Specifies the output file format. To see a list of valid output formats, use the -hf option.
-F format Specifies the debug information format. To see a list of valid output formats, use the -y option (for example -felf -y).
-g Causes nasm to generate debug information.
-gformat Equivalent to -g -F format.
-h Causes nasm to exit immediately, after giving a summary of its invocation options.
-hf Same as -h , but also lists all valid output formats.
-I|-i directory Adds a directory to the search path for include files. The directory specification must include the trailing slash, as it will be directly prepended to the name of the include file.
-l listfile Causes an assembly listing to be directed to the given file, in which the original source is displayed on the right hand side (plus the source for included files and the expansions of multi-line macros) and the generated code is shown in hex on the left.
-M Causes nasm to output Makefile-style dependencies to stdout; normal output is suppressed.
-MG file Same as -M but assumes that missing Makefile dependecies are generated and added to dependency list without a prefix.
-MF file Output Makefile-style dependencies to the specified file.
-MD file Same as a combination of -M and -MF options.
-MT file Override the default name of the dependency target dependency target name. This is normally the same as the output filename, specified by the -o option.
-MQ file The same as -MT except it tries to quote characters that have special meaning in Makefile syntax. This is not foolproof, as not all characters with special meaning are quotable in Make.
-MP Emit phony target.
-O number Optimize branch offsets.
•   -O0: No optimization
•   -O1: Minimal optimization
•   -Ox: Multipass optimization (default)
-o outfile Specifies a precise name for the output file, overriding nasm's default means of determining it.
-P|-p file Specifies a file to be pre-included, before the main source file starts to be processed.
-s Causes nasm to send its error messages and/or help text to stdout instead of stderr.
-t Causes nasm to assemble in SciTech TASM compatible mode.
-U|-u macro Undefines a single-line macro.
-v Causes nasm to exit immediately, after displaying its version number.
*-W[no-]foo' Causes nasm to enable or disable certain classes of warning messages, in gcc-like style, for example -Wlabel-orphan or -Wno-orphan-labels.
-w[+-]foo Causes nasm to enable or disable certain classes of warning messages, for example -w+label-orphan or -w-macro-params.
-X format Specifies error reporting format (gnu or vc).
-y Causes nasm to list supported debug formats.
-Z filename Causes nasm to redirect error messages to filename. This option exists to support operating systems on which stderr is not easily redirected.
--prefix, --postfix Prepend or append (respectively) the given argument to all global or extern variables.
This man page does not fully describe the syntax of nasm's assembly language, but does give a summary of the differences from other assemblers.
Registers have no leading ‘%’ sign, unlike gas, and floating-point stack registers are referred to as st0, st1, and so on.
Floating-point instructions may use either the single-operand form or the double. A TO keyword is provided; thus, one could either write
fadd st0,st1 fadd st1,st0
or one could use the alternative single-operand forms
fadd st1 fadd to st1
Uninitialised storage is reserved using the RESB, RESW, RESD, RESQ, REST and RESO pseudo-opcodes, each taking one parameter which gives the number of bytes, words, doublewords, quadwords or ten-byte words to reserve.
Repetition of data items is not done by the DUP keyword as seen in DOS assemblers, but by the use of the TIMES prefix, like this:
message: times 3 db 'abc' times 64-$+message db 0
which defines the string abcabcabc, followed by the right number of zero bytes to make the total length up to 64 bytes.
Symbol references are always understood to be immediate (i.e. the address of the symbol), unless square brackets are used, in which case the contents of the memory location are used. Thus:
mov ax,wordvar
loads AX with the address of the variable wordvar, whereas
mov ax,[wordvar] mov ax,[wordvar+1] mov ax,[es:wordvar+bx]
all refer to the contents of memory locations. The syntaxes
mov ax,es:wordvar[bx] es mov ax,wordvar[1]
are not legal at all, although the use of a segment register name as an instruction prefix is valid, and can be used with instructions such as LODSB which can’t be overridden any other way.
Constants may be expressed numerically in most formats: a trailing H, Q or B denotes hex, octal or binary respectively, and a leading ‘0x’ or ‘$’ denotes hex as well. Leading zeros are not treated specially at all. Character constants may be enclosed in single or double quotes; there is no escape character. The ordering is little-endian (reversed), so that the character constant 'abcd' denotes 0x64636261 and not 0x61626364.
Local labels begin with a period, and their ‘locality’ is granted by the assembler prepending the name of the previous non-local symbol. Thus declaring a label ‘.loop’ after a label ‘label’ has actually defined a symbol called ‘label.loop’.
SECTION name or SEGMENT name causes nasm to direct all following code to the named section. Section names vary with output file format, although most formats support the names .text, .data and .bss. (The exception is the obj format, in which all segments are user-definable.)
ABSOLUTE address causes nasm to position its notional assembly point at an absolute address: so no code or data may be generated, but you can use RESB, RESW and RESD to move the assembly point further on, and you can define labels. So this directive may be used to define data structures. When you have finished doing absolute assembly, you must issue another SECTION directive to return to normal assembly.
BITS 16, BITS 32 or BITS 64 switches the default processor mode for which nasm is generating code: it is equivalent to USE16 or USE32 in DOS assemblers.
EXTERN symbol and GLOBAL symbol import and export symbol definitions, respectively, from and to other modules. Note that the GLOBAL directive must appear before the definition of the symbol it refers to.
STRUC strucname and ENDSTRUC, when used to bracket a number of RESB, RESW or similar instructions, define a data structure. In addition to defining the offsets of the structure members, the construct also defines a symbol for the size of the structure, which is simply the structure name with size tacked on to the end.
FORMAT-SPECIFIC DIRECTIVES ORG address is used by the bin flat-form binary output format, and specifies the address at which the output code will eventually be loaded.
GROUP grpname seg1 seg2... is used by the obj (Microsoft 16-bit) output format, and defines segment groups. This format also uses UPPERCASE, which directs that all segment, group and symbol names output to the object file should be in uppercase. Note that the actual assembly is still case sensitive.
LIBRARY libname is used by the rdf output format, and causes a dependency record to be written to the output file which indicates that the program requires a certain library in order to run.
Single-line macros are defined using the %define or %idefine commands, in a similar fashion to the C preprocessor. They can be overloaded with respect to number of parameters, although defining a macro with no parameters prevents the definition of any macro with the same name taking parameters, and vice versa. %define defines macros whose names match case-sensitively, whereas %idefine defines case-insensitive macros.
Multi-line macros are defined using %macro and %imacro (the distinction is the same as that between %define and %idefine), whose syntax is as follows
%macro name minprm[-maxprm][+][.nolist] [defaults] <some lines of macro expansion text> %endmacro
Again, these macros may be overloaded. The trailing plus sign indicates that any parameters after the last one get subsumed, with their separating commas, into the last parameter. The defaults part can be used to specify defaults for unspecified macro parameters after minparam. %endm is a valid synonym for %endmacro.
To refer to the macro parameters within a macro expansion, you use %1, %2 and so on. You can also enforce that a macro parameter should contain a condition code by using %+1, and you can invert the condition code by using %-1. You can also define a label specific to a macro invocation by prefixing it with a double ‘%’ sign.
Files can be included using the %include directive, which works like C.
The preprocessor has a ‘context stack’, which may be used by one macro to store information that a later one will retrieve. You can push a context on the stack using %push, remove one using %pop, and change the name of the top context (without disturbing any associated definitions) using %repl. Labels and %define macros specific to the top context may be defined by prefixing their names with %$, and things specific to the next context down with %$$, and so on.
Conditional assembly is done by means of %ifdef, %ifndef, %else and %endif as in C. (Except that %ifdef can accept several putative macro names, and will evaluate TRUE if any of them is defined.) In addition, the directives %ifctx and %ifnctx can be used to condition on the name of the top context on the context stack. The obvious set of ‘else-if’ directives, %elifdef, %elifndef, %elifctx and %elifnctx are also supported.
Please report bugs through the bug tracker function at http://nasm.us.
as(1), ld(1).
RC(7)                             User Commands                            RC(7)
rc - manual page for rc 2.33.128
rc [OPTION]...
rc is the RTags client application.
--verbose|-v Be more verbose.
--verify-version|-t [arg] Verify that the correct protocol version is used.
--silent|-Q Be silent.
--help|-h Display this help.
--config [arg] Use this file (instead of ~/.rcrc).
--no-rc Don't load any rc files.
Rdm: --quit-rdm|-q Tell server to shut down with optional exit code as argument.
--connect-timeout [arg] Timeout for connecting to rdm in ms (default 1000).
Project management: --clear|-C Clear projects.
--project|-w [optional] With arg, select project matching that if unique, otherwise list all projects.
--delete-project|-W [arg] Delete all projects matching regex.
--job-count|-j [optional] Set or query current job count. (Prefix with l to set low-priority-job-count).
Indexing commands: --compile|-c [optional] Pass compilation arguments to rdm.
--guess-flags Guess compile flags (used with -c).
--load-compile-commands|-J [optional] Load compile_commands.json from directory
--suspend|-X [optional] Dump suspended files (don't track changes in these files) with no arg. Otherwise toggle suspension for arg.
Query commands: --follow-location|-f [arg] Follow this location.
--references-name|-R [arg] Find references matching arg.
--references|-r [arg] Find references matching this location.
--list-symbols|-S [optional] List symbol names matching arg.
--find-symbols|-F [optional] Find symbols matching arg.
--symbol-info|-U [arg] Get cursor info for this location.
--status|-s [optional] Dump status of rdm. Arg can be symbols or symbolNames.
--diagnose [arg] Resend diagnostics for file.
--diagnose-all Resend diagnostics for all files.
--last-indexed Get timestamp of the last time indexing completed for the current project.
--is-indexed|-T [arg] Check if rtags knows about, and is ready to return information about, this source file.
--is-indexing [optional] Check if rtags is currently indexing files in any project or in project matching pattern.
--has-filemanager [optional] Check if rtags has info about files in this directory.
--preprocess|-E [arg] Preprocess file.
--asm [arg] Assemble file.
--reindex|-V [optional] Reindex all files or all files matching pattern.
--check-reindex|-x [optional] Check if reindexing is necessary for all files matching pattern.
--path|-P [optional] Print files matching pattern.
--current-project Print path for current project.
--dump-file|-d [arg] Dump source file.
--check-includes [arg] Check includes for source file.
--dump-file-maps [arg] Dump file maps for file.
--generate-test [arg] Generate a test for a given source file.
--rdm-log|-g Receive logs from rdm.
--fixits [arg] Get fixits for file.
--remove|-D [arg] Remove file from project.
--find-project-root [arg] Use to check behavior of find-project-root.
--find-project-build-root [arg] Use to check behavior of find-project-root for builds.
--include-file [arg] Use to generate include statement for symbol.
--sources [optional] Dump sources for source file.
--dependencies [arg] Dump dependencies for source file [(includes, included-by, depends-on, depended-on, tree-depends-on, raw)].
--all-dependencies Dump dependencies for all source files [(includes, included-by, depends-on, depended-on, tree-depends-on, raw)].
--reload-file-manager|-B Reload file manager.
--man  Output XML for xmltoman to generate man page for rc :-)
--code-complete-at|-l [arg] Code complete at location: arg is file:line:col.
--send-diagnostics [arg] Only for debugging. Send data to all -G connections.
--dump-completions Dump cached completions.
--dump-compile-commands Dump compilation database for project.
--set-buffers [optional] Set active buffers (list of filenames for active buffers in editor).
--list-buffers List active buffers.
--add-buffers [arg] Add additional buffers.
--remove-buffers [arg] Remove buffers.
--list-cursor-kinds List spelling for known cursor kinds.
--class-hierarchy [arg] Dump class hierarcy for struct/class at location.
--debug-locations [optional] Manipulate debug locations.
--validate Validate database files for current project.
--tokens [arg] Dump tokens for file. --tokens file.cpp:123-321 for range.
--find-dead-functions [optional] Find functions declared/defined in the current file that are never in the project.
Command flags: --strip-paren|-p Strip parens in various contexts.
--max|-M [arg] Max lines of output for queries.
--reverse-sort|-O Sort output reversed.
--rename Used for --references to indicate that we're using the results to rename symbols.
--unsaved-file [arg] Pass unsaved file on command line. E.g. --unsaved-file=main.cpp:1200 then write 1200 bytes on stdin.
--log-file|-L [arg] Log to this file.
--no-context|-N Don't print context for locations.
--path-filter|-i [arg] Filter out results not matching with arg.
--dependency-filter [arg] Filter out results unless argument depends on them.
--range-filter [arg] Filter out results not in the specified range.
--filter-system-headers|-H Don't exempt system headers from path filters.
--all-references|-e Include definitions/declarations/constructors/destructors for references. Used for rename symbol.
--target-usrs Print all matching usr targets for -f. Used for debugging.
--all-targets Print multiple targets for -f. Sorted by best match.
--elisp|-Y Output elisp: (list "one" "two" ...).
--json Output json.
--json-diagnostics-include-skipped Output json diagnostics with skipped ranges.
--diagnostics|-m Receive async formatted diagnostics from rdm.
--match-regexp|-Z Treat various text patterns as regexps (-P, -i, -V, -F).
--match-icase|-I Match case insensitively
--absolute-path|-K Print files with absolute path.
--socket-file|-n [arg] Use this socket file (default ~/.rdm).
--socket-address [arg] Use this host:port combination (instead of --socket-file).
--timeout|-y [arg] Max time in ms to wait for job to finish (default no timeout).
--find-virtuals|-k Use in combinations with -R or -r to show other implementations of this function.
--find-file-prefer-exact|-A Use to make --find-file prefer exact matches over partial matches.
--symbol-info-include-parents Use to make --symbol-info include parent symbols.
--symbol-info-include-targets Use to make --symbol-info include target symbols.
--symbol-info-include-references Use to make --symbol-info include reference symbols.
--symbol-info-include-base-classes Use to make --symbol-info include baseclasses' symbols.
--cursor-kind Include cursor kind in --find-symbols output.
--display-name Include display name in --find-symbols output.
--current-file [arg] Pass along which file is being edited to give rdm a better chance at picking the right project.
--declaration-only|-G Filter out definitions (unless inline).
--definition-only Filter out declarations (unless inline).
--kind-filter [arg] Only return results matching this kind.
--containing-function|-o Include name of containing function in output.
--containing-function-location Include location of containing function in output.
--build-index [arg] For sources with multiple builds, use the arg'th.
--compilation-flags-only For --source, only print compilation flags.
--compilation-flags-split-line For --source, print one compilation flag per line.
--compilation-flags-pwd For --source, print pwd for compile command on the first line.
--dump-include-headers For --dump-file, also dump dependencies.
--silent-query Don't log this request in rdm.
--synchronous-completions Wait for completion results and print them to stdout.
--synchronous-diagnostics Wait for diagnostics and print them to stdout.
--xml  Output XML
--no-sort-references-by-input Don't sort references by input position.
--project-root [arg] Override project root for compile commands.
--rtags-config [arg] Print out .rtags-config for argument.
--wildcard-symbol-names|-a Expand * like wildcards in --list-symbols and --find-symbols.
--no-color|-z Don't colorize context.
--wait Wait for reindexing to finish.
--code-complete-include-macros Include macros in code completion results.
--code-complete-includes Give includes in completion results.
--code-complete-no-wait Don't wait for synchronous completion if the translation unit has to be created.
--code-complete-prefix [arg] Filter out code completion results that don't start with this prefix.
--code-completion-enabled|-b Inform rdm that we're code-completing. Use with --diagnose
--no-spell-checking Don't produce spell check info in diagnostics.
--tokens-include-symbols Include symbols for tokens.
--no-realpath Don't resolve paths using realpath(3).
--include-path [arg] Dump include path for symbol.
--max-depth [arg] Max search depth. Used for --include-path.
rdm(7)
CHAGE(1)                          User Commands                         CHAGE(1)
chage - change user password expiry information
chage [options] LOGIN
The chage command changes the number of days between password changes and the date of the last password change. This information is used by the system to determine when a user must change their password.
The options which apply to the chage command are:
-d, --lastday LAST_DAY Set the number of days since January 1st, 1970 when the password was last changed. The date may also be expressed in the format YYYY-MM-DD (or the format more commonly used in your area).
-E, --expiredate EXPIRE_DATE Set the date or number of days since January 1, 1970 on which the user's account will no longer be accessible. The date may also be expressed in the format YYYY-MM-DD (or the format more commonly used in your area). A user whose account is locked must contact the system administrator before being able to use the system again.
Passing the number -1 as the EXPIRE_DATE will remove an account expiration date.
-h, --help Display help message and exit.
-i, --iso8601 When printing dates, use YYYY-MM-DD format.
-I, --inactive INACTIVE Set the number of days of inactivity after a password has expired before the account is locked. The INACTIVE option is the number of days of inactivity. A user whose account is locked must contact the system administrator before being able to use the system again.
Passing the number -1 as the INACTIVE will remove an account's inactivity.
-l, --list Show account aging information.
-m, --mindays MIN_DAYS Set the minimum number of days between password changes to MIN_DAYS. A value of zero for this field indicates that the user may change their password at any time.
-M, --maxdays MAX_DAYS Set the maximum number of days during which a password is valid. When MAX_DAYS plus LAST_DAY is less than the current day, the user will be required to change their password before being able to use their account. This occurrence can be planned for in advance by use of the -W option, which provides the user with advance warning.
Passing the number -1 as MAX_DAYS will remove checking a password's validity.
-W, --warndays WARN_DAYS Set the number of days of warning before a password change is required. The WARN_DAYS option is the number of days prior to the password expiring that a user will be warned their password is about to expire.
If none of the options are selected, chage operates in an interactive fashion, prompting the user with the current values for all of the fields. Enter the new value to change the field, or leave the line blank to use the current value. The current value is displayed between a pair of [ ] marks.
The chage program requires a shadow password file to be available.
The chage command is restricted to the root user, except for the -l option, which may be used by an unprivileged user to determine when their password or account is due to expire.
The chage command exits with the following values:
1 permission denied
2 invalid command syntax
15 can't find the shadow password file
passwd(5), shadow(5).
REDIS-CLI(1)                 General Commands Manual                REDIS-CLI(1)
redis-cli - Command-line client to redis-server
redis-cli [options]
redis-cli provides a simple command-line interface to a Redis server.
See redis-doc for more information on the commands Redis accepts.
redis-cli was written by Salvatore Sanfilippo.
GIT(1)                             Git Manual                             GIT(1)
git - the stupid content tracker
git [--version] [--help] [-C <path>] [-c <name>=<value>] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare] [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] [--super-prefix=<path>] [--config-env=<name>=<envvar>] <command> [<args>]
Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.
See gittutorial(7) to get started, then see giteveryday(7) for a useful minimum set of commands. The Git User’s Manual[1] has a more in-depth introduction.
After you mastered the basic concepts, you can come back to this page to learn what commands Git offers. You can learn more about individual Git commands with "git help command". gitcli(7) manual page gives you an overview of the command-line command syntax.
A formatted and hyperlinked copy of the latest Git documentation can be viewed at https://git.github.io/htmldocs/git.html or https://git-scm.com/docs.
--version Prints the Git suite version that the git program came from.
This option is internaly converted to git version ...  and accepts the same options as the git-version(1) command. If --help is also given, it takes precedence over --version.
--help Prints the synopsis and a list of the most commonly used commands. If the option --all or -a is given then all available commands are printed. If a Git command is named this option will bring up the manual page for that command.
Other options are available to control how the manual page is displayed. See git-help(1) for more information, because git --help ...  is converted internally into git help ....