neulab/tldr huggingface dataset:
Note When the remote branch you want to fetch is known to be rewound and rebased regularly, it is expected that its new tip will not be descendant of its previous tip (as stored in your remote-tracking branch the last time you fetched). You would want to use the + sign to indicate non-fast-forward updates will be needed for such branches. There is no way to determine or declare that a branch will be made available in a repository with this behavior; the pulling user simply must know this is the expected usage pattern for a branch.
--stdin Read refspecs, one per line, from stdin in addition to those provided as arguments. The "tag <name>" format is not supported.
CONFIGURED REMOTE-TRACKING BRANCHES You often interact with the same remote repository by regularly and repeatedly fetching from it. In order to keep track of the progress of such a remote repository, git fetch allows you to configure remote.<repository>.fetch configuration variables.
Typically such a variable may look like this:
[remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/*
This configuration is used in two ways:
•   When git fetch is run without specifying what branches and/or tags to fetch on the command line, e.g.  git fetch origin or git fetch, remote.<repository>.fetch values are used as the refspecs—they specify which refs to fetch and which local refs to update. The example above will fetch all branches that exist in the origin (i.e. any ref that matches the left-hand side of the value, refs/heads/*) and update the corresponding remote-tracking branches in the refs/remotes/origin/* hierarchy.
•   When git fetch is run with explicit branches and/or tags to fetch on the command line, e.g.  git fetch origin master, the <refspec>s given on the command line determine what are to be fetched (e.g.  master in the example, which is a short-hand for master:, which in turn means "fetch the master branch but I do not explicitly say what remote-tracking branch to update with it from the command line"), and the example command will fetch only the master branch. The remote.<repository>.fetch values determine which remote-tracking branch, if any, is updated. When used in this way, the remote.<repository>.fetch values do not have any effect in deciding what gets fetched (i.e. the values are not used as refspecs when the command-line lists refspecs); they are only used to decide where the refs that are fetched are stored by acting as a mapping.
The latter use of the remote.<repository>.fetch values can be overridden by giving the --refmap=<refspec> parameter(s) on the command line.
Git has a default disposition of keeping data unless it’s explicitly thrown away; this extends to holding onto local references to branches on remotes that have themselves deleted those branches.
If left to accumulate, these stale references might make performance worse on big and busy repos that have a lot of branch churn, and e.g. make the output of commands like git branch -a --contains <commit> needlessly verbose, as well as impacting anything else that’ll work with the complete set of known references.
These remote-tracking references can be deleted as a one-off with either of:
# While fetching $ git fetch --prune <name>
# Only prune, don't fetch $ git remote prune <name>
To prune references as part of your normal workflow without needing to remember to run that, set fetch.prune globally, or remote.<name>.prune per-remote in the config. See git-config(1).
Here’s where things get tricky and more specific. The pruning feature doesn’t actually care about branches, instead it’ll prune local ←→ remote-references as a function of the refspec of the remote (see <refspec> and CONFIGURED REMOTE-TRACKING BRANCHES above).
Therefore if the refspec for the remote includes e.g. refs/tags/*:refs/tags/*, or you manually run e.g. git fetch --prune <name> "refs/tags/*:refs/tags/*" it won’t be stale remote tracking branches that are deleted, but any local tag that doesn’t exist on the remote.
This might not be what you expect, i.e. you want to prune remote <name>, but also explicitly fetch tags from it, so when you fetch from it you delete all your local tags, most of which may not have come from the <name> remote in the first place.
So be careful when using this with a refspec like refs/tags/*:refs/tags/*, or any other refspec which might map references from multiple remotes to the same local namespace.
Since keeping up-to-date with both branches and tags on the remote is a common use-case the --prune-tags option can be supplied along with --prune to prune local tags that don’t exist on the remote, and force-update those tags that differ. Tag pruning can also be enabled with fetch.pruneTags or remote.<name>.pruneTags in the config. See git- config(1).
The --prune-tags option is equivalent to having refs/tags/*:refs/tags/* declared in the refspecs of the remote. This can lead to some seemingly strange interactions:
# These both fetch tags $ git fetch --no-tags origin 'refs/tags/*:refs/tags/*' $ git fetch --no-tags --prune-tags origin
The reason it doesn’t error out when provided without --prune or its config versions is for flexibility of the configured versions, and to maintain a 1=1 mapping between what the command line flags do, and what the configuration versions do.
It’s reasonable to e.g. configure fetch.pruneTags=true in ~/.gitconfig to have tags pruned whenever git fetch --prune is run, without making every invocation of git fetch without --prune an error.
Pruning tags with --prune-tags also works when fetching a URL instead of a named remote. These will all prune tags not found on origin:
$ git fetch origin --prune --prune-tags $ git fetch origin --prune 'refs/tags/*:refs/tags/*' $ git fetch <url of origin> --prune --prune-tags $ git fetch <url of origin> --prune 'refs/tags/*:refs/tags/*'
The output of "git fetch" depends on the transport method used; this section describes the output when fetching over the Git protocol (either locally or via ssh) and Smart HTTP protocol.
The status of the fetch is output in tabular form, with each line representing the status of a single ref. Each line is of the form:
<flag> <summary> <from> -> <to> [<reason>]
The status of up-to-date refs is shown only if the --verbose option is used.
In compact output mode, specified with configuration variable fetch.output, if either entire <from> or <to> is found in the other string, it will be substituted with * in the other string. For example, master -> origin/master becomes master -> origin/*.
(space) for a successfully fetched fast-forward;
- for a successfully pruned ref;
t for a successful tag update;
* for a successfully fetched new ref;
! for a ref that was rejected or failed to update; and
= for a ref that was up to date and did not need fetching.
summary For a successfully fetched ref, the summary shows the old and new values of the ref in a form suitable for using as an argument to git log (this is <old>..<new> in most cases, and <old>...<new> for forced non-fast-forward updates).
from The name of the remote ref being fetched from, minus its refs/<type>/ prefix. In the case of deletion, the name of the remote ref is "(none)".
to The name of the local ref being updated, minus its refs/<type>/ prefix.
reason A human-readable explanation. In the case of successfully fetched refs, no explanation is needed. For a failed ref, the reason for failure is described.
•   Update the remote-tracking branches:
$ git fetch origin
The above command copies all branches from the remote refs/heads/ namespace and stores them to the local refs/remotes/origin/ namespace, unless the branch.<name>.fetch option is used to specify a non-default refspec.
•   Using refspecs explicitly:
$ git fetch origin +seen:seen maint:tmp
This updates (or creates, as necessary) branches seen and tmp in the local repository by fetching from the branches (respectively) seen and maint from the remote repository.
The seen branch will be updated even if it does not fast-forward, because it is prefixed with a plus sign; tmp will not be.
•   Peek at a remote’s branch, without configuring the remote in your local repository:
$ git fetch git://git.kernel.org/pub/scm/git/git.git maint $ git log FETCH_HEAD
The first command fetches the maint branch from the repository at git://git.kernel.org/pub/scm/git/git.git and the second command uses FETCH_HEAD to examine the branch with git-log(1). The fetched objects will eventually be removed by git’s built-in housekeeping (see git- gc(1)).
Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself cannot be fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future Git version.
git-pull(1)
tic(1)                       General Commands Manual                      tic(1)
tic - the terminfo entry-description compiler
tic [-01CDGIKLNTUVWacfgqrstx] [-e names] [-o dir] [-Q[n]] [-R subset] [-v[n]] [-w[n]] file
The tic command translates a terminfo file from source format into compiled format.  The compiled format is necessary for use with the library routines in ncurses(3NCURSES).
As described in term(5), the database may be either a directory tree (one file per terminal entry) or a hashed database (one record per entry). The tic command writes only one type of entry, depending on how it was built:
•   For directory trees, the top-level directory, e.g., /usr/share/terminfo, specifies the location of the database.
•   For hashed databases, a filename is needed.  If the given file is not found by that name, but can be found by adding the suffix ".db", then that is used.
The default name for the hashed database is the same as the default directory name (only adding a ".db" suffix).
In either case (directory or hashed database), tic will create the container if it does not exist.  For a directory, this would be the “terminfo” leaf, versus a "terminfo.db" file.
The results are normally placed in the system terminfo database /etc/terminfo.  The compiled terminal description can be placed in a different terminfo database.  There are two ways to achieve this:
•   First, you may override the system default either by using the -o option, or by setting the variable TERMINFO in your shell environment to a valid database location.
•   Secondly, if tic cannot write in /etc/terminfo or the location specified using your TERMINFO variable, it looks for the directory $HOME/.terminfo (or hashed database $HOME/.terminfo.db); if that location exists, the entry is placed there.
Libraries that read terminfo entries are expected to check in succession
•   a location specified with the TERMINFO environment variable,
•   $HOME/.terminfo,
•   directories listed in the TERMINFO_DIRS environment variable,
•   a compiled-in list of directories (no default value), and
•   the system terminfo database (/etc/terminfo).
ALIASES This is the same program as infotocap and captoinfo; usually those are linked to, or copied from this program:
•   When invoked as infotocap, tic sets the -I option.
•   When invoked as captoinfo, tic sets the -C option.
OPTIONS -0     restricts the output to a single line
-1     restricts the output to a single column
-a     tells tic to retain commented-out capabilities rather than discarding them.  Capabilities are commented by prefixing them with a period.  This sets the -x option, because it treats the commented-out entries as user-defined names.  If the source is termcap, accept the 2-character names required by version 6. Otherwise these are ignored.
-C     Force source translation to termcap format.  Note: this differs from the -C option of infocmp(1) in that it does not merely translate capability names, but also translates terminfo strings to termcap format.  Capabilities that are not translatable are left in the entry under their terminfo names but commented out with two preceding dots.  The actual format used incorporates some improvements for escaped characters from terminfo format.  For a stricter BSD-compatible translation, add the -K option.
If this is combined with -c, tic makes additional checks to report cases where the terminfo values do not have an exact equivalent in termcap form.  For example:
•   sgr usually will not convert, because termcap lacks the ability to work with more than two parameters, and because termcap lacks many of the arithmetic/logical operators used in terminfo.
•   capabilities with more than one delay or with delays before the end of the string will not convert completely.
-c     tells tic to only check file for errors, including syntax problems and bad use-links.  If you specify -C (-I) with this option, the code will print warnings about entries which, after use resolution, are more than 1023 (4096) bytes long.  Due to a fixed buffer length in older termcap libraries, as well as buggy checking for the buffer length (and a documented limit in terminfo), these entries may cause core dumps with other implementations.
tic checks string capabilities to ensure that those with parameters will be valid expressions.  It does this check only for the predefined string capabilities; those which are defined with the -x option are ignored.
-D     tells tic to print the database locations that it knows about, and exit.  The first location shown is the one to which it would write compiled terminal descriptions.  If tic is not able to find a writable database location according to the rules summarized above, it will print a diagnostic and exit with an error rather than printing a list of database locations.
-e names Limit writes and translations to the following comma-separated list of terminals.  If any name or alias of a terminal matches one of the names in the list, the entry will be written or translated as normal.  Otherwise no output will be generated for it.  The option value is interpreted as a file containing the list if it contains a '/'.  (Note: depending on how tic was compiled, this option may require -I or -C.)
-f     Display complex terminfo strings which contain if/then/else/endif expressions indented for readability.
-G     Display constant literals in decimal form rather than their character equivalents.
-g     Display constant character literals in quoted form rather than their decimal equivalents.
-I     Force source translation to terminfo format.
-K     Suppress some longstanding ncurses extensions to termcap format, e.g., "\s" for space.
-L     Force source translation to terminfo format using the long C variable names listed in <term.h>
-N     Disable smart defaults.  Normally, when translating from termcap to terminfo, the compiler makes a number of assumptions about the defaults of string capabilities reset1_string, carriage_return, cursor_left, cursor_down, scroll_forward, tab, newline, key_backspace, key_left, and key_down, then attempts to use obsolete termcap capabilities to deduce correct values.  It also normally suppresses output of obsolete termcap capabilities such as bs.  This option forces a more literal translation that also preserves the obsolete capabilities.
-odir  Write compiled entries to given database location.  Overrides the TERMINFO environment variable.
-Qn    Rather than show source in terminfo (text) format, print the compiled (binary) format in hexadecimal or base64 form, depending on the option's value:
1  hexadecimal
2  base64
3  hexadecimal and base64
-q     Suppress comments and blank lines when showing translated source.
-Rsubset Restrict output to a given subset.  This option is for use with archaic versions of terminfo like those on SVr1, Ultrix, or HP-UX that do not support the full set of SVR4/XSI Curses terminfo; and outright broken ports like AIX 3.x that have their own extensions incompatible with SVr4/XSI.  Available subsets are “SVr1”, “Ultrix”, “HP”, “BSD” and “AIX”; see terminfo(5) for details.
-r     Force entry resolution (so there are no remaining tc capabilities) even when doing translation to termcap format.  This may be needed if you are preparing a termcap file for a termcap library (such as GNU termcap through version 1.3 or BSD termcap through 4.3BSD) that does not handle multiple tc capabilities per entry.
-s     Summarize the compile by showing the database location into which entries are written, and the number of entries which are compiled.
-T     eliminates size-restrictions on the generated text.  This is mainly useful for testing and analysis, since the compiled descriptions are limited (e.g., 1023 for termcap, 4096 for terminfo).
-t     tells tic to discard commented-out capabilities.  Normally when translating from terminfo to termcap, untranslatable capabilities are commented-out.
-U   tells tic to not post-process the data after parsing the source file.  Normally, it infers data which is commonly missing in older terminfo data, or in termcaps.
-vn  specifies that (verbose) output be written to standard error trace information showing tic's progress.
The optional parameter n is a number from 1 to 10, inclusive, indicating the desired level of detail of information.  If ncurses is built without tracing support, the optional parameter is ignored. If n is omitted, the default level is 1.  If n is specified and greater than 1, the level of detail is increased.
The debug flag levels are as follows:
1      Names of files created and linked
2      Information related to the “use” facility
3      Statistics from the hashing algorithm
5      String-table memory allocations
7      Entries into the string-table
8      List of tokens encountered by scanner
9      All values computed in construction of the hash table
If the debug level n is not given, it is taken to be one.
-W   By itself, the -w option will not force long strings to be wrapped. Use the -W option to do this.
If you specify both -f and -W options, the latter is ignored when -f has already split the line.
-wn  specifies the width of the output.  The parameter is optional.  If it is omitted, it defaults to 60.
-x   Treat unknown capabilities as user-defined (see user_caps(5)).  That is, if you supply a capability name which tic does not recognize, it will infer its type (boolean, number or string) from the syntax and make an extended table entry for that.  User-defined capability strings whose name begins with “k” are treated as function keys.
PARAMETERS file   contains one or more terminfo terminal descriptions in source format [see terminfo(5)].  Each description in the file describes the capabilities of a particular terminal.
If file is “-”, then the data is read from the standard input. The file parameter may also be the path of a character-device.
PROCESSING All but one of the capabilities recognized by tic are documented in terminfo(5).  The exception is the use capability.
When a use=entry-name field is discovered in a terminal entry currently being compiled, tic reads in the binary from /etc/terminfo to complete the entry.  (Entries created from file will be used first.  tic duplicates the capabilities in entry-name for the current entry, with the exception of those capabilities that explicitly are defined in the current entry.
When an entry, e.g., entry_name_1, contains a use=entry_name_2 field, any canceled capabilities in entry_name_2 must also appear in entry_name_1 before use= for these capabilities to be canceled in entry_name_1.
Total compiled entries cannot exceed 4096 bytes.  The name field cannot exceed 512 bytes.  Terminal names exceeding the maximum alias length (32 characters on systems with long filenames, 14 characters otherwise) will be truncated to the maximum alias length and a warning message will be printed.
System V Release 2 provided a tic utility.  It accepted a single option: -v (optionally followed by a number).  According to Ross Ridge's comment in mytinfo, this version of tic was unable to represent cancelled capabilities.
System V Release 3 provided a different tic utility, written by Pavel Curtis, (originally named “compile” in pcurses).  This added an option -c to check the file for errors, with the caveat that errors in “use=” links would not be reported.  System V Release 3 documented a few warning messages which did not appear in pcurses.  While the program itself was changed little as development continued with System V Release 4, the table of capabilities grew from 180 (pcurses) to 464 (Solaris).
In early development of ncurses (1993), Zeyd Ben-Halim used the table from mytinfo to extend the pcurses table to 469 capabilities (456 matched SVr4, 8 were only in SVr4, 13 were not in SVr4).  Of those 13, 11 were ultimately discarded (perhaps to match the draft of X/Open Curses).  The exceptions were memory_lock_above and memory_unlock (see user_caps(5)).
Eric Raymond incorporated parts of mytinfo into ncurses to implement the termcap-to-terminfo source conversion, and extended that to begin development of the corresponding terminfo-to-termcap source conversion, Thomas Dickey completed that development over the course of several years.
In 1999, Thomas Dickey added the -x option to support user-defined capabilities.
In 2010, Roy Marples provided a tic program and terminfo library for NetBSD.  That implementation adapts several features from ncurses, including tic's -x option.
The -c option tells tic to check for problems in the terminfo source file.  Continued development provides additional checks:
•   pcurses had 8 warnings
•   ncurses in 1996 had 16 warnings
•   Solaris (SVr4) curses has 28 warnings
•   NetBSD tic in 2019 has 19 warnings.
•   ncurses in 2019 has 96 warnings
The checking done in ncurses' tic helps with the conversion to termcap, as well as pointing out errors and inconsistencies.  It is also used to ensure consistency with the user-defined capabilities.  There are 527 distinct capabilities in ncurses' terminal database; 128 of those are user-defined.
X/Open Curses, Issue 7 (2009) provides a brief description of tic.  It lists one option: -c.  The omission of -v is unexpected.  The change history states that the description is derived from True64 UNIX. According to its manual pages, that system also supported the -v option.
Shortly after Issue 7 was released, Tru64 was discontinued.  As of 2019, the surviving implementations of tic are SVr4 (AIX, HP-UX and Solaris), ncurses and NetBSD curses.  The SVr4 tic programs all support the -v option.  The NetBSD tic program follows X/Open's documentation, omitting the -v option.
The X/Open rationale states that some implementations of tic read terminal descriptions from the standard input if the file parameter is omitted.  None of these implementations do that.  Further, it comments that some may choose to read from ”./terminfo.src” but that is obsolescent behavior from SVr2, and is not (for example) a documented feature of SVr3.
COMPATIBILITY There is some evidence that historic tic implementations treated description fields with no whitespace in them as additional aliases or short names.  This tic does not do that, but it does warn when description fields may be treated that way and check them for dangerous characters.
EXTENSIONS Unlike the SVr4 tic command, this implementation can actually compile termcap sources.  In fact, entries in terminfo and termcap syntax can be mixed in a single source file.  See terminfo(5) for the list of termcap names taken to be equivalent to terminfo names.
The SVr4 manual pages are not clear on the resolution rules for use capabilities.  This implementation of tic will find use targets anywhere in the source file, or anywhere in the file tree rooted at TERMINFO (if TERMINFO is defined), or in the user's $HOME/.terminfo database (if it exists), or (finally) anywhere in the system's file tree of compiled entries.
The error messages from this tic have the same format as GNU C error messages, and can be parsed by GNU Emacs's compile facility.
Aside from -c and -v, options are not portable:
•   Most of tic's options are not supported by SVr4 tic:
-0 -1 -C -G -I -N -R -T -V -a -e -f -g -o -r -s -t -x
•   The NetBSD tic  supports a few of the ncurses options
-a -o -x
and adds -S (a feature which does the same thing as infocmp's -e and -E options).
The SVr4 -c mode does not report bad “use=” links.
System V does not compile entries to or read entries from your $HOME/.terminfo database unless TERMINFO is explicitly set to it.
/etc/terminfo/?/* Compiled terminal description database.
captoinfo(1), infocmp(1), infotocap(1), toe(1), ncurses(3NCURSES), term(5).  terminfo(5).  user_caps(5).
Eric S. Raymond <esr@snark.thyrsus.com> and Thomas E. Dickey <dickey@invisible-island.net>
xinput(1)                    General Commands Manual                   xinput(1)
xinput - utility to configure and test X input devices
xinput [OPTIONS] [DEVICE]
xinput is a utility to list available input devices, query information about a device and change input device settings.
--version Test if the X Input extension is available and return the version number of the program and the version supported by the server. This option does not require a device name.
--list [--short || --long || --name-only || --id-only] [device] If no argument is given list all the input devices. If an argument is given, show all the features of device.  If --long is provided, the output includes detailed information about the capabilities of each devices. Otherwise, or if --short is provided, only the device names and some minimal information is listed.  If --name-only is provided, the output is limited to the device names. One device name is listed per line. Note that the order the devices are listed is undefined.  If --id-only is provided, the output is limited to the device IDs. One device ID is listed per line. Note that the order the devices are listed is undefined.
--get-feedbacks device Display the feedbacks of device.
--set-pointer device Switch device in core pointer.  This option does nothing on X servers 1.5 and later.
--set-mode device ABSOLUTE|RELATIVE Change the mode of device.
--set-ptr-feedback device threshold num denom Change the pointer acceleration (or feedback) parameters of device.  The xset(1) man page has more details. For X.Org Server 1.7 and above, there are additional device properties pertaining to pointer acceleration. These do not replace, but complement the pointer feedback setting.
--set-integer-feedback device index value Change the value of an integer feedback of device.
--set-button-map device map_button_1 [map_button_2 [...]] Change the button mapping of device. The buttons are specified in physical order (starting with button 1) and are mapped to the logical button provided. 0 disables a button. The default button mapping for a device is 1 2 3 4 5 6 etc.
--query-state device Query the device state.
--list-props device [device [...]] Lists properties that can be set for the given device(s).
--set-int-prop device property format value Sets an integer property for the device.  Appropriate values for format are 8, 16, or 32, depending on the property. Deprecated, use --set-prop instead.
--set-float-prop device property value Sets a float property for the device. Deprecated, use --set-prop instead.
--set-prop [--type=atom|float|int] [--format=8|16|32] device property value [...] Set the property to the given value(s).  If not specified, the format and type of the property are left as-is.  The arguments are interpreted according to the property type. See Section CHANGING PROPERTIES.
--watch-props device Prints to standard out when property changes occur.
--delete-prop device property Delete the property from the device.
--test [-proximity] device Register all extended events from device and enter an endless loop displaying events received. If the -proximity is given, ProximityIn and ProximityOut are registered.
--test-xi2 [--root] [device] Register for a number of XI2 events and display them. If a device is given, only events on this device are displayed. If --root is given, events are selected on the root window only. Otherwise, a new client window is created (similar to xev).
--create-master prefix [sendCore] [enable] Create a new pair of master devices on an XI2-enabled server with the given prefix. The server will create one master pointer named "prefix pointer" and one master keyboard named "prefix keyboard". If sendCore is 1, this pair of master devices is set to send core events (default).  If enable is 1, this master device pair will be enabled immediately (default).
--remove-master master [Floating|AttachToMaster] [returnPointer] [returnKeyboard] Remove master  and its paired master device. Attached slave devices are set floating if Floating is specified or the argument is omitted.  If the second argument is AttachToMaster, returnPointer specifies the master pointer to attach all slave pointers to and returnKeyboard specifies the master keyboard to attach all slave keyboards to.
--reattach slave master Reattach slave to master.
--float slave Remove slave from its current master device.
--set-cp window master Set the ClientPointer for the client owning window to master. master must specify a master pointer.
--map-to-output device crtc Restricts the movements of the absolute device to the RandR crtc. The output name must match a currently connected output (see xrandr(1)). If the NVIDIA binary driver is detected or RandR 1.2 or later is not available, a Xinerama output may be specified as "HEAD-N", with N being the Xinerama screen number. This option has no effect on relative devices.
--enable device Enable the device. This call is equivalent to xinput --set-prop device "Device Enabled" 1
--disable device Disable the device. This call is equivalent to xinput --set-prop device "Device Enabled" 0
device can be the device name as a string or the XID of the device.
slave can be the device name as a string or the XID of a slave device.
master can be the device name as a string or the XID of a master device.
property can be the property as a string or the Atom value.
When xinput should modify an existing driver property value, it is sufficient to provide the device name and property name as string, followed by the new value(s) of the property. For example:
xinput set-prop "my device" "my prop" 1 2 3
Xwayland is an X server that uses a Wayland Compositor as backend. Xwayland acts as translation layer between the X protocol and the Wayland protocol but does not have direct access to the hardware. The X Input Extension devices created by Xwayland ("xwayland-pointer", "xwayland- keyboard", etc.) map to the Wayland protocol devices, not to physical devices.
These X Input Extension devices are only visible to other X clients connected to the same Xwayland process. Changing properties on Xwayland devices only affects the behavior of those clients. For example, disabling an Xwayland device with xinput does not disable the device in Wayland-native applications. Other changes may not have any effect at all.
In most instances, using xinput with an Xwayland device is indicative of a bug in a shell script and xinput will print a warning. Use the Wayland Compositor's native device configuration methods instead.
X(7), xset(1), xrandr(1)
Copyright 1996,1997, Frederic Lepied.
Copyright 2007, Peter Hutterer.
Copyright 2008, Philip Langdale.
Copyright 2009-2011, Red Hat, Inc.
Peter Hutterer <peter.hutterer@who-t.net> Philip Langdale, <philipl@alumni.utexas.net> Frederic Lepied, France <Frederic.Lepied@sugix.frmug.org> Julien Cristau <jcristau@debian.org> Thomas Jaeger <ThJaeger@gmail.com> and more.
SAM(1)                       General Commands Manual                      SAM(1)
sam - screen editor with structural regular expressions
sam [ option ...  ] [ files ]
sam -r machine
sam.save
B [ -nnnn ] file ...
Sam is a multi-file editor.  It modifies a local copy of an external file.  The copy is here called a file.  The files are listed in a menu available through mouse button 3 or the n command.  Each file has an associated name, usually the name of the external file from which it was read, and a `modified' bit that indicates whether the editor's file agrees with the external file.  The external file is not read into the editor's file until it first becomes the current file—that to which editing commands apply—whereupon its menu entry is printed.  The options are
-d     Do not download the terminal part of sam.  Editing will be done with the command language only, as in ed(1).
-r machine Run the host part remotely on the specified machine, the terminal part locally.
-s file Start the host part from the indicated file on the remote host. Only meaningful with the -r option.
-t path Start the terminal part from the indicated file.  Useful for debugging.
The standard X11 -geom toolkit option can be used to select the desired window geometry.
Regular expressions Regular expressions are as in regexp(7g) with the addition of \n to represent newlines.  A regular expression may never contain a literal newline character.  The elements of regular expressions are:
.      Match any character except newline.
\n     Match newline.
\x     For any character except n match the character (here x).
[abc]  Match any character in the square brackets.  \n may be mentioned.
[^abc] Match any character not in the square brackets, but never a newline.  Both these forms accept a range of ASCII characters indicated by a dash, as in a-z.
^      Match the null string immediately after a newline.
$      Match the null string immediately before a newline.
Any other character except newline matches itself.
In the following, r1 and r2 are regular expressions.
(r1)   Match what r1 matches.
r1|r2  Match what r1 or what r2 matches.
r1*    Match zero or more adjacent matches of r1.
r1+    Match one or more adjacent matches of r1.
r1?    Match zero or one matches of r1.
The operators *, + and ?  are highest precedence, then catenation, then | is lowest.  The empty regular expression stands for the last complete expression encountered.  A regular expression in sam matches the longest leftmost substring formally matched by the expression.  Searching in the reverse direction is equivalent to searching backwards with the catenation operations reversed in the expression.
Addresses An address identifies a substring in a file.  In the following, `character n' means the null string after the n-th character in the file, with 1 the first character in the file.  `Line n' means the n-th match, starting at the beginning of the file, of the regular expression (The peculiar properties of a last line without a newline are temporarily undefined.)  All files always have a current substring, called dot, that is the default address.
Simple Addresses #n     The empty string after character n; #0 is the beginning of the file.
n      Line n.
/regexp/ ?regexp? The substring that matches the regular expression, found by looking toward the end (/) or beginning (?)  of the file, and if necessary continuing the search from the other end to the starting point of the search.  The matched substring may straddle the starting point.  When entering a pattern containing a literal question mark for a backward search, the question mark should be specified as a member of a class.
0      The string before the first full line.  This is not necessarily the null string; see + and - below.
$      The null string at the end of the file.
.      Dot.
'      The mark in the file (see the k command below).
"regexp" Preceding a simple address (default .), refers to the address evaluated in the unique file whose menu line matches the regular expression.
Compound Addresses In the following, a1 and a2 are addresses.
a1+a2  The address a2 evaluated starting at the end of a1.
a1-a2  The address a2 evaluated looking in the reverse direction starting at the beginning of a1.
a1,a2  The substring from the beginning of a1 to the end of a2.  If a1 is missing, 0 is substituted.  If a2 is missing, $ is substituted.
a1;a2  Like a1,a2, but with a2 evaluated at the end of, and dot set to, a1.
The operators + and - are high precedence, while , and ; are low precedence.
In both + and - forms, if a2 is a line or character address with a missing number, the number defaults to 1.  If a1 is missing, is substituted.  If both a1 and a2 are present and distinguishable, + may be elided.  a2 may be a regular expression; if it is delimited by the effect of the + or - is reversed.
It is an error for a compound address to represent a malformed substring. Some useful idioms: a1+- (a1-+) selects the line containing the end (beginning) of a1.  0/regexp/ locates the first match of the expression in the file.  (The form 0;// sets dot unnecessarily.)  ./regexp/// finds the second following occurrence of the expression, and .,/regexp/ extends dot.
Commands In the following, text demarcated by slashes represents text delimited by any printable ASCII character except alphanumerics.  Any number of trailing delimiters may be elided, with multiple elisions then representing null strings, but the first delimiter must always be present.  In any delimited text, newline may not appear literally; \n may be typed for newline; and \/ quotes the delimiter, here Backslash is otherwise interpreted literally, except in s commands.
Most commands may be prefixed by an address to indicate their range of operation.  Those that may not are marked with a below.  If a command takes an address and none is supplied, dot is used.  The sole exception is the w command, which defaults to 0,$.  In the description, `range' is used to represent whatever address is supplied.  Many commands set the value of dot as a side effect.  If so, it is always set to the `result' of the change: the empty string for a deletion, the new text for an insertion, etc. (but see the s and e commands).
Grouping and multiple changes Commands may be grouped by enclosing them in braces {}.  Commands within the braces must appear on separate lines (no backslashes are required between commands).  Semantically, an opening brace is like a command: it takes an (optional) address and sets dot for each sub-command.  Commands within the braces are executed sequentially, but changes made by one command are not visible to other commands (see the next paragraph). Braces may be nested arbitrarily.
When a command makes a number of changes to a file, as in x/re/c/text/, the addresses of all changes to the file are computed in the original file.  If the changes are in sequence, they are applied to the file. Successive insertions at the same address are catenated into a single insertion composed of the several insertions in the order applied.
The terminal What follows refers to behavior of sam when downloaded, that is, when operating as a display editor on a bitmap display.  This is the default behavior; invoking sam with the -d (no download) option provides access to the command language only.
Each file may have zero or more windows open.  Each window is equivalent and is updated simultaneously with changes in other windows on the same file.  Each window has an independent value of dot, indicated by a highlighted substring on the display.  Dot may be in a region not within the window.  There is usually a `current window', marked with a dark border, to which typed text and editing commands apply.  The escape key (ESC) selects (sets dot to) text typed since the last mouse button hit.
The button 3 menu controls window operations.  The top of the menu provides the following operators, each of which uses one or more cursors to prompt for selection of a window or sweeping of a rectangle.
new    Create a new, empty file: Depress button 3 where one corner of the new rectangle should appear (box cursor), and move the mouse while holding down button 3 to the diagonally opposite corner. `Sweeping' a null rectangle gets a large window, disjoint from the command window or the whole sam window, depending on where the null rectangle is.
xerox  Create a copy of an existing window.  After selecting the window to copy with button 1, sweep out the window for the copy.
reshape Change the size and location of a window.  First click button 3 in the window to be changed (gunsight cursor).  Then sweep out a window as for the new menu selection.
close  Delete the window.  In the last window of a file, close is equivalent to a D for the file.
write  Equivalent to a w for the file.
Below these operators is a list of available files, starting with ~~sam~~, the command window.  Selecting a file from the list makes the most recently used window on that file current, unless it is already current, in which case selections cycle through the open windows.  If no windows are open on the file, the user is prompted to open one.  Files other than ~~sam~~ are marked with one of the characters -+* according as zero, one, or more windows are open on the file.  A further mark appears on the file in the current window and a single quote, ', on a file modified since last write.
The command window, created automatically when sam starts, is an ordinary window except that text typed to it is interpreted as commands for the editor rather than passive text, and text printed by editor commands appears in it.  There is an `output point' that separates commands being typed from previous output.  Commands typed in the command window apply to the current open file—the file in the most recently current window.
Manipulating text Typed characters replace the current selection (dot) in the current window.  Backspace deletes the previous character.  Escape selects (sets dot to) everything typed since the last mouse hit.
Button 1 changes selection.  Pointing to a non-current window with button 1 makes it current; within the current window, button 1 selects text, thus setting dot.  Double-clicking selects text to the boundaries of words, lines, quoted strings or bracketed strings, depending on the text at the click.
Button 2 provides a menu of editing commands:
cut    Delete dot and save the deleted text in the snarf buffer.
paste  Replace the text in dot by the contents of the snarf buffer.
snarf  Save the text in dot in the snarf buffer.
look   Search forward for the next occurrence of the literal text in dot. If dot is the null string, the text in the snarf buffer is used. The snarf buffer is unaffected.
<exch> Exchange the snarf buffer with the current selection in another X11 window.  The exchange of a large amount of selected text is truncated to the size of Sam's internal snarf buffer (currently 4K) without warning.
/regexp Search forward for the next match of the last regular expression typed in a command.  (Not in command window.)
send   Send the text in dot, or the snarf buffer if dot is the null string, as if it were typed to the command window.  Saves the sent text in the snarf buffer.  (Command window only.)
X11 resources Various attributes of sam can be set by giving values to X11 resources for the class Sam.  There are various ways to do this; one is to have a file called Sam in your home directory, with entries in it like:
Sam*width: 500 Sam*height: 600 Sam*font: fixed Sam*scrollForwardR: true
In addition to the usual X11 toolkit resources, the scrollForwardR resource says where the right button (button 3) scrolls forward or backward in the file.
Abnormal termination If sam terminates other than by a q command (by hangup, deleting its window, etc.), modified files are saved in an executable file, This program, when executed, asks whether to write each file back to a external file.  The answer causes writing; anything else skips the file. If a machine crash prevents the creation of a file, all changes are lost. If an editing session is difficult to replicate, you should write your changed files often.
B is a shell-level command that causes an instance of sam running on the same terminal to load the named files.  The option allows a line number to be specified for the initial position to display in the last named file.
<system-dependent dirctory>/samsave the program called to unpack $home/sam.save.
ed(1), regexp(7g)
When a sam window is resized, the command window may have the wrong size.
UPOWER(1)                            upower                            UPOWER(1)
upower - UPower command line tool
upower [--dump] [--enumerate] [--monitor-detail] [--monitor] [--show-info] [--version] [--wakeups] [--help]
upower is a simple command line client for the UPower(7) daemon. TODO: not fully documented.
--monitor Connect to the UPower daemon and print a line every time a power source is added, removed or changed.
--monitor-detail Like --monitor but prints the full details of the power source whenever an event happens.
--help Show help options.
Written by David Zeuthen <davidz@redhat.com> with a lot of help from many others.
Please send bug reports to either the distribution or the DeviceKit mailing list, see http://lists.freedesktop.org/mailman/listinfo/devkit-devel on how to subscribe.
upowerd(8), UPower(7),
GIT-REPLACE(1)                     Git Manual                     GIT-REPLACE(1)
git-replace - Create, list, delete refs to replace objects
git replace [-f] <object> <replacement> git replace [-f] --edit <object> git replace [-f] --graft <commit> [<parent>...] git replace [-f] --convert-graft-file git replace -d <object>... git replace [--format=<format>] [-l [<pattern>]]
Adds a replace reference in refs/replace/ namespace.
The name of the replace reference is the SHA-1 of the object that is replaced. The content of the replace reference is the SHA-1 of the replacement object.
The replaced object and the replacement object must be of the same type. This restriction can be bypassed using -f.
Unless -f is given, the replace reference must not yet exist.
There is no other restriction on the replaced and replacement objects. Merge commits can be replaced by non-merge commits and vice versa.
Replacement references will be used by default by all Git commands except those doing reachability traversal (prune, pack transfer and fsck).
It is possible to disable use of replacement references for any command using the --no-replace-objects option just after git.
For example if commit foo has been replaced by commit bar:
$ git --no-replace-objects cat-file commit foo
shows information about commit foo, while:
$ git cat-file commit foo
shows information about commit bar.
The GIT_NO_REPLACE_OBJECTS environment variable can be set to achieve the same effect as the --no-replace-objects option.
-f, --force If an existing replace ref for the same object exists, it will be overwritten (instead of failing).
-d, --delete Delete existing replace refs for the given objects.
--edit <object> Edit an object’s content interactively. The existing content for <object> is pretty-printed into a temporary file, an editor is launched on the file, and the result is parsed to create a new object of the same type as <object>. A replacement ref is then created to replace <object> with the newly created object. See git-var(1) for details about how the editor will be chosen.
--raw When editing, provide the raw object contents rather than pretty-printed ones. Currently this only affects trees, which will be shown in their binary form. This is harder to work with, but can help when repairing a tree that is so corrupted it cannot be pretty-printed. Note that you may need to configure your editor to cleanly read and write binary data.
--graft <commit> [<parent>...] Create a graft commit. A new commit is created with the same content as <commit> except that its parents will be [<parent>...] instead of <commit>'s parents. A replacement ref is then created to replace <commit> with the newly created commit. Use --convert-graft-file to convert a $GIT_DIR/info/grafts file and use replace refs instead.
--convert-graft-file Creates graft commits for all entries in $GIT_DIR/info/grafts and deletes that file upon success. The purpose is to help users with transitioning off of the now-deprecated graft file.
-l <pattern>, --list <pattern> List replace refs for objects that match the given pattern (or all if no pattern is given). Typing "git replace" without arguments, also lists all replace refs.
--format=<format> When listing, use the specified <format>, which can be one of short, medium and long. When omitted, the format defaults to short.
The following format are available:
•   short: <replaced sha1>
•   medium: <replaced sha1> → <replacement sha1>
•   long: <replaced sha1> (<replaced type>) → <replacement sha1> (<replacement type>)
git-hash-object(1), git-rebase(1), and git-filter-repo[1], among other git commands, can be used to create replacement objects from existing objects. The --edit option can also be used with git replace to create a replacement object by editing an existing object.