neulab/tldr huggingface dataset:
The --diskspec option can be used to control how --disk-only and external full system snapshots create external files.  This option can occur multiple times, according to the number of <disk> elements in the domain xml.  Each <diskspec> is in the form disk[,snapshot=type][,driver=type][,stype=type][,file=name].  A diskspec must be provided for disks backed by block devices as libvirt doesn't auto-generate file names for those.  The optional stype parameter allows one to control the type of the source file. Supported values are 'file' (default) and 'block'. To exclude a disk from an external snapshot use --diskspec disk,snapshot=no.
To include a literal comma in disk or in file=name, escape it with a second comma.  A literal --diskspec must precede each diskspec unless all three of domain, name, and description are also present.  For example, a diskspec of "vda,snapshot=external,file=/path/to,,new" results in the following XML:
<disk name='vda' snapshot='external'> <source file='/path/to,new'/> </disk>
If --reuse-external is specified, and the domain XML or diskspec option requests an external snapshot with a destination of an existing file, then the destination must exist and be pre-created with correct format and metadata. The file is then reused; otherwise, a snapshot is refused to avoid losing contents of the existing files.
If --no-metadata is specified, then the snapshot data is created, but any metadata is immediately discarded (that is, libvirt does not treat the snapshot as current, and cannot revert to the snapshot unless snapshot-create is later used to teach libvirt about the metadata again).
If --live is specified, libvirt takes the snapshot while the guest is running. This increases the size of the memory image of the external snapshot. This is currently supported only for external full system snapshots.
Optionally, the --validate option can be passed to validate XML document which is internally generated by this command against the internal RNG schema.
snapshot-current Syntax:
snapshot-current domain {[--name] | [--security-info] | [snapshotname]}
Without snapshotname, this will output the snapshot XML for the domain's current snapshot (if any).  If --name is specified, just the current snapshot name instead of the full xml.  Otherwise, using --security-info will also include security sensitive information in the XML.
With snapshotname, this is a request to make the existing named snapshot become the current snapshot, without reverting the domain.
snapshot-edit Syntax:
snapshot-edit domain [snapshotname] [--current] {[--rename] | [--clone]}
Edit the XML configuration file for snapshotname of a domain.  If both snapshotname and --current are specified, also force the edited snapshot to become the current snapshot.  If snapshotname is omitted, then --current must be supplied, to edit the current snapshot.
virsh snapshot-dumpxml dom name > snapshot.xml vi snapshot.xml (or make changes with your other text editor) virsh snapshot-create dom snapshot.xml --redefine [--current]
If --rename is specified, then the edits can change the snapshot name. If --clone is specified, then changing the snapshot name will create a clone of the snapshot metadata.  If neither is specified, then the edits must not change the snapshot name.  Note that changing a snapshot name must be done with care, since the contents of some snapshots, such as internal snapshots within a single qcow2 file, are accessible only from the original name.
snapshot-info Syntax:
snapshot-info domain {snapshot | --current}
Output basic information about a named <snapshot>, or the current snapshot with --current.
snapshot-list Syntax:
snapshot-list domain [--metadata] [--no-metadata] [{--parent | --roots | [{--tree | --name}]}] [--topological] [{[--from] snapshot | --current} [--descendants]] [--leaves] [--no-leaves] [--inactive] [--active] [--disk-only] [--internal] [--external]
List all of the available snapshots for the given domain, defaulting to show columns for the snapshot name, creation time, and domain state.
Normally, table form output is sorted by snapshot name; using --topological instead sorts so that no child is listed before its ancestors (although there may be more than one possible ordering with this property).
If --parent is specified, add a column to the output table giving the name of the parent of each snapshot.  If --roots is specified, the list will be filtered to just snapshots that have no parents.  If --tree is specified, the output will be in a tree format, listing just snapshot names.  These three options are mutually exclusive. If --name is specified only the snapshot name is printed. This option is mutually exclusive with --tree.
If --from is provided, filter the list to snapshots which are children of the given snapshot; or if --current is provided, start at the current snapshot.  When used in isolation or with --parent, the list is limited to direct children unless --descendants is also present.  When used with --tree, the use of --descendants is implied.  This option is not compatible with --roots.  Note that the starting point of --from or --current is not included in the list unless the --tree option is also present.
If --leaves is specified, the list will be filtered to just snapshots that have no children.  Likewise, if --no-leaves is specified, the list will be filtered to just snapshots with children.  (Note that omitting both options does no filtering, while providing both options will either produce the same list or error out depending on whether the server recognizes the flags).  Filtering options are not compatible with --tree.
If --metadata is specified, the list will be filtered to just snapshots that involve libvirt metadata, and thus would prevent undefine of a persistent guest, or be lost on destroy of a transient domain.  Likewise, if --no-metadata is specified, the list will be filtered to just snapshots that exist without the need for libvirt metadata.
If --inactive is specified, the list will be filtered to snapshots that were taken when the domain was shut off.  If --active is specified, the list will be filtered to snapshots that were taken when the domain was running, and where the snapshot includes the memory state to revert to that running state.  If --disk-only is specified, the list will be filtered to snapshots that were taken when the domain was running, but where the snapshot includes only disk state.
If --internal is specified, the list will be filtered to snapshots that use internal storage of existing disk images.  If --external is specified, the list will be filtered to snapshots that use external files for disk images or memory state.
snapshot-dumpxml Syntax:
snapshot-dumpxml domain snapshot [--security-info]
Output the snapshot XML for the domain's snapshot named snapshot.  Using --security-info will also include security sensitive information.  Use snapshot-current to easily access the XML of the current snapshot.
snapshot-parent Syntax:
snapshot-parent domain {snapshot | --current}
Output the name of the parent snapshot, if any, for the given snapshot, or for the current snapshot with --current.
snapshot-revert Syntax:
snapshot-revert domain {snapshot | --current} [{--running | --paused}] [--force]
Revert the given domain to the snapshot specified by snapshot, or to the current snapshot with --current.  Be aware that this is a destructive action; any changes in the domain since the last snapshot was taken will be lost.  Also note that the state of the domain after snapshot-revert is complete will be the state of the domain at the time the original snapshot was taken.
Normally, reverting to a snapshot leaves the domain in the state it was at the time the snapshot was created, except that a disk snapshot with no vm state leaves the domain in an inactive state.  Passing either the --running or --paused flag will perform additional state changes (such as booting an inactive domain, or pausing a running domain).  Since transient domains cannot be inactive, it is required to use one of these flags when reverting to a disk snapshot of a transient domain.
There are a number of cases where a snapshot revert involves extra risk, which requires the use of --force to proceed:
• One is the case of a snapshot that lacks full domain information for reverting configuration (such as snapshots created prior to libvirt 0.9.5); since libvirt cannot prove that the current configuration matches what was in use at the time of the snapshot, supplying --force assures libvirt that the snapshot is compatible with the current configuration (and if it is not, the domain will likely fail to run).
• Another is the case of reverting from a running domain to an active state where a new hypervisor has to be created rather than reusing the existing hypervisor, because it implies drawbacks such as breaking any existing VNC or Spice connections; this condition happens with an active snapshot that uses a provably incompatible configuration, as well as with an inactive snapshot that is combined with the --start or --pause flag.
• Also, libvirt will refuse to restore snapshots of inactive QEMU domains while there is managed saved state. This is because those snapshots do not contain memory state and will therefore not replace the existing memory state. This ends up switching a disk underneath a running system and will likely cause extensive filesystem corruption or crashes due to swap content mismatches when run.
snapshot-delete Syntax:
snapshot-delete domain {snapshot | --current} [--metadata] [{--children | --children-only}]
Delete the snapshot for the domain named snapshot, or the current snapshot with --current.  If this snapshot has child snapshots, changes from this snapshot will be merged into the children.  If --children is passed, then delete this snapshot and any children of this snapshot.  If --children-only is passed, then delete any children of this snapshot, but leave this snapshot intact.  These two flags are mutually exclusive.
If --metadata is specified, then only delete the snapshot metadata maintained by libvirt, while leaving the snapshot contents intact for access by external tools; otherwise deleting a snapshot also removes the data contents from that point in time.
The following commands manipulate domain checkpoints.  Checkpoints serve as a point in time to identify which portions of a guest's disks have changed after that time, making it possible to perform incremental and differential backups.  Checkpoints are identified with a unique name. See https://libvirt.org/formatcheckpoint.html for documentation of the XML format used to represent properties of checkpoints.
checkpoint-create Syntax:
checkpoint-create domain [xmlfile] { --redefine [--redefine-validate] | [--quiesce]}
Create a checkpoint for domain domain with the properties specified in xmlfile describing a <domaincheckpoint> top-level element. The format of the input XML file will be validated against an internal RNG schema (identical to using the virt-xml-validate(1) tool). If xmlfile is completely omitted, then libvirt will create a checkpoint with a name based on the current time.
If --redefine is specified, then all XML elements produced by checkpoint-dumpxml are valid; this can be used to migrate checkpoint hierarchy from one machine to another, to recreate hierarchy for the case of a transient domain that goes away and is later recreated with the same name and UUID, or to make slight alterations in the checkpoint metadata (such as host-specific aspects of the domain XML embedded in the checkpoint).  When this flag is supplied, the xmlfile argument is mandatory.
If --redefine-validate is specified along with --redefine the hypervisor performs validation of metadata associated with the checkpoint stored in places besides the checkpoint XML. Note that some hypervisors may require that the domain is running to perform validation.
If --quiesce is specified, libvirt will try to use guest agent to freeze and unfreeze domain's mounted file systems. However, if domain has no guest agent, checkpoint creation will fail.
Existence of checkpoint metadata will prevent attempts to undefine a persistent guest.  However, for transient domains, checkpoint metadata is silently lost when the domain quits running (whether by command such as destroy or by internal guest action).
For now, it is not possible to create checkpoints in a domain that has snapshots, although this restriction will be lifted in a future release.
checkpoint-create-as Syntax:
checkpoint-create-as domain [--print-xml] [name] [description] [--quiesce] [--diskspec] diskspec]...
Create a checkpoint for domain domain with the given <name> and <description>; if either value is omitted, libvirt will choose a value. If --print-xml is specified, then XML appropriate for checkpoint-create is output, rather than actually creating a checkpoint.
The --diskspec option can be used to control which guest disks participate in the checkpoint. This option can occur multiple times, according to the number of <disk> elements in the domain xml.  Each <diskspec> is in the form disk[,checkpoint=type][,bitmap=name]. A literal --diskspec must precede each diskspec unless all three of domain, name, and description are also present.  For example, a diskspec of "vda,checkpoint=bitmap,bitmap=map1" results in the following XML:
<disk name='vda' checkpoint='bitmap' bitmap='map1'/>
checkpoint-edit Syntax:
checkpoint-edit domain checkpointname
Edit the XML configuration file for checkpointname of a domain.
virsh checkpoint-dumpxml dom name > checkpoint.xml vi checkpoint.xml (or make changes with your other text editor) virsh checkpoint-create dom checkpoint.xml --redefine
except that it does some error checking, including that the edits should not attempt to change the checkpoint name.
checkpoint-info Syntax:
checkpoint-info domain checkpoint
Output basic information about a named <checkpoint>.
checkpoint-list Syntax:
checkpoint-list domain [{--parent | --roots | [{--tree | --name}]}] [--topological] [[--from] checkpoint | [--descendants]] [--leaves] [--no-leaves]
List all of the available checkpoints for the given domain, defaulting to show columns for the checkpoint name and creation time.
Normally, table form output is sorted by checkpoint name; using --topological instead sorts so that no child is listed before its ancestors (although there may be more than one possible ordering with this property).
If --parent is specified, add a column to the output table giving the name of the parent of each checkpoint.  If --roots is specified, the list will be filtered to just checkpoints that have no parents.  If --tree is specified, the output will be in a tree format, listing just checkpoint names.  These three options are mutually exclusive. If --name is specified only the checkpoint name is printed. This option is mutually exclusive with --tree.
If --from is provided, filter the list to checkpoints which are children of the given checkpoint.  When used in isolation or with --parent, the list is limited to direct children unless --descendants is also present. When used with --tree, the use of --descendants is implied.  This option is not compatible with --roots.  Note that the starting point of --from is not included in the list unless the --tree option is also present.
If --leaves is specified, the list will be filtered to just checkpoints that have no children.  Likewise, if --no-leaves is specified, the list will be filtered to just checkpoints with children.  (Note that omitting both options does no filtering, while providing both options will either produce the same list or error out depending on whether the server recognizes the flags).  Filtering options are not compatible with --tree.
checkpoint-dumpxml Syntax:
checkpoint-dumpxml domain checkpoint [--security-info] [--no-domain] [--size]
Output the checkpoint XML for the domain's checkpoint named checkpoint. Using --security-info will also include security sensitive information.
Using --size will add XML indicating the current size in bytes of guest data that has changed since the checkpoint was created (although remember that guest activity between a size check and actually creating a backup can result in the backup needing slightly more space). Note that some hypervisors may require that domain is running when --size is used.
Using --no-domain will omit the <domain> element from the output for a more compact view.
checkpoint-parent Syntax:
checkpoint-parent domain checkpoint
Output the name of the parent checkpoint, if any, for the given checkpoint.
checkpoint-delete Syntax:
checkpoint-delete domain checkpoint [--metadata] [{--children | --children-only}]
Delete the checkpoint for the domain named checkpoint.  The record of which portions of the disk changed since the checkpoint are merged into the parent checkpoint (if any). If --children is passed, then delete this checkpoint and any children of this checkpoint.  If --children-only is passed, then delete any children of this checkpoint, but leave this checkpoint intact. These two flags are mutually exclusive.
If --metadata is specified, then only delete the checkpoint metadata maintained by libvirt, while leaving the checkpoint contents intact for access by external tools; otherwise deleting a checkpoint also removes the ability to perform an incremental backup from that point in time.
The following commands manipulate network filters. Network filters allow filtering of the network traffic coming from and going to virtual machines.  Individual network traffic filters are written in XML and may contain references to other network filters, describe traffic filtering rules, or contain both. Network filters are referenced by virtual machines from within their interface description. A network filter may be referenced by multiple virtual machines' interfaces.
nwfilter-define Syntax:
nwfilter-define xmlfile [--validate]
Make a new network filter known to libvirt. If a network filter with the same name already exists, it will be replaced with the new XML.  Any running virtual machine referencing this network filter will have its network traffic rules adapted. If for any reason the network traffic filtering rules cannot be instantiated by any of the running virtual machines, then the new XML will be rejected.
nwfilter-undefine Syntax:
nwfilter-undefine nwfilter-name
Delete a network filter. The deletion will fail if any running virtual machine is currently using this network filter.
nwfilter-list Syntax:
nwfilter-list
List all of the available network filters.
nwfilter-dumpxml Syntax:
nwfilter-dumpxml nwfilter-name
Output the network filter XML.
nwfilter-edit Syntax:
nwfilter-edit nwfilter-name
Edit the XML of a network filter.
virsh nwfilter-dumpxml myfilter > myfilter.xml vi myfilter.xml (or make changes with your other text editor) virsh nwfilter-define myfilter.xml
except that it does some error checking.  The new network filter may be rejected due to the same reason as mentioned in nwfilter-define.
The following commands manipulate network filter bindings. Network filter bindings track the association between a network port and a network filter. Generally the bindings are managed automatically by the hypervisor drivers when adding/removing NICs on a guest.
If an admin is creating/deleting TAP devices for non-guest usage, however, the network filter binding commands provide a way to make use of the network filters directly.
nwfilter-binding-create Syntax:
nwfilter-binding-create xmlfile [--validate]
Associate a network port with a network filter. The network filter backend will immediately attempt to instantiate the filter rules on the port. This command may be used to associate a filter with a currently running guest that does not have a filter defined for a specific network port. Since the bindings are generally automatically managed by the hypervisor, using this command to define a filter for a network port and then starting the guest afterwards may prevent the guest from starting if it attempts to use the network port and finds a filter already defined.
nwfilter-binding-delete Syntax:
nwfilter-binding-delete port-name
Disassociate a network port from a network filter. The network filter backend will immediately tear down the filter rules that exist on the port. This command may be used to remove the network port binding for a filter currently in use for the guest while the guest is running without needing to restart the guest. Restoring the network port binding filter for the running guest would be accomplished by using nwfilter-binding-create.
nwfilter-binding-list Syntax:
nwfilter-binding-list
List all of the network ports which have filters associated with them.
nwfilter-binding-dumpxml Syntax:
nwfilter-binding-dumpxml port-name
Output the network filter binding XML for the network device called port-name.
HYPERVISOR-SPECIFIC COMMANDS NOTE: Use of the following commands is strongly discouraged.  They can cause libvirt to become confused and do the wrong thing on subsequent operations.  Once you have used these commands, please do not report problems to the libvirt developers; the reports will be ignored.  If you find that these commands are the only way to accomplish something, then it is better to request that the feature be added as a first-class citizen in the regular libvirt library.
qemu-attach Syntax:
qemu-attach pid
Attach an externally launched QEMU process to the libvirt QEMU driver. The QEMU process must have been created with a monitor connection using the UNIX driver. Ideally the process will also have had the '-name' argument specified.
$ qemu-kvm -cdrom ~/demo.iso \ -monitor unix:/tmp/demo,server,nowait \ -name foo \ -uuid cece4f9f-dff0-575d-0e8e-01fe380f12ea  & $ QEMUPID=$! $ virsh qemu-attach $QEMUPID
Not all functions of libvirt are expected to work reliably after attaching to an externally launched QEMU process. There may be issues with the guest ABI changing upon migration and device hotplug or hotunplug may not work. The attached environment should be considered primarily read-only.
qemu-monitor-command Syntax:
qemu-monitor-command domain { [--hmp] | [--pretty] [--return-value] } command...
Send an arbitrary monitor command command to domain domain through the QEMU monitor.  The results of the command will be printed on stdout.
If more than one argument is provided for command, they are concatenated with a space in between before passing the single command to the monitor.
Note that libvirt uses the QMP to talk to qemu so command must be valid JSON in QMP format to work properly.
If --pretty is given the QMP reply is pretty-printed.
If --return-value is given the 'return' key of the QMP response object is extracted rather than passing through the full reply from QEMU.
If --hmp is passed, the command is considered to be a human monitor command and libvirt will automatically convert it into QMP and convert the result back.
qemu-agent-command Syntax:
qemu-agent-command domain [--timeout seconds | --async | --block] command...
Send an arbitrary guest agent command command to domain domain through QEMU agent.  --timeout, --async and --block options are exclusive. --timeout requires timeout seconds seconds and it must be positive.  When --aysnc is given, the command waits for timeout whether success or failed. And when --block is given, the command waits forever with blocking timeout.
qemu-monitor-event Syntax:
qemu-monitor-event [domain] [--event event-name] [--loop] [--timeout seconds] [--pretty] [--regex] [--no-case] [--timestamp]
Wait for arbitrary QEMU monitor events to occur, and print out the details of events as they happen.  The events can optionally be filtered by domain or event-name.  The 'query-events' QMP command can be used via qemu-monitor-command to learn what events are supported.  If --regex is used, event-name is a basic regular expression instead of a literal string.  If --no-case is used, event-name will match case-insensitively.
By default, this command is one-shot, and returns success once an event occurs; you can send SIGINT (usually via Ctrl-C) to quit immediately.  If --timeout is specified, the command gives up waiting for events after seconds have elapsed.  With --loop, the command prints all events until a timeout or interrupt key.  If --pretty is specified, any JSON event details are pretty-printed for better legibility.
When --timestamp is used, a human-readable timestamp will be printed before the event, and the timing information provided by QEMU will be omitted.
lxc-enter-namespace Syntax:
lxc-enter-namespace domain [--noseclabel] -- /path/to/binary [arg1, [arg2, ...]]
Enter the namespace of domain and execute the command /path/to/binary passing the requested args. The binary path is relative to the container root filesystem, not the host root filesystem. The binary will inherit the environment variables / console visible to virsh. The command will be run with the same sVirt context and cgroups placement as processes within the container. This command only works when connected to the LXC hypervisor driver.  This command succeeds only if /path/to/binary has 0 exit status.
By default the new process will run with the security label of the new parent container. Use the --noseclabel option to instead have the process keep the same security label as virsh.
The following environment variables can be set to alter the behaviour of virsh
• VIRSH_DEBUG=<0 to 4>
Turn on verbose debugging of virsh commands. Valid levels are
• VIRSH_DEBUG=0
DEBUG - Messages at ALL levels get logged
• VIRSH_DEBUG=1
INFO - Logs messages at levels INFO, NOTICE, WARNING and ERROR
• VIRSH_DEBUG=2
NOTICE - Logs messages at levels NOTICE, WARNING and ERROR
• VIRSH_DEBUG=3
WARNING - Logs messages at levels WARNING and ERROR
• VIRSH_DEBUG=4
ERROR - Messages at only ERROR level gets logged.
• VIRSH_LOG_FILE=``LOGFILE``
The file to log virsh debug messages.
• VIRSH_DEFAULT_CONNECT_URI
The hypervisor to connect to by default. Set this to a URI, in the same format as accepted by the connect option. This environment variable is deprecated in favour of the global LIBVIRT_DEFAULT_URI variable which serves the same purpose.
• LIBVIRT_DEFAULT_URI
The hypervisor to connect to by default. Set this to a URI, in the same format as accepted by the connect option. This overrides the default URI set in any client config file and prevents libvirt from probing for drivers.
• VISUAL
The editor to use by the edit and related options.
• EDITOR
The editor to use by the edit and related options, if VISUAL is not set.
• VIRSH_HISTSIZE
The number of commands to remember in the command  history.  The default value is 500.
• LIBVIRT_DEBUG=LEVEL
Turn on verbose debugging of all libvirt API calls. Valid levels are
• LIBVIRT_DEBUG=1
Messages at level DEBUG or above
• LIBVIRT_DEBUG=2
Messages at level INFO or above
• LIBVIRT_DEBUG=3
Messages at level WARNING or above
• LIBVIRT_DEBUG=4
Messages at level ERROR
For further information about debugging options consult https://libvirt.org/logging.html
Please report all bugs you discover.  This should be done via either:
1. the mailing list
https://libvirt.org/contact.html
2. the bug tracker
https://libvirt.org/bugs.html
Alternatively, you may report bugs to your software distributor / vendor.
Please refer to the AUTHORS file distributed with libvirt.
Copyright (C) 2005, 2007-2015 Red Hat, Inc., and the authors listed in the libvirt AUTHORS file.
virsh is distributed under the terms of the GNU LGPL v2+.  This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
virt-install(1), virt-xml-validate(1), virt-top(1), virt-df(1), https://libvirt.org/
gh(1)                                                                      gh(1)
gh - GitHub CLI
gh <command> <subcommand> [flags]
Work seamlessly with GitHub from the command line.
--help[=false]      Show help for command
--version[=false]      Show gh version
$ gh issue create $ gh repo clone cli/cli $ gh pr checkout 321
gh-alias(1), gh-api(1), gh-auth(1), gh-browse(1), gh-codespace(1), gh- completion(1), gh-config(1), gh-extension(1), gh-gist(1), gh-gpg-key(1), gh-issue(1), gh-pr(1), gh-release(1), gh-repo(1), gh-run(1), gh- secret(1), gh-ssh-key(1), gh-workflow(1)
tset(1)                      General Commands Manual                     tset(1)
tset, reset - terminal initialization
tset [-IQVcqrsw] [-] [-e ch] [-i ch] [-k ch] [-m mapping] [terminal] reset [-IQVcqrsw] [-] [-e ch] [-i ch] [-k ch] [-m mapping] [terminal]
tset - initialization This program initializes terminals.
First, tset retrieves the current terminal mode settings for your terminal.  It does this by successively testing
to obtain terminal settings.  Having retrieved these settings, tset remembers which file descriptor to use when updating settings.
Next, tset determines the type of terminal that you are using.  This determination is done as follows, using the first terminal type found.
1. The terminal argument specified on the command line.
2. The value of the TERM environmental variable.
3. (BSD systems only.) The terminal type associated with the standard error output device in the /etc/ttys file.  (On System-V-like UNIXes and systems using that convention, getty does this job by setting TERM according to the type passed to it by /etc/inittab.)
4. The default terminal type, “unknown”.
If the terminal type was not specified on the command-line, the -m option mappings are then applied (see the section TERMINAL TYPE MAPPING for more information).  Then, if the terminal type begins with a question mark (“?”), the user is prompted for confirmation of the terminal type.  An empty response confirms the type, or, another type can be entered to specify a new type.  Once the terminal type has been determined, the terminal description for the terminal is retrieved.  If no terminal description is found for the type, the user is prompted for another terminal type.
Once the terminal description is retrieved,
•   if the “-w” option is enabled, tset may update the terminal's window size.
If the window size cannot be obtained from the operating system, but the terminal description (or environment, e.g., LINES and COLUMNS variables specify this), use this to set the operating system's notion of the window size.
•   if the “-c” option is enabled, the backspace, interrupt and line kill characters (among many other things) are set
•   unless the “-I” option is enabled, the terminal and tab initialization strings are sent to the standard error output, and tset waits one second (in case a hardware reset was issued).
•   Finally, if the erase, interrupt and line kill characters have changed, or are not set to their default values, their values are displayed to the standard error output.
reset - reinitialization When invoked as reset, tset sets the terminal modes to “sane” values:
•   sets cooked and echo modes,
•   turns off cbreak and raw modes,
•   turns on newline translation and
•   resets any unset special characters to their default values
before doing the terminal initialization described above.  Also, rather than using the terminal initialization strings, it uses the terminal reset strings.
The reset command is useful after a program dies leaving a terminal in an abnormal state:
•   you may have to type
<LF>reset<LF>
(the line-feed character is normally control-J) to get the terminal to work, as carriage-return may no longer work in the abnormal state.
•   Also, the terminal will often not echo the command.
The options are as follows:
-c   Set control characters and modes.
-e ch Set the erase character to ch.
-I   Do not send the terminal or tab initialization strings to the terminal.
-i ch Set the interrupt character to ch.
-k ch Set the line kill character to ch.
-m mapping Specify a mapping from a port type to a terminal.  See the section TERMINAL TYPE MAPPING for more information.
-Q   Do not display any values for the erase, interrupt and line kill characters.  Normally tset displays the values for control characters which differ from the system's default values.
-q   The terminal type is displayed to the standard output, and the terminal is not initialized in any way.  The option “-” by itself is equivalent but archaic.
-r   Print the terminal type to the standard error output.
-s   Print the sequence of shell commands to initialize the environment variable TERM to the standard output.  See the section SETTING THE ENVIRONMENT for details.
-V   reports the version of ncurses which was used in this program, and exits.
-w   Resize the window to match the size deduced via setupterm(3X). Normally this has no effect, unless setupterm is not able to detect the window size.
The arguments for the -e, -i, and -k options may either be entered as actual characters or by using the “hat” notation, i.e., control-h may be specified as “^H” or “^h”.
If neither -c or -w is given, both options are assumed.
It is often desirable to enter the terminal type and information about the terminal's capabilities into the shell's environment.  This is done using the -s option.
When the -s option is specified, the commands to enter the information into the shell's environment are written to the standard output.  If the SHELL environmental variable ends in “csh”, the commands are for csh, otherwise, they are for sh.  Note, the csh commands set and unset the shell variable noglob, leaving it unset.  The following line in the .login or .profile files will initialize the environment correctly:
eval `tset -s options ... `
When the terminal is not hardwired into the system (or the current system information is incorrect) the terminal type derived from the /etc/ttys file or the TERM environmental variable is often something generic like network, dialup, or unknown.  When tset is used in a startup script it is often desirable to provide information about the type of terminal used on such ports.
The -m options maps from some set of conditions to a terminal type, that is, to tell tset “If I'm on this port at a particular speed, guess that I'm on that kind of terminal”.
The argument to the -m option consists of an optional port type, an optional operator, an optional baud rate specification, an optional colon (“:”) character and a terminal type.  The port type is a string (delimited by either the operator or the colon character).  The operator may be any combination of “>”, “<”, “@”, and “!”; “>” means greater than, “<” means less than, “@” means equal to and “!” inverts the sense of the test.  The baud rate is specified as a number and is compared with the speed of the standard error output (which should be the control terminal).  The terminal type is a string.
If the terminal type is not specified on the command line, the -m mappings are applied to the terminal type.  If the port type and baud rate match the mapping, the terminal type specified in the mapping replaces the current type.  If more than one mapping is specified, the first applicable mapping is used.
For example, consider the following mapping: dialup>9600:vt100.  The port type is dialup , the operator is >, the baud rate specification is 9600, and the terminal type is vt100.  The result of this mapping is to specify that if the terminal type is dialup, and the baud rate is greater than 9600 baud, a terminal type of vt100 will be used.
If no baud rate is specified, the terminal type will match any baud rate. If no port type is specified, the terminal type will match any port type. For example, -m dialup:vt100 -m :?xterm will cause any dialup port, regardless of baud rate, to match the terminal type vt100, and any non- dialup port type to match the terminal type ?xterm.  Note, because of the leading question mark, the user will be queried on a default port as to whether they are actually using an xterm terminal.
No whitespace characters are permitted in the -m option argument.  Also, to avoid problems with meta-characters, it is suggested that the entire -m option argument be placed within single quote characters, and that csh users insert a backslash character (“\”) before any exclamation marks (“!”).
A reset command appeared in 1BSD (March 1978), written by Kurt Shoens. This program set the erase and kill characters to ^H (backspace) and @ respectively.  Mark Horton improved that in 3BSD (October 1979), adding intr, quit, start/stop and eof characters as well as changing the program to avoid modifying any user settings.  That version of reset did not use the termcap database.
A separate tset command was provided in 1BSD by Eric Allman, using the termcap database.  Allman's comments in the source code indicate that he began work in October 1977, continuing development over the next few years.
According to comments in the source code, the tset program was modified in September 1980, to use logic copied from the 3BSD “reset” when it was invoked as reset.  This version appeared in 4.1cBSD, late in 1982.
Other developers (e.g., Keith Bostic and Jim Bloom) continued to modify tset until 4.4BSD was released in 1993.
The ncurses implementation was lightly adapted from the 4.4BSD sources for a terminfo environment by Eric S. Raymond <esr@snark.thyrsus.com>.
Neither IEEE Std 1003.1/The Open Group Base Specifications Issue 7 (POSIX.1-2008) nor X/Open Curses Issue 7 documents tset or reset.
The AT&T tput utility (AIX, HPUX, Solaris) incorporated the terminal-mode manipulation as well as termcap-based features such as resetting tabstops from tset in BSD (4.1c), presumably with the intention of making tset obsolete.  However, each of those systems still provides tset.  In fact, the commonly-used reset utility is always an alias for tset.
The tset utility provides for backward-compatibility with BSD environments (under most modern UNIXes, /etc/inittab and getty(1) can set TERM appropriately for each dial-up line; this obviates what was tset's most important use).  This implementation behaves like 4.4BSD tset, with a few exceptions specified here.
A few options are different because the TERMCAP variable is no longer supported under terminfo-based ncurses:
•   The -S option of BSD tset no longer works; it prints an error message to the standard error and dies.
•   The -s option only sets TERM, not TERMCAP.
There was an undocumented 4.4BSD feature that invoking tset via a link named “TSET” (or via any other name beginning with an upper-case letter) set the terminal to use upper-case only.  This feature has been omitted.
The -A, -E, -h, -u and -v options were deleted from the tset utility in 4.4BSD.  None of them were documented in 4.3BSD and all are of limited utility at best.  The -a, -d, and -p options are similarly not documented or useful, but were retained as they appear to be in widespread use.  It is strongly recommended that any usage of these three options be changed to use the -m option instead.  The -a, -d, and -p options are therefore omitted from the usage summary above.
Very old systems, e.g., 3BSD, used a different terminal driver which was replaced in 4BSD in the early 1980s.  To accommodate these older systems, the 4BSD tset provided a -n option to specify that the new terminal driver should be used.  This implementation does not provide that choice.
It is still permissible to specify the -e, -i, and -k options without arguments, although it is strongly recommended that such usage be fixed to explicitly specify the character.
As of 4.4BSD, executing tset as reset no longer implies the -Q option. Also, the interaction between the - option and the terminal argument in some historic implementations of tset has been removed.
The -c and -w options are not found in earlier implementations.  However, a different window size-change feature was provided in 4.4BSD.
•   In 4.4BSD, tset uses the window size from the termcap description to set the window size if tset is not able to obtain the window size from the operating system.
•   In ncurses, tset obtains the window size using setupterm, which may be from the operating system, the LINES and COLUMNS environment variables or the terminal description.
Obtaining the window size from the terminal description is common to both implementations, but considered obsolescent.  Its only practical use is for hardware terminals.  Generally speaking, a window size would be unset only if there were some problem obtaining the value from the operating system (and setupterm would still fail).  For that reason, the LINES and COLUMNS environment variables may be useful for working around window- size problems.  Those have the drawback that if the window is resized, those variables must be recomputed and reassigned.  To do this more easily, use the resize(1) program.
The tset command uses these environment variables:
SHELL tells tset whether to initialize TERM using sh or csh syntax.
TERM Denotes your terminal type.  Each terminal type is distinct, though many are similar.
TERMCAP may denote the location of a termcap database.  If it is not an absolute pathname, e.g., begins with a “/”, tset removes the variable from the environment before looking for the terminal description.
/etc/ttys system port name to terminal type mapping database (BSD versions only).
/usr/share/terminfo terminal capability database
csh(1), sh(1), stty(1), curs_terminfo(3X), tty(4), terminfo(5), ttys(5), environ(7)
EMACSCLIENT(1)               General Commands Manual              EMACSCLIENT(1)
emacsclient - tells a running Emacs to visit a file
emacsclient [options] files ...
This manual page documents briefly the emacsclient command.  Full documentation is available in the GNU Info format; see below.  This manual page was originally written for the Debian GNU/Linux distribution, but is not specific to that system.
emacsclient works in conjunction with the built-in Emacs server.
You can either call emacsclient directly or let other programs run it for you when necessary.  On GNU and Unix systems many programs consult the environment variable EDITOR (sometimes also VISUAL) to obtain the command used for editing.  Thus, setting this environment variable to 'emacsclient' will allow these programs to use an already running Emacs for editing.  Other operating systems might have their own methods for defining the default editor.
For emacsclient to work, you need an already running Emacs with a server. Within Emacs, call the functions `server-start' or `server-mode'.  (Your `.emacs' file can do this automatically if you add either `(server- start)' or `(server-mode 1)' to it.)
When you've finished editing the buffer, type `C-x #' (`server-edit'). This saves the file and sends a message back to the `emacsclient' program telling it to exit.  The programs that use `EDITOR' wait for the "editor" (actually, `emacsclient') to exit.  `C-x #' also checks for other pending external requests to edit various files, and selects the next such file.
If you set the variable `server-window' to a window or a frame, `C-x #' displays the server buffer in that window or in that frame.
The programs follow the usual GNU command line syntax, with long options starting with two dashes (`-').
-nw, -t, --tty open a new Emacs frame on the current terminal
-c, --create-frame create a new frame instead of trying to use the current Emacs frame
-e, --eval do not visit files but instead evaluate the arguments as Emacs Lisp expressions.
-n, --no-wait returns immediately without waiting for you to "finish" the buffer in Emacs.
-s, --socket-name=FILENAME use socket named FILENAME for communication.
-f, --server-file=FILENAME use TCP configuration file FILENAME for communication.  This can also be specified via the `EMACS_SERVER_FILE' environment variable.
-a, --alternate-editor=EDITOR if the Emacs server is not running, run the specified editor instead.  This can also be specified via the `ALTERNATE_EDITOR' environment variable.  If the value of EDITOR is the empty string, then Emacs is started in daemon mode and emacsclient will try to connect to it.
-d, --display=DISPLAY tell the server to display the files on the given display.
-V, --version print version information and exit
-H, --help print this usage information message and exit
The program is documented fully in Using Emacs as a Server available via the Info system.
This manual page was written by Stephane Bortzmeyer <bortzmeyer@debian.org>, for the Debian GNU/Linux system (but may be used by others).
This manual page is in the public domain.
AT(1)                        General Commands Manual                       AT(1)
at, batch, atq, atrm - queue, examine, or delete jobs for later execution
at [-V] [-q queue] [-f file] [-u username] [-mMlv] timespec ... at [-V] [-q queue] [-f file] [-u username] [-mMkv] [-t time] at -c job [...] atq [-V] [-q queue] at [-rd] job [...] atrm [-V] job [...] batch at -b
at and batch read commands from standard input or a specified file which are to be executed at a later time, using /bin/sh.
at      executes commands at a specified time.
atq     lists the user's pending jobs, unless the user is the superuser; in that case, everybody's jobs are listed.  The format of the output lines (one for each job) is: Job number, date, hour, queue, and username.
atrm    deletes jobs, identified by their job number.
batch   executes commands when system load levels permit; in other words, when the load average drops below 0.8, or the value specified in the invocation of atd.
At allows fairly complex time specifications, extending the POSIX.2 standard.  It accepts times of the form HH:MM to run a job at a specific time of day.  (If that time is already past, the next day is assumed.) You may also specify midnight, noon, or teatime (4pm) and you can have a time-of-day suffixed with AM or PM for running in the morning or the evening.  You can also say what day the job will be run, by giving a date in the form month-name day with an optional year, or giving a date of the form MMDD[CC]YY, MM/DD/[CC]YY, DD.MM.[CC]YY or [CC]YY-MM-DD.  The specification of a date must follow the specification of the time of day. You can also give times like now + count time-units, where the time-units can be minutes, hours, days, or weeks and you can tell at to run the job today by suffixing the time with today and to run the job tomorrow by suffixing the time with tomorrow.
For example, to run a job at 4pm three days from now, you would do at 4pm + 3 days, to run a job at 10:00am on July 31, you would do at 10am Jul 31 and to run a job at 1am tomorrow, you would do at 1am tomorrow.
If you specify a job to absolutely run at a specific time and date in the past, the job will run as soon as possible.  For example, if it is 8pm and you do a at 6pm today, it will run more likely at 8:05pm.
The definition of the time specification can be found in /usr/share/doc/at/timespec.
For both at and batch, commands are read from standard input or the file specified with the -f option and executed.  The working directory, the environment (except for the variables BASH_VERSINFO, DISPLAY, EUID, GROUPS, SHELLOPTS, TERM, UID, and _) and the umask are retained from the time of invocation.
As at is currently implemented as a setuid program, other environment variables (e.g., LD_LIBRARY_PATH or LD_PRELOAD) are also not exported. This may change in the future.  As a workaround, set these variables explicitly in your job.
An at - or batch - command invoked from a su(1) shell will retain the current userid.  The user will be mailed standard error and standard output from his commands, if any.  Mail will be sent using the command /usr/bin/sendmail.  If at is executed from a su(1) shell, the owner of the login shell will receive the mail.
The superuser may use these commands in any case.  For other users, permission to use at is determined by the files /etc/at.allow and /etc/at.deny.  See at.allow(5) for details.
-V      prints the version number to standard error and exit successfully.
-q queue uses the specified queue.  A queue designation consists of a single letter; valid queue designations range from a to z and A to Z.  The a queue is the default for at and the b queue for batch.  Queues with higher letters run with increased niceness. The special queue "=" is reserved for jobs which are currently running.
If a job is submitted to a queue designated with an uppercase letter, the job is treated as if it were submitted to batch at the time of the job. Once the time is reached, the batch processing rules with respect to load average apply.  If atq is given a specific queue, it will only show jobs pending in that queue.
-m      Send mail to the user when the job has completed even if there was no output.
-M      Never send mail to the user.
-u username Sends mail to username rather than the current user.
-f file Reads the job from file rather than standard input.
-t time run the job at time, given in the format [[CC]YY]MMDDhhmm[.ss]
-l      Is an alias for atq.
-r      Is an alias for atrm.