neulab/tldr huggingface dataset:
--scan For all operations except --examine, --scan will cause the operation to be applied to all arrays listed in /proc/mdstat.  For --examine, --scan causes all devices listed in the config file to be examined.
-b, --brief Be less verbose.  This is used with --detail and --examine.  Using --brief with --verbose gives an intermediate level of verbosity.
Usage: mdadm --monitor options... devices...
This usage causes mdadm to periodically poll a number of md arrays and to report on any events noticed.  mdadm will never exit once it decides that there are arrays to be checked, so it should normally be run in the background.
As well as reporting events, mdadm may move a spare drive from one array to another if they are in the same spare-group or domain and if the destination array has a failed drive but no spares.
If any devices are listed on the command line, mdadm will only monitor those devices.  Otherwise all arrays listed in the configuration file will be monitored.  Further, if --scan is given, then any other md devices that appear in /proc/mdstat will also be monitored.
The result of monitoring the arrays is the generation of events.  These events are passed to a separate program (if specified) and may be mailed to a given E-mail address.
When passing events to a program, the program is run once for each event, and is given 2 or 3 command-line arguments: the first is the name of the event (see below), the second is the name of the md device which is affected, and the third is the name of a related device if relevant (such as a component device that has failed).
If --scan is given, then a program or an E-mail address must be specified on the command line or in the config file.  If neither are available, then mdadm will not monitor anything.  Without --scan, mdadm will continue monitoring as long as something was found to monitor.  If no program or email is given, then each event is reported to stdout.
The different events are:
DeviceDisappeared An md array which previously was configured appears to no longer be configured. (syslog priority: Critical)
If mdadm was told to monitor an array which is RAID0 or Linear, then it will report DeviceDisappeared with the extra information Wrong-Level.  This is because RAID0 and Linear do not support the device-failed, hot-spare and resync operations which are monitored.
RebuildStarted An md array started reconstruction (e.g. recovery, resync, reshape, check, repair). (syslog priority: Warning)
RebuildNN Where NN is a two-digit number (ie. 05, 48). This indicates that rebuild has passed that many percent of the total. The events are generated with fixed increment since 0. Increment size may be specified with a commandline option (default is 20). (syslog priority: Warning)
RebuildFinished An md array that was rebuilding, isn't any more, either because it finished normally or was aborted. (syslog priority: Warning)
Fail   An active component device of an array has been marked as faulty. (syslog priority: Critical)
FailSpare A spare component device which was being rebuilt to replace a faulty device has failed. (syslog priority: Critical)
SpareActive A spare component device which was being rebuilt to replace a faulty device has been successfully rebuilt and has been made active.  (syslog priority: Info)
NewArray A new md array has been detected in the /proc/mdstat file. (syslog priority: Info)
DegradedArray A newly noticed array appears to be degraded.  This message is not generated when mdadm notices a drive failure which causes degradation, but only when mdadm notices that an array is degraded when it first sees the array.  (syslog priority: Critical)
MoveSpare A spare drive has been moved from one array in a spare-group or domain to another to allow a failed drive to be replaced. (syslog priority: Info)
SparesMissing If mdadm has been told, via the config file, that an array should have a certain number of spare devices, and mdadm detects that it has fewer than this number when it first sees the array, it will report a SparesMissing message.  (syslog priority: Warning)
TestMessage An array was found at startup, and the --test flag was given. (syslog priority: Info)
Only Fail, FailSpare, DegradedArray, SparesMissing and TestMessage cause Email to be sent.  All events cause the program to be run.  The program is run with two or three arguments: the event name, the array device and possibly a second device.
Each event has an associated array device (e.g.  /dev/md1) and possibly a second device.  For Fail, FailSpare, and SpareActive the second device is the relevant component device.  For MoveSpare the second device is the array that the spare was moved from.
For mdadm to move spares from one array to another, the different arrays need to be labeled with the same spare-group or the spares must be allowed to migrate through matching POLICY domains in the configuration file.  The spare-group name can be any string; it is only necessary that different spare groups use different names.
When mdadm detects that an array in a spare group has fewer active devices than necessary for the complete array, and has no spare devices, it will look for another array in the same spare group that has a full complement of working drive and a spare.  It will then attempt to remove the spare from the second drive and add it to the first.  If the removal succeeds but the adding fails, then it is added back to the original array.
If the spare group for a degraded array is not defined, mdadm will look at the rules of spare migration specified by POLICY lines in mdadm.conf and then follow similar steps as above if a matching spare is found.
The GROW mode is used for changing the size or shape of an active array. For this to work, the kernel must support the necessary change.  Various types of growth are being added during 2.6 development.
Currently the supported changes include
•   change the "size" attribute for RAID1, RAID4, RAID5 and RAID6.
•   increase or decrease the "raid-devices" attribute of RAID0, RAID1, RAID4, RAID5, and RAID6.
•   change the chunk-size and layout of RAID0, RAID4, RAID5, RAID6 and RAID10.
•   convert between RAID1 and RAID5, between RAID5 and RAID6, between RAID0, RAID4, and RAID5, and between RAID0 and RAID10 (in the near-2 mode).
•   add a write-intent bitmap to any array which supports these bitmaps, or remove a write-intent bitmap from such an array.
•   change the array's consistency policy.
Using GROW on containers is currently supported only for Intel's IMSM container format.  The number of devices in a container can be increased - which affects all arrays in the container - or an array in a container can be converted between levels where those levels are supported by the container, and the conversion is on of those listed above.  Resizing arrays in an IMSM container with --grow --size is not yet supported.
•   Intel's native checkpointing doesn't use --backup-file option and it is transparent for assembly feature.
•   Roaming between Windows(R) and Linux systems for IMSM metadata is not supported during grow process.
SIZE CHANGES Normally when an array is built the "size" is taken from the smallest of the drives.  If all the small drives in an arrays are, one at a time, removed and replaced with larger drives, then you could have an array of large drives with only a small amount used.  In this situation, changing the "size" with "GROW" mode will allow the extra space to start being used.  If the size is increased in this way, a "resync" process will start to make sure the new parts of the array are synchronised.
Note that when an array changes size, any filesystem that may be stored in the array will not automatically grow or shrink to use or vacate the space.  The filesystem will need to be explicitly told to use the extra space after growing, or to reduce its size prior to shrinking the array.
Also the size of an array cannot be changed while it has an active bitmap.  If an array has a bitmap, it must be removed before the size can be changed. Once the change is complete a new bitmap can be created.
Note: --grow --size is not yet supported for external file bitmap.
RAID-DEVICES CHANGES A RAID1 array can work with any number of devices from 1 upwards (though 1 is not very useful).  There may be times which you want to increase or decrease the number of active devices.  Note that this is different to hot-add or hot-remove which changes the number of inactive devices.
When reducing the number of devices in a RAID1 array, the slots which are to be removed from the array must already be vacant.  That is, the devices which were in those slots must be failed and removed.
When the number of devices is increased, any hot spares that are present will be activated immediately.
Changing the number of active devices in a RAID5 or RAID6 is much more effort.  Every block in the array will need to be read and written back to a new location.  From 2.6.17, the Linux Kernel is able to increase the number of devices in a RAID5 safely, including restarting an interrupted "reshape".  From 2.6.31, the Linux Kernel is able to increase or decrease the number of devices in a RAID5 or RAID6.
From 2.6.35, the Linux Kernel is able to convert a RAID0 in to a RAID4 or RAID5.  mdadm uses this functionality and the ability to add devices to a RAID4 to allow devices to be added to a RAID0.  When requested to do this, mdadm will convert the RAID0 to a RAID4, add the necessary disks and make the reshape happen, and then convert the RAID4 back to RAID0.
When decreasing the number of devices, the size of the array will also decrease.  If there was data in the array, it could get destroyed and this is not reversible, so you should firstly shrink the filesystem on the array to fit within the new size.  To help prevent accidents, mdadm requires that the size of the array be decreased first with mdadm --grow --array-size.  This is a reversible change which simply makes the end of the array inaccessible.  The integrity of any data can then be checked before the non-reversible reduction in the number of devices is request.
When relocating the first few stripes on a RAID5 or RAID6, it is not possible to keep the data on disk completely consistent and crash-proof. To provide the required safety, mdadm disables writes to the array while this "critical section" is reshaped, and takes a backup of the data that is in that section.  For grows, this backup may be stored in any spare devices that the array has, however it can also be stored in a separate file specified with the --backup-file option, and is required to be specified for shrinks, RAID level changes and layout changes.  If this option is used, and the system does crash during the critical period, the same file must be passed to --assemble to restore the backup and reassemble the array.  When shrinking rather than growing the array, the reshape is done from the end towards the beginning, so the "critical section" is at the end of the reshape.
LEVEL CHANGES Changing the RAID level of any array happens instantaneously.  However in the RAID5 to RAID6 case this requires a non-standard layout of the RAID6 data, and in the RAID6 to RAID5 case that non-standard layout is required before the change can be accomplished.  So while the level change is instant, the accompanying layout change can take quite a long time.  A --backup-file is required.  If the array is not simultaneously being grown or shrunk, so that the array size will remain the same - for example, reshaping a 3-drive RAID5 into a 4-drive RAID6 - the backup file will be used not just for a "cricital section" but throughout the reshape operation, as described below under LAYOUT CHANGES.
CHUNK-SIZE AND LAYOUT CHANGES Changing the chunk-size of layout without also changing the number of devices as the same time will involve re-writing all blocks in-place.  To ensure against data loss in the case of a crash, a --backup-file must be provided for these changes.  Small sections of the array will be copied to the backup file while they are being rearranged.  This means that all the data is copied twice, once to the backup and once to the new layout on the array, so this type of reshape will go very slowly.
If the reshape is interrupted for any reason, this backup file must be made available to mdadm --assemble so the array can be reassembled. Consequently the file cannot be stored on the device being reshaped.
BITMAP CHANGES A write-intent bitmap can be added to, or removed from, an active array. Either internal bitmaps, or bitmaps stored in a separate file, can be added.  Note that if you add a bitmap stored in a file which is in a filesystem that is on the RAID array being affected, the system will deadlock.  The bitmap must be on a separate filesystem.
CONSISTENCY POLICY CHANGES The consistency policy of an active array can be changed by using the --consistency-policy option in Grow mode. Currently this works only for the ppl and resync policies and allows to enable or disable the RAID5 Partial Parity Log (PPL).
Usage: mdadm --incremental [--run] [--quiet] component-device [optional- aliases-for-device]
Usage: mdadm --incremental --fail component-device
Usage: mdadm --incremental --rebuild-map
Usage: mdadm --incremental --run --scan
This mode is designed to be used in conjunction with a device discovery system.  As devices are found in a system, they can be passed to mdadm --incremental to be conditionally added to an appropriate array.
Conversely, it can also be used with the --fail flag to do just the opposite and find whatever array a particular device is part of and remove the device from that array.
If the device passed is a CONTAINER device created by a previous call to mdadm, then rather than trying to add that device to an array, all the arrays described by the metadata of the container will be started.
mdadm performs a number of tests to determine if the device is part of an array, and which array it should be part of.  If an appropriate array is found, or can be created, mdadm adds the device to the array and conditionally starts the array.
Note that mdadm will normally only add devices to an array which were previously working (active or spare) parts of that array.  The support for automatic inclusion of a new drive as a spare in some array requires a configuration through POLICY in config file.
The tests that mdadm makes are as follow:
+      Is the device permitted by mdadm.conf?  That is, is it listed in a DEVICES line in that file.  If DEVICES is absent then the default it to allow any device.  Similarly if DEVICES contains the special word partitions then any device is allowed.  Otherwise the device name given to mdadm, or one of the aliases given, or an alias found in the filesystem, must match one of the names or patterns in a DEVICES line.
This is the only context where the aliases are used.  They are usually provided by a udev rules mentioning $env{DEVLINKS}.
+      Does the device have a valid md superblock?  If a specific metadata version is requested with --metadata or -e then only that style of metadata is accepted, otherwise mdadm finds any known version of metadata.  If no md metadata is found, the device may be still added to an array as a spare if POLICY allows.
mdadm keeps a list of arrays that it has partially assembled in /run/mdadm/map.  If no array exists which matches the metadata on the new device, mdadm must choose a device name and unit number.  It does this based on any name given in mdadm.conf or any name information stored in the metadata.  If this name suggests a unit number, that number will be used, otherwise a free unit number will be chosen.  Normally mdadm will prefer to create a partitionable array, however if the CREATE line in mdadm.conf suggests that a non-partitionable array is preferred, that will be honoured.
If the array is not found in the config file and its metadata does not identify it as belonging to the "homehost", then mdadm will choose a name for the array which is certain not to conflict with any array which does belong to this host.  It does this be adding an underscore and a small number to the name preferred by the metadata.
Once an appropriate array is found or created and the device is added, mdadm must decide if the array is ready to be started.  It will normally compare the number of available (non-spare) devices to the number of devices that the metadata suggests need to be active.  If there are at least that many, the array will be started.  This means that if any devices are missing the array will not be restarted.
As an alternative, --run may be passed to mdadm in which case the array will be run as soon as there are enough devices present for the data to be accessible.  For a RAID1, that means one device will start the array. For a clean RAID5, the array will be started as soon as all but one drive is present.
Note that neither of these approaches is really ideal.  If it can be known that all device discovery has completed, then mdadm -IRs can be run which will try to start all arrays that are being incrementally assembled.  They are started in "read-auto" mode in which they are read-only until the first write request.  This means that no metadata updates are made and no attempt at resync or recovery happens. Further devices that are found before the first write can still be added safely.
This section describes environment variables that affect how mdadm operates.
MDADM_NO_MDMON Setting this value to 1 will prevent mdadm from automatically launching mdmon.  This variable is intended primarily for debugging mdadm/mdmon.
MDADM_NO_UDEV Normally, mdadm does not create any device nodes in /dev, but leaves that task to udev.  If udev appears not to be configured, or if this environment variable is set to '1', the mdadm will create and devices that are needed.
MDADM_NO_SYSTEMCTL If mdadm detects that systemd is in use it will normally request systemd to start various background tasks (particularly mdmon) rather than forking and running them in the background.  This can be suppressed by setting MDADM_NO_SYSTEMCTL=1.
IMSM_NO_PLATFORM A key value of IMSM metadata is that it allows interoperability with boot ROMs on Intel platforms, and with other major operating systems.  Consequently, mdadm will only allow an IMSM array to be created or modified if detects that it is running on an Intel platform which supports IMSM, and supports the particular configuration of IMSM that is being requested (some functionality requires newer OROM support).
These checks can be suppressed by setting IMSM_NO_PLATFORM=1 in the environment.  This can be useful for testing or for disaster recovery.  You should be aware that interoperability may be compromised by setting this value.
MDADM_GROW_ALLOW_OLD If an array is stopped while it is performing a reshape and that reshape was making use of a backup file, then when the array is re-assembled mdadm will sometimes complain that the backup file is too old.  If this happens and you are certain it is the right backup file, you can over-ride this check by setting MDADM_GROW_ALLOW_OLD=1 in the environment.
MDADM_CONF_AUTO Any string given in this variable is added to the start of the AUTO line in the config file, or treated as the whole AUTO line if none is given.  It can be used to disable certain metadata types when mdadm is called from a boot script.  For example export MDADM_CONF_AUTO='-ddf -imsm' will make sure that mdadm does not automatically assemble any DDF or IMSM arrays that are found.  This can be useful on systems configured to manage such arrays with dmraid.
mdadm --query /dev/name-of-device This will find out if a given device is a RAID array, or is part of one, and will provide brief information about the device.
mdadm --assemble --scan This will assemble and start all arrays listed in the standard config file.  This command will typically go in a system startup file.
mdadm --stop --scan This will shut down all arrays that can be shut down (i.e. are not currently in use).  This will typically go in a system shutdown script.
mdadm --follow --scan --delay=120 If (and only if) there is an Email address or program given in the standard config file, then monitor the status of all arrays listed in that file by polling them ever 2 minutes.
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/hd[ac]1 Create /dev/md0 as a RAID1 array consisting of /dev/hda1 and /dev/hdc1.
echo 'DEVICE /dev/hd*[0-9] /dev/sd*[0-9]' > mdadm.conf mdadm --detail --scan >> mdadm.conf This will create a prototype config file that describes currently active arrays that are known to be made from partitions of IDE or SCSI drives. This file should be reviewed before being used as it may contain unwanted detail.
echo 'DEVICE /dev/hd[a-z] /dev/sd*[a-z]' > mdadm.conf mdadm --examine --scan --config=mdadm.conf >> mdadm.conf This will find arrays which could be assembled from existing IDE and SCSI whole drives (not partitions), and store the information in the format of a config file.  This file is very likely to contain unwanted detail, particularly the devices= entries.  It should be reviewed and edited before being used as an actual config file.
mdadm --examine --brief --scan --config=partitions mdadm -Ebsc partitions Create a list of devices by reading /proc/partitions, scan these for RAID superblocks, and printout a brief listing of all that were found.
mdadm -Ac partitions -m 0 /dev/md0 Scan all partitions and devices listed in /proc/partitions and assemble /dev/md0 out of all such devices with a RAID superblock with a minor number of 0.
mdadm --monitor --scan --daemonise > /run/mdadm/mon.pid If config file contains a mail address or alert program, run mdadm in the background in monitor mode monitoring all md devices.  Also write pid of mdadm daemon to /run/mdadm/mon.pid.
mdadm -Iq /dev/somedevice Try to incorporate newly discovered device into some array as appropriate.
mdadm --incremental --rebuild-map --run --scan Rebuild the array map from any current arrays, and then start any that can be started.
mdadm /dev/md4 --fail detached --remove detached Any devices which are components of /dev/md4 will be marked as faulty and then remove from the array.
mdadm --grow /dev/md4 --level=6 --backup-file=/root/backup-md4 The array /dev/md4 which is currently a RAID5 array will be converted to RAID6.  There should normally already be a spare drive attached to the array as a RAID6 needs one more drive than a matching RAID5.
mdadm --create /dev/md/ddf --metadata=ddf --raid-disks 6 /dev/sd[a-f] Create a DDF array over 6 devices.
mdadm --create /dev/md/home -n3 -l5 -z 30000000 /dev/md/ddf Create a RAID5 array over any 3 devices in the given DDF set.  Use only 30 gigabytes of each device.
mdadm -A /dev/md/ddf1 /dev/sd[a-f] Assemble a pre-exist ddf array.
mdadm -I /dev/md/ddf1 Assemble all arrays contained in the ddf array, assigning names as appropriate.
mdadm --create --help Provide help about the Create mode.
mdadm --config --help Provide help about the format of the config file.
mdadm --help Provide general help.
/proc/mdstat If you're using the /proc filesystem, /proc/mdstat lists all active md devices with information about them.  mdadm uses this to find arrays when --scan is given in Misc mode, and to monitor array reconstruction on Monitor mode.
/etc/mdadm.conf The config file lists which devices may be scanned to see if they contain MD super block, and gives identifying information (e.g. UUID) about known MD arrays.  See mdadm.conf(5) for more details.
/etc/mdadm.conf.d A directory containing configuration files which are read in lexical order.
/run/mdadm/map When --incremental mode is used, this file gets a list of arrays currently being created.
mdadm understand two sorts of names for array devices.
The first is the so-called 'standard' format name, which matches the names used by the kernel and which appear in /proc/mdstat.
The second sort can be freely chosen, but must reside in /dev/md/.  When giving a device name to mdadm to create or assemble an array, either full path name such as /dev/md0 or /dev/md/home can be given, or just the suffix of the second sort of name, such as home can be given.
When mdadm chooses device names during auto-assembly or incremental assembly, it will sometimes add a small sequence number to the end of the name to avoid conflicted between multiple arrays that have the same name. If mdadm can reasonably determine that the array really is meant for this host, either by a hostname in the metadata, or by the presence of the array in mdadm.conf, then it will leave off the suffix if possible.  Also if the homehost is specified as <ignore> mdadm will only use a suffix if a different array of the same name already exists or is listed in the config file.
The standard names for non-partitioned arrays (the only sort of md array available in 2.4 and earlier) are of the form
/dev/mdNN
where NN is a number.  The standard names for partitionable arrays (as available from 2.6 onwards) are of the form:
/dev/md_dNN
Partition numbers should be indicated by adding "pMM" to these, thus "/dev/md/d1p2".
From kernel version 2.6.28 the "non-partitioned array" can actually be partitioned.  So the "md_dNN" names are no longer needed, and partitions such as "/dev/mdNNpXX" are possible.
From kernel version 2.6.29 standard names can be non-numeric following the form:
/dev/md_XXX
where XXX is any string.  These names are supported by mdadm since version 3.3 provided they are enabled in mdadm.conf.
mdadm was previously known as mdctl.
For further information on mdadm usage, MD and the various levels of RAID, see:
http://raid.wiki.kernel.org/
(based upon Jakob Østergaard's Software-RAID.HOWTO)
The latest version of mdadm should always be available from
http://www.kernel.org/pub/linux/utils/raid/mdadm/
Related man pages:
mdmon(8), mdadm.conf(5), md(4).
MKLOST+FOUND(8)              System Manager's Manual             MKLOST+FOUND(8)
mklost+found - create a lost+found directory on a mounted Linux second extended file system
mklost+found
mklost+found is used to create a lost+found directory in the current working directory on a Linux second extended file system.  There is normally a lost+found directory in the root directory of each file system.
mklost+found pre-allocates disk blocks to the lost+found directory so that when e2fsck(8) is being run to recover a file system, it does not need to allocate blocks in the file system to store a large number of unlinked files.  This ensures that e2fsck will not have to allocate data blocks in the file system during recovery.
mklost+found has been written by Remy Card <Remy.Card@linux.org>.  It is currently being maintained by Theodore Ts'o <tytso@alum.mit.edu>.
There are none :-)
mklost+found is part of the e2fsprogs package and is available from http://e2fsprogs.sourceforge.net.
W(1)                              User Commands                             W(1)
w - Show who is logged on and what they are doing.
w displays information about the users currently on the machine, and their processes.  The header shows, in this order, the current time, how long the system has been running, how many users are currently logged on, and the system load averages for the past 1, 5, and 15 minutes.
The following entries are displayed for each user: login name, the tty name, the remote host, login time, idle time, JCPU, PCPU, and the command line of their current process.
The JCPU time is the time used by all processes attached to the tty.  It does not include past background jobs, but does include currently running background jobs.
The PCPU time is the time used by the current process, named in the "what" field.
COMMAND-LINE OPTIONS -h, --no-header Don't print the header.
-u, --no-current Ignores the username while figuring out the current process and cpu times.  To demonstrate this, do a su and do a w and a w -u.
-s, --short Use the short format.  Don't print the login time, JCPU or PCPU times.
-f, --from Toggle printing the from (remote hostname) field.  The default as released is for the from field to not be printed, although your system administrator or distribution maintainer may have compiled a version in which the from field is shown by default.
-i, --ip-addr Display IP address instead of hostname for from field.
-o, --old-style Old style output.  Prints blank space for idle times less than one minute.
user   Show information about the specified user only.
PROCPS_USERLEN Override the default width of the username column.  Defaults to 8.
PROCPS_FROMLEN Override the default width of the from column.  Defaults to 16.
/var/run/utmp information about who is currently logged on
/proc  process information
free(1), ps(1), top(1), uptime(1), utmp(5), who(1)
w was re-written almost entirely by Charles Blake, based on the version by Larry Greenfield ⟨greenfie@gauss.rutgers.edu⟩ and Michael K. Johnson ⟨johnsonm@redhat.com⟩
LLVM-STRINGS(1)                       LLVM                       LLVM-STRINGS(1)
llvm-strings - print strings
llvm-strings [options] [input...]
llvm-strings is a tool intended as a drop-in replacement for GNU's strings, which looks for printable strings in files and writes them to the standard output stream. A printable string is any sequence of four (by default) or more printable ASCII characters. The end of the file, or any other byte, terminates the current sequence.
llvm-strings looks for strings in each input file specified.  Unlike GNU strings it looks in the entire input file, regardless of file format, rather than restricting the search to certain sections of object files. If "-" is specified as an input, or no input is specified, the program reads from the standard input stream.
$ cat input.txt bars foo wibble blob $ llvm-strings input.txt bars wibble blob
--all, -a Silently ignored. Present for GNU strings compatibility.
--bytes=<length>, -n Set the minimum number of printable ASCII characters required for a sequence of bytes to be considered a string. The default value is 4.
--help, -h Display a summary of command line options.
--print-file-name, -f Display the name of the containing file before each string.
$ llvm-strings --print-file-name test.o test.elf test.o: _Z5hellov test.o: some_bss test.o: test.cpp test.o: main test.elf: test.cpp test.elf: test2.cpp test.elf: _Z5hellov test.elf: main test.elf: some_bss
--radix=<radix>, -t Display the offset within the file of each string, before the string and using the specified radix. Valid <radix> values are o, d and x for octal, decimal and hexadecimal respectively.
$ llvm-strings --radix=o test.o 1054 _Z5hellov 1066 .rela.text 1101 .comment 1112 some_bss 1123 .bss 1130 test.cpp 1141 main $ llvm-strings --radix=d test.o 556 _Z5hellov 566 .rela.text 577 .comment 586 some_bss 595 .bss 600 test.cpp 609 main $ llvm-strings -t x test.o 22c _Z5hellov 236 .rela.text 241 .comment 24a some_bss 253 .bss 258 test.cpp 261 main
--version Display the version of the llvm-strings executable.
llvm-strings exits with a non-zero exit code if there is an error. Otherwise, it exits with code 0.
runsvdir(8)                  System Manager's Manual                 runsvdir(8)
runsvdir - starts and monitors a collection of runsv(8) processes
runsvdir [-P] dir [ log ]
dir must be a directory.  log is a space holder for a readproctitle log, and must be at least seven characters long or absent.
runsvdir starts a runsv(8) process for each subdirectory, or symlink to a directory, in the services directory dir, up to a limit of 1000 subdirectories, and restarts a runsv(8) process if it terminates. runsvdir skips subdirectory names starting with dots.  runsv(8) must be in runsvdir's PATH.
At least every five seconds runsvdir checks whether the time of last modification, the inode, or the device, of the services directory dir has changed.  If so, it re-scans the service directory, and if it sees a new subdirectory, or new symlink to a directory, in dir, it starts a new runsv(8) process; if runsvdir sees a subdirectory being removed that was previously there, it sends the corresponding runsv(8) process a TERM signal, stops monitoring this process, and so does not restart the runsv(8) process if it exits.
If the log argument is given to runsvdir, all output to standard error is redirected to this log, which is similar to the daemontools' readproctitle log.  To see the most recent error messages, use a process- listing tool such as ps(1).  runsvdir writes a dot to the readproctitle log every 15 minutes so that old error messages expire.
-P     use setsid(2) to run each runsv(8) process in a new session and separate process group.
If runsvdir receives a TERM signal, it exits with 0 immediately.
If runsvdir receives a HUP signal, it sends a TERM signal to each runsv(8) process it is monitoring and then exits with 111.
sv(8), runsv(8), runsvchdir(8), runit(8), runit-init(8), chpst(8), svlogd(8), utmpset(8), setsid(2)
jar(1)                       General Commands Manual                      jar(1)
Name jar-The Java Archive Tool
jar combines multiple files into a single JAR archive file.
Create jar file jar c[v0Mmfe] [manifest] [jarfile] [entrypoint] [-C dir] inputfiles [-Joption]
Update jar file jar u[v0Mmfe] [manifest] [jarfile] [entrypoint] [-C dir] inputfiles [-Joption]
Extract jar file jar x[vf] [jarfile] [inputfiles] [-Joption]
List table of contents of jar file jar t[vf] [jarfile] [inputfiles] [-Joption]
Add index to jar file jar i jarfile [-Joption]
cuxtiv0Mmfe Options that control the jar command.
jarfile Jar file to be created (c), updated (u), extracted (x), or have its table of contents viewed (t). The -f option and filename jarfile are a pair -- if either is present, they must both appear. Note that omitting f and jarfile accepts a "jar file" from standard input (for x and t) or sends the "jar file" to standard output (for c and u).
inputfiles Files or directories, separated by spaces, to be combined into jarfile (for c and u), or to be extracted (for x) or listed (for t) from jarfile. All directories are processed recursively. The files are compressed unless option 0 (zero) is used.
manifest Pre-existing manifest file whose name: value pairs are to be included in MANIFEST.MF in the jar file. The -m option and filename manifest are a pair -- if either is present, they must both appear. The letters m, f and e must appear in the same order that manifest, jarfile, entrypoint appear.
entrypoint The name of the class that set as the application entry point for stand-alone applications bundled into executable jar file. The -e option and entrypoint are a pair -- if either is present, they must both appear. The letters m, f and e must appear in the same order that manifest, jarfile, entrypoint appear.
-C dir Temporarily changes directories to dir while processing the following inputfiles argument. Multiple -C dir inputfiles sets are allowed.
-Joption Option to be passed into the Java runtime environment. (There must be no space between -J and option).
The jar tool combines multiple files into a single JAR archive file. jar is a general-purpose archiving and compression tool, based on ZIP and the ZLIB @ http://www.gzip.org/zlib/ compression format. However, jar was designed mainly package java applets or applications into a single archive. When the components of an applet or application (files, images and sounds) are combined into a single archive, they can be downloaded by a java agent (like a browser) in a single HTTP transaction, rather than requiring a new connection for each piece. This dramatically improves download times. jar also compresses files and so further improves download time. In addition, it allows individual entries in a file to be signed by the applet author so that their origin can be authenticated. The syntax for the jar tool is almost identical to the syntax for the tar command. A jar archive can be used as a class path entry, whether or not it is compressed.
Typical usage to combine files into a jar file is:
% jar cf myFile.jar *.class
In this example, all the class files in the current directory are placed into the file named myFile.jar. The jar tool automatically generates a manifest file entry named META-INF/MANIFEST.MF. It is always the first entry in the jar file. The manifest file declares meta-information about the archive, and stores that data as name : value pairs. Refer to the JAR file specification @ http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR%20Manifest for details explaining how the jar tool stores meta-information in the manifest file.
If a jar file should include name : value pairs contained in an existing manifest file, specify that file using the -m option:
% jar cmf myManifestFile myFile.jar *.class
An existing manifest file must end with a new line character.  jar does not parse the last line of a manifest file if it does not end with a new line character.
Note:  A jar command that specifies cfm on the command line instead of cmf (the order of the m and -f options are reversed), the jar command line must specify the name of the jar archive first, followed by the name of the manifest file: % jar cfm myFile.jar myManifestFile *.class
The manifest is in a text format inspired by RFC822 ASCII format, so it is easy to view and process manifest-file contents.
To extract the files from a jar file, use x:
% jar xf myFile.jar
To extract individual files from a jar file, supply their filenames:
% jar xf myFile.jar foo bar
Beginning with version 1.3 of the JDK, the jar utility supports JarIndex @ http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Index, which allows application class loaders to load classes more efficiently from jar files. If an application or applet is bundled into multiple jar files,  only the necessary jar files will be downloaded and opened to load classes. This performance optimization is enabled by running jar with the -ioption. It will generate package location information for the specified main jar file and all the jar files it depends on, which need to be specified in the Class-Path attribute of the main jar file's manifest.
% jar i main.jar
In this example, an INDEX.LIST file is inserted into the META-INF directory of main.jar. The application class loader uses the information stored in this file for efficient class loading.  For details about how location information is stored in the index file, refer to the JarIndex specification. To copy directories, first compress files in dir1 to stdout, then extract from stdin to dir2 (omitting the -f option from both jar commands):
% (cd dir1; jar c .) | (cd dir2; jar x)
To review command samples which use jar to opeate on jar files and jar file manifests, see Examples, below. Also refer to the jar trail of the Java Tutorial @ http://docs.oracle.com/javase/tutorial/deployment/jar.
c  Creates a new archive file named jarfile (if f is specified) or to standard output (if f and jarfile are omitted). Add to it the files and directories specified by inputfiles.
u  Updates an existing file jarfile (when f is specified) by adding to it files and directories specified by inputfiles. For example: jar uf foo.jar foo.class would add the file foo.class to the existing jar file foo.jar. The -u option can also update the manifest entry, as given by this example: jar umf manifest foo.jar updates the foo.jar manifest with the name : value pairs in manifest.
x  Extracts files and directories from jarfile (if f is specified) or standard input (if f and jarfile are omitted). If inputfiles is specified, only those specified files and directories are extracted. Otherwise, all files and directories are extracted. The time and date of the extracted files are those given in the archive.
t  Lists the table of contents from jarfile (if f is specified) or standard input (if f and jarfile are omitted). If inputfiles is specified, only those specified files and directories are listed. Otherwise, all files and directories are listed.
i  Generate index information for the specified jarfile and its dependent jar files. For example: jar i foo.jar
would generate an INDEX.LIST file in foo.jar which contains location information for each package in foo.jar and all the jar files specified in the Class-Path attribute of foo.jar. See the index example.
f  Specifies the file jarfile to be created (c), updated (u), extracted (x), indexed (i), or viewed (t). The -f option and filename jarfile are a pair -- if present, they must both appear. Omitting f and jarfile accepts a jar file name from stdin(for x and t) or sends jar file to stdout (for c and u).
v  Generates verbose output to standard output. Examples shown below.
0  (zero) Store without using ZIP compression.
M  Do not create a manifest file entry (for c and u), or delete a manifest file entry if one exists (for u).
m  Includes name : value attribute pairs from the specified manifest file manifest in the file at META-INF/MANIFEST.MF. jar adds a name : value pair unless an entry already exists with the same name, in which case jar updates its value. On the command line, the letters m and f must appear in the same order that manifest and jarfile appear. Example use: jar cmf myManifestFile myFile.jar *.class You can add special-purpose name : value attribute pairs to the manifest that aren't contained in the default manifest. For example, you can add attributes specifying vendor information, version information, package sealing, or to make JAR-bundled applications executable. See the JAR Files @ http://docs.oracle.com/javase/tutorial/deployment/jar/ trail in the Java Tutorial  for examples of using the -m option.
e  Sets entrypoint as the application entry point for stand-alone applications bundled into executable jar file. The use of this option creates or overrides the Main-Class attribute value in the manifest file. This option can be used during creation of jar file or while updating the jar file. This option specifies the application entry point without editing or creating the manifest file. For example, this command creates Main.jar where the Main-Class attribute value in the manifest is set to Main: jar cfe Main.jar Main Main.class The java runtime can directly invoke this application by running the following command: java -jar Main.jar If the entrypoint class name is in a package it may use either a dot (".") or slash ("/") character as the delimiter. For example, if Main.class is in a package called foo the entry point can be specified in the following ways: jar -cfe Main.jar foo/Main foo/Main.class or jar -cfe Main.jar foo.Main foo/Main.class Note:  specifying both -m and -e options together when the given manifest also contains the Main-Class attribute results in an ambigous Main.class specification, leading to an error and the jar creation or update operation is aborted.
-C dir Temporarily changes directories (cd dir) during execution of the jar command while processing the following inputfiles argument. Its operation is intended to be similar to the -C option of the UNIX tar utility. For example, this command changes to the classes directory and adds the bar.class from that directory to foo.jar: jar uf foo.jar -C classes bar.class This command changes to the classes directory and adds to foo.jar all files within the classes directory (without creating a classes directory in the jar file), then changes back to the original directory before changing to the bin directory to add xyz.class to foo.jar. jar uf foo.jar -C classes . -C bin xyz.class If classes holds files bar1 and bar2, then here's what the jar file will contain using jar tf foo.jar: META-INF/ META-INF/MANIFEST.MF bar1 bar2 xyz.class
-Joption Pass option to the Java runtime environment, where option is one of the options described on the reference page for the java application launcher. For example, -J-Xmx48M sets the maximum memory to 48 megabytes. It is a common convention for -J to pass options to the underlying runtime environment.
To shorten or simplify the jar command line, you can specify one or more files that themselves contain arguments to the jar command (except -J options). This enables you to create jar commands of any length, overcoming command line limits imposed by the operating system.
An argument file can include options and filenames. The arguments within a file can be space-separated or newline-separated. Filenames within an argument file are relative to the current directory, not relative to the location of the argument file. Wildcards (*) that might otherwise be expanded by the operating system shell are not expanded. Use of the @ character to recursively interpret files is not supported. The -J options are not supported because they are passed to the launcher, which does not support argument files.
When executing jar, pass in the path and name of each argument file with the @ leading character. When jar encounters an argument beginning with the character @, it expands the contents of that file into the argument list. The example below, classes.list holds the names of files output by a find command:
% find . -name '*.class' -print > classes.list
You can then execute the jar command on Classes.list by passing it to jar using argfile syntax:
% jar cf my.jar @classes.list
An argument file can specify a path, but any filenames inside the argument file that have relative paths are relative to the current working directory, not to the path passed in. Here is an example: % jar @path1/classes.list
To add all the files in a particular directory to an archive (overwriting contents if the archive already exists). Enumerating verbosely (with the -v option) will tell you more information about the files in the archive, such as their size and last modified date. % ls 1.au          Animator.class    monkey.jpg 2.au          Wave.class        spacemusic.au 3.au          at_work.gif
% jar cvf bundle.jar * added manifest adding: 1.au(in = 2324) (out= 67)(deflated 97%) adding: 2.au(in = 6970) (out= 90)(deflated 98%) adding: 3.au(in = 11616) (out= 108)(deflated 99%) adding: Animator.class(in = 2266) (out= 66)(deflated 97%) adding: Wave.class(in = 3778) (out= 81)(deflated 97%) adding: at_work.gif(in = 6621) (out= 89)(deflated 98%) adding: monkey.jpg(in = 7667) (out= 91)(deflated 98%) adding: spacemusic.au(in = 3079) (out= 73)(deflated 97%)
If you already have separate subdirectories for images, audio files and classes, you can combine them into a single jar file: % ls -F audio/ classes/ images/
% jar cvf bundle.jar audio classes images added manifest adding: audio/(in = 0) (out= 0)(stored 0%) adding: audio/1.au(in = 2324) (out= 67)(deflated 97%) adding: audio/2.au(in = 6970) (out= 90)(deflated 98%) adding: audio/3.au(in = 11616) (out= 108)(deflated 99%) adding: audio/spacemusic.au(in = 3079) (out= 73)(deflated 97%) adding: classes/(in = 0) (out= 0)(stored 0%) adding: classes/Animator.class(in = 2266) (out= 66)(deflated 97%) adding: classes/Wave.class(in = 3778) (out= 81)(deflated 97%) adding: images/(in = 0) (out= 0)(stored 0%) adding: images/monkey.jpg(in = 7667) (out= 91)(deflated 98%) adding: images/at_work.gif(in = 6621) (out= 89)(deflated 98%)
% ls -F audio/ bundle.jar classes/ images/
To see the entry names in the jarfile, use the t option: % jar tf bundle.jar META-INF/ META-INF/MANIFEST.MF audio/1.au audio/2.au audio/3.au audio/spacemusic.au classes/Animator.class classes/Wave.class images/monkey.jpg images/at_work.gif
To add an index file to the jar file for speeding up class loading, use the i option. Example:
If you split the inter-dependent classes for a stock trade application into three jar files: main.jar, buy.jar, and sell.jar.
If you specify the Class-path attribute in the main.jar manifest as: Class-Path: buy.jar sell.jar
then you can use the -i option to speed up the class loading time for your application: % jar i main.jar
An INDEX.LIST file is inserted to the META-INF directory. This enables the application class loader to download the specified jar files when it is searching for classes or resources.
The Jar Overview @ http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jarGuide.html
The Jar File Specification @ http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html
The JarIndex Spec @ http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Index
Jar Tutorial @ http://docs.oracle.com/javase/tutorial/deployment/jar/index.html
pack200(1)
SSHPASS(1)                     Sshpass User Manual                    SSHPASS(1)
sshpass [-ffilename|-dnum|-ppassword|-e] [options] command arguments
This manual page documents the sshpass command.
sshpass is a utility designed for running ssh using the mode referred to as "keyboard-interactive" password authentication, but in non-interactive mode.
ssh uses direct TTY access to make sure that the password is indeed issued by an interactive keyboard user. Sshpass runs ssh in a dedicated tty, fooling it into thinking it is getting the password from an interactive user.