neulab/tldr huggingface dataset:
w Undefined weak symbol other than an ELF object symbol. It is not a link failure if the symbol is not defined.
W Defined weak symbol other than an ELF object symbol. This definition will only be used if no regular definitions exist in a link. If multiple weak definitions and no regular definitions exist, one of the weak definitions will be used.
- Mach-O: N_STAB symbol.
? Something unrecognizable.
Because LLVM bitcode files typically contain objects that are not considered to have addresses until they are linked into an executable image or dynamically compiled "just-in-time", llvm-nm does not print an address for any symbol in an LLVM bitcode file, even symbols which are defined in the bitcode file.
-B     Use BSD output format. Alias for --format=bsd.
--debug-syms, -a Show all symbols, even those usually suppressed.
--defined-only Print only symbols defined in this file.
--demangle, -C Demangle symbol names.
--dynamic, -D Display dynamic symbols instead of normal symbols.
--extern-only, -g Print only symbols whose definitions are external; that is, accessible from other files.
--format=<format>, -f Select an output format; format may be sysv, posix, darwin, bsd or just-symbols.  The default is bsd.
--help, -h Print a summary of command-line options and their meanings.
-j     Print just the symbol names. Alias for --format=just-symbols`.
-m     Use Darwin format. Alias for --format=darwin.
--no-demangle Don't demangle symbol names. This is the default.
--no-llvm-bc Disable the LLVM bitcode reader.
--no-sort, -p Show symbols in the order encountered.
--no-weak Don't print weak symbols.
--numeric-sort, -n, -v Sort symbols by address.
--portability, -P Use POSIX.2 output format.  Alias for --format=posix.
--print-armap Print the archive symbol table, in addition to the symbols.
--print-file-name, -A, -o Precede each symbol with the file it came from.
--print-size, -S Show symbol size as well as address (not applicable for Mach-O).
--quiet Suppress 'no symbols' diagnostic.
--radix=<RADIX>, -t Specify the radix of the symbol address(es). Values accepted are d (decimal), x (hexadecimal) and o (octal).
--reverse-sort, -r Sort symbols in reverse order.
--size-sort Sort symbols by size.
--special-syms Do not filter special symbols from the output.
--undefined-only, -u Print only undefined symbols.
--version, -V Display the version of the llvm-nm executable, then exit. Does not stack with other commands.
@<FILE> Read command-line options from response file <FILE>.
MACH-O SPECIFIC OPTIONS --add-dyldinfo Add symbols from the dyldinfo, if they are not already in the symbol table.  This is the default.
--add-inlinedinfo Add symbols from the inlined libraries, TBD file inputs only.
--arch=<arch1[,arch2,...]> Dump the symbols from the specified architecture(s).
--dyldinfo-only Dump only symbols from the dyldinfo.
--no-dyldinfo Do not add any symbols from the dyldinfo.
-s <segment> <section> Dump only symbols from this segment and section name.
-x     Print symbol entry in hex.
â€¢ llvm-nm does not support the full set of arguments that GNU nm does.
llvm-nm exits with an exit code of zero.
llvm-ar(1), llvm-objdump(1), llvm-readelf(1), llvm-readobj(1)
MM2GV(1)                     General Commands Manual                    MM2GV(1)
mm2gv - Matrix Market-DOT converters
mm2gv [ -cluv?  ] [ -Ui ] [ -ooutfile ] [ file ]
mm2gv converts a sparse matrix of the Matrix Market format to a graph in the GV (formerly DOT) format.  If the matrix M is not square, the graph is considered bipartite and the matrix is viewed as a bipartite graph adjacency matrix, with the rows and columns of the matrix specifying the two sets of vertices. Equivalently, the matrix is converted into a symmetric square matrix
0    M MT   0 a block matrix with square blocks of 0's in the upper left and lower right, the upper right block being M and the lower left block being the transpose of M.  This matrix is then viewed as the adjacency matrix of the graph.
For a square matrix, mm2gv uses it directly as an adjacency matrix if its pattern of non-zero entries is symmetric; otherwise, it will treat it as a bipartite graph as with the case of non-square matrices. This behavior can be modified by the -U flag.
-c     This flag causes mm2gv to assign colors to the edges. The matrix element is scaled to the range [0,1] depending on where it lies between the minimum and maximum set matrix values. This scaled value is used as the "wt" attribute of the corresponding edge.  In addition, this scalar value is mapped to an RGB value, which is stored as the edge "color".
-l     If set, mm2gv attaches a label to the graph indicating the base name of the input file, and the number of nodes and edges.
-u     If specified, the graph is assumed to be undirected. By default, the graph generated is directed.
-v     This flag causes mm2gv to store the matrix values as the "len" attribute of the corresponding edge.
-Ubflag Specifies how square matrices are handled. If bflag is 0, a square matrix will always be treated as an adjacency matrix.  If bflag is 1 (the default), a square matrix with a symmetric pattern of non- zero entries will be used as an adjacency matrix; otherwise, it will be used a bipartite graph.  If bflag is 2, a symmetric matrix will be used as an adjacency matrix; otherwise, it will be used a bipartite graph.  If bflag is 3, any input matrix will be treated like a bipartite graph.
-ooutfile Prints output to the file outfile. If not given, mm2gv uses stdout.
OPERANDS The following operand is supported:
file    Name of the file in MatrixMarket format.  If no file operand is specified, the standard input will be used.
Return 0 if there were no problems during conversion; and non-zero if any error occurred.
Yifan Hu <yifanhu@yahoo.com> Emden R. Gansner <erg@graphviz.com>
See http://math.nist.gov/MatrixMarket/ for description of the format and http://www.cise.ufl.edu/research/sparse/matrices/ for a large collection of sparse matrices in this format.
docker-container - Manage containers
Manage containers
-h, --help[=false]      help for container
docker(1), docker-container-attach(1), docker-container-commit(1), docker-container-cp(1), docker-container-create(1), docker-container- diff(1), docker-container-exec(1), docker-container-export(1), docker- container-inspect(1), docker-container-kill(1), docker-container-logs(1), docker-container-ls(1), docker-container-pause(1), docker-container- port(1), docker-container-prune(1), docker-container-rename(1), docker- container-restart(1), docker-container-rm(1), docker-container-run(1), docker-container-start(1), docker-container-stats(1), docker-container- stop(1), docker-container-top(1), docker-container-unpause(1), docker- container-update(1), docker-container-wait(1)
PASTE(1P)                   POSIX Programmer's Manual                  PASTE(1P)
paste — merge corresponding or subsequent lines of files
paste [-s] [-d list] file...
The paste utility shall concatenate the corresponding lines of the given input files, and write the resulting lines to standard output.
The default operation of paste shall concatenate the corresponding lines of the input files. The <newline> of every line except the line from the last input file shall be replaced with a <tab>.
If an end-of-file condition is detected on one or more input files, but not all input files, paste shall behave as though empty lines were read from the files on which end-of-file was detected, unless the -s option is specified.
The paste utility shall conform to the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines.
-d list   Unless a <backslash> character appears in list, each character in list is an element specifying a delimiter character. If a <backslash> character appears in list, the <backslash> character and one or more characters following it are an element specifying a delimiter character as described below. These elements specify one or more delimiters to use, instead of the default <tab>, to replace the <newline> of the input lines. The elements in list shall be used circularly; that is, when the list is exhausted the first element from the list is reused. When the -s option is specified:
*  The last <newline> in a file shall not be modified.
*  The delimiter shall be reset to the first element of list after each file operand is processed.
When the -s option is not specified:
*  The <newline> characters in the file specified by the last file operand shall not be modified.
*  The delimiter shall be reset to the first element of list each time a line is processed from each file.
If a <backslash> character appears in list, it and the character following it shall be used to represent the following delimiter characters:
\n    <newline>.
\t    <tab>.
\\    <backslash> character.
\0    Empty string (not a null character). If '\0' is immediately followed by the character 'x', the character 'X', or any character defined by the LC_CTYPE digit keyword (see the Base Definitions volume of POSIX.1‐2017, Chapter 7, Locale), the results are unspecified.
If any other characters follow the <backslash>, the results are unspecified.
-s        Concatenate all of the lines from each input file into one line of output per file, in command line order. The <newline> of every line except the last line in each input file shall be replaced with a <tab>, unless otherwise specified by the -d option. If an input file is empty, the output line corresponding to that file shall consist of only a <newline> character.
file      A pathname of an input file. If '-' is specified for one or more of the files, the standard input shall be used; the standard input shall be read one line at a time, circularly, for each instance of '-'.  Implementations shall support pasting of at least 12 file operands.
The standard input shall be used only if one or more file operands is '-'.  See the INPUT FILES section.
The following environment variables shall affect the execution of paste:
LANG      Provide a default value for the internationalization variables that are unset or null. (See the Base Definitions volume of POSIX.1‐2017, Section 8.2, Internationalization Variables the precedence of internationalization variables used to determine the values of locale categories.)
Concatenated lines of input files shall be separated by the <tab> (or other characters under the control of the -d option) and terminated by a <newline>.
If one or more input files cannot be opened when the -s option is not specified, a diagnostic message shall be written to standard error, but no output is written to standard output. If the -s option is specified, the paste utility shall provide the default behavior described in Section 1.4, Utility Description Defaults.
When the escape sequences of the list option-argument are used in a shell script, they must be quoted; otherwise, the shell treats the <backslash> as a special character.
Conforming applications should only use the specific <backslash>-escaped delimiters presented in this volume of POSIX.1‐2017. Historical implementations treat '\x', where 'x' is not in this list, as 'x', but future implementations are free to expand this list to recognize other common escapes similar to those accepted by printf and other standard utilities.
Most of the standard utilities work on text files. The cut utility can be used to turn files with arbitrary line lengths into a set of text files containing the same data. The paste utility can be used to create (or recreate) files with arbitrary line lengths. For example, if file contains long lines:
creates file1 (a text file) with lines no longer than 500 bytes (plus the <newline>) and file2 that contains the remainder of the data from file. Note that file2 is not a text file if there are lines in file that are longer than 500 + {LINE_MAX} bytes. The original file can be recreated from file1 and file2 using the command:
The commands:
paste -d "\0" ... paste -d "" ...
are not necessarily equivalent; the latter is not specified by this volume of POSIX.1‐2017 and may result in an error. The construct '\0' is used to mean ``no separator'' because historical versions of paste did not follow the syntax guidelines, and the command:
paste -d"" ...
could not be handled properly by getopt().
1. Write out a directory in four columns:
ls | paste - - - -
2. Combine pairs of lines from a file into single lines:
paste -s -d "\t\n" file
Section 1.4, Utility Description Defaults, cut, grep, pr
The Base Definitions volume of POSIX.1‐2017, Chapter 7, Locale, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines
@INDOT_U@NAMED(@SYS_OPS_EXT_U@)       LOCAL      @INDOT_U@NAMED(@SYS_OPS_EXT_U@)
@INDOT@named — Internet domain name server (DNS)
@INDOT@NAMED [-d debuglevel] [-p port#] [-(b|c) config_file] [-f -q -r] [-w directory] [config_file]
Named is the Internet domain name server.  See RFC's 1033, 1034, and 1035 for more information on the Internet name-domain system.  Without any arguments, named will read the default configuration file /etc/named.conf, read any initial data, and listen for queries.  A config_file argument given at the end of the command line will override any config_file specified by using the “-b” or “-c” flags.
NOTE: Several of named's options, and much more of its behaviour, can be controlled in the configuration file.  Please refer to the configuration file guide included with this BIND distribution for further information.
-d debuglevel Print debugging information.  The debuglevel is a number determines the level of messages printed.  If negative, debuglevel is set to “1”.
NOTE: The new debugging framework is considerably more sophisticated than it was in older versions of @INDOT@NAMED. The configuration file's “logging” statement allows for multiple, distinct levels of debugging for each of a large set of categories of events (such as queries, transfers in or out, etc.).  Please refer to the configuration file guide included with this BIND distribution for further information about these extensive new capabilities.
-p port#    Use the specified remote port number; this is the port number to which @INDOT@NAMED will send queries.  The default value is the standard port number, i.e., the port number returned by getservbyname(@LIB_NETWORK_EXT@) for service “domain”.
NOTE: Previously, the syntax “-p port#[/localport#]” was supported; the first port was that used when contacting remote servers, and the second one was the service port bound by the local instance of @INDOT_U@NAMED.  The current usage is equivalent to the old usage without the localport# specified; this functionality can be specified with the “listen-on” clause of the configuration file's “options” statement.
-(b|c) config_file Use an alternate config_file; this argument is overridden by any config_file which is specified at the end of the command line.  The default value is /etc/named.conf.
-f          Run this process in the foreground; don't fork(@SYSCALL_EXT@) and daemonize.  (The default is to daemonize.)
-q          Trace all incoming queries if @INDOT_U@NAMED has been compiled with QRYLOG defined.
NOTE: This option is deprecated in favor of the “queries” logging category of the configuration file's “logging” statement; for more information, please refer to the configuration file guide included with this distribution of BIND.
-r          Turns recursion off in the server.  Answers can come only from local (primary or secondary) zones.  This can be used on root servers.  The default is to use recursion.
NOTE: This option can be overridden by and is deprecated in favor of the “recursion” clause of the configuration file's “options” statement.
-w directory Sets the working directory of the server.  The “directory” clause of the configuration file's “options” statement overrides any value specified on the command line.  The default working directory is the current directory (“.”).
Any additional argument is taken as the name of the configuration file, for compatibility with older implementations; as noted above, this argument overrides any config_file specified by the use of the “-b” or “-c” flags. If no further argument is given, then the default configuration file is used (/etc/named.conf).
Master File Format The master file consists of control information and a list of resource records for objects in the zone of the forms:
$INCLUDE <filename> <opt_domain> $ORIGIN <domain> <domain> <opt_ttl> <opt_class> <type> <resource_record_data>
domain        is “.” for root, “@” for the current origin, or a standard domain name. If domain is a standard domain name that does not end with “.”, the current origin is appended to the domain. Domain names ending with “.” are unmodified.
opt_domain    This field is used to define an origin for the data in an included file.  It is equivalent to placing an $ORIGIN statement before the first line of the included file.  The field is optional.  Neither the opt_domain field nor $ORIGIN statements in the included file modify the current origin for this file.
opt_ttl       An optional integer number for the time-to-live field.  It defaults to zero, meaning the minimum value specified in the SOA record for the zone.
opt_class     The object address type; currently only one type is supported, IN, for objects connected to the DARPA Internet.
type          This field contains one of the following tokens; the data expected in the resource_record_data field is in parentheses:
A          a host address (dotted-quad IP address)
NS         an authoritative name server (domain)
MX         a mail exchanger (domain), preceded by a preference value (0..32767), with lower numeric values representing higher logical preferences.
CNAME      the canonical name for an alias (domain)
SOA        marks the start of a zone of authority (domain of originating host, domain address of maintainer, a serial number and the following parameters in seconds: refresh, retry, expire and minimum TTL (see RFC 883)).
NULL       a null resource record (no format or data)
RP         a Responsible Person for some domain name (mailbox, TXT-referral)
PTR        a domain name pointer (domain)
HINFO      host information (cpu_type OS_type)
Resource records normally end at the end of a line, but may be continued across lines between opening and closing parentheses.  Comments are introduced by semicolons and continue to the end of the line.
NOTE: There are other resource record types not shown here.  You should consult the BIND Operations Guide (“BOG”) for the complete list.  Some resource record types may have been standardized in newer RFC's but not yet implemented in this version of BIND.
SOA Record Format Each master zone file should begin with an SOA record for the zone.  An example SOA record is as follows:
@       IN      SOA     ucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. ( 1989020501      ; serial 10800   ; refresh 3600    ; retry 3600000 ; expire 86400 ) ; minimum
The SOA specifies a serial number, which should be changed each time the master file is changed.  Note that the serial number can be given as a dotted number, but this is a very unwise thing to do since the translation to normal integers is via concatenation rather than multiplication and addition.  You can spell out the year, month, day of month, and 0..99 version number and still fit inside the unsigned 32-bit size of this field. (It's true that we will have to rethink this strategy in the year 4294, but we're not worried about it.)
Secondary servers check the serial number at intervals specified by the refresh time in seconds; if the serial number changes, a zone transfer will be done to load the new data.  If a master server cannot be contacted when a refresh is due, the retry time specifies the interval at which refreshes should be attempted.  If a master server cannot be contacted within the interval given by the expire time, all data from the zone is discarded by secondary servers.  The minimum value is the time-to-live (“TTL”) used by records in the file with no explicit time-to-live value.
The boot file directives “domain” and “suffixes” have been obsoleted by a more useful, resolver-based implementation of suffixing for partially- qualified domain names.  The prior mechanisms could fail under a number of situations, especially when then local nameserver did not have complete information.
The following signals have the specified effect when sent to the server process using the kill(@CMD_EXT@) command:
SIGHUP    Causes server to read named.boot and reload the database.  If the server is built with the FORCED_RELOAD compile-time option, then SIGHUP will also cause the server to check the serial number on all secondary zones; normally, the serial numbers are only checked at the SOA-specified intervals.
SIGINT    Dumps the current data base and cache to “/var/tmp/named_dump.db” or the value of _PATH_DUMPFILE.
SIGILL    Dumps statistics data into named.stats if the server is compiled with -DSTATS.  Statistics data is appended to the file.
SIGSYS    Dumps the profiling data in /var/tmp if the server is compiled with profiling (server forks, chdirs and exits).
SIGTERM   Dumps the primary and secondary database files.  Used to save modified data on shutdown if the server is compiled with dynamic updating enabled.
SIGUSR1   Turns on debugging; each SIGUSR1 increments debug level.  (SIGEMT on older systems without SIGUSR1.)
SIGUSR2   Turns off debugging completely.  (SIGFPE on older systems without SIGUSR2.)
SIGWINCH  Toggles logging of all incoming queries via syslog(@SYS_OPS_EXT@) (requires server to have been built with the QRYLOG option).
/etc/named.conf                             default name server configuration file /var/run/named.pid (_PATH_PIDFILE)          the process id /var/tmp/named_dump.db (_PATH_DUMPFILE)     dump of the name server database /var/tmp/named.run (file: _PATH_DEBUG)      debug output /var/tmp/named.stats (file: _PATH_STATS)    nameserver statistics data
gethostbyname(@LIB_NETWORK_EXT@), hostname(@DESC_EXT@), kill(@CMD_EXT@), resolver(@LIB_NETWORK_EXT@), resolver(@FORMAT_EXT@), signal(@SYSCALL_EXT@), RFC 882, RFC 883, RFC 973, RFC 974, RFC 1033, RFC 1034, RFC 1035, RFC 1123, “Name Server Operations Guide for BIND”
GITLAB(1)                                                              GITLAB(1)
gitlab - command line interface to gitlab
gitlab command
gitlab is a command line interface to gitlab based on the gem gitlab.  It requires to set a few environment variables (see configuration).
For a complete list of supported CLI commands, see:
<http://www.rubydoc.info/gems/gitlab/Gitlab/Client>
Any of those methods can be called as a command by passing the parameters of the commands as parameters of gitlab.
A few environment variables needs to be set:
export GITLAB_API_ENDPOINT=https://gitlab.yourcompany.com/api/v4
export GITLAB_API_PRIVATE_TOKEN=<your private token from /profile/account>
The variable GITLAB_API_HTTPARTY_OPTIONS is optional. It can be used to set any HTTParty option you may need using YAML hash syntax. For example SSL verification can be disabled with:
export GITLAB_API_HTTPARTY_OPTIONS="{verify: false}"
To list users: gitlab users
To get current user: gitlab user
The result can be filtered: gitlab user --only=id,username
gitlab user --except=email,bio
• gem documentation <http://www.rubydoc.info/gems/gitlab/Gitlab/Client>
• /usr/share/doc/ruby-gitlab/README.md.gz
Sophie Brun <sophie@freexian.com>
sbatch(1)                        Slurm Commands                        sbatch(1)
sbatch - Submit a batch script to Slurm.
sbatch [OPTIONS(0)...] [ : [OPTIONS(N)...]] script(0) [args(0)...]
Option(s) define multiple jobs in a co-scheduled heterogeneous job.  For more details about heterogeneous jobs see the document https://slurm.schedmd.com/heterogeneous_jobs.html
sbatch submits a batch script to Slurm.  The batch script may be given to sbatch through a file name on the command line, or if no file name is specified, sbatch will read in a script from standard input. The batch script may contain options preceded with "#SBATCH" before any executable commands in the script.  sbatch will stop processing further #SBATCH directives once the first non-comment non-whitespace line has been reached in the script.
sbatch exits immediately after the script is successfully transferred to the Slurm controller and assigned a Slurm job ID.  The batch script is not necessarily granted resources immediately, it may sit in the queue of pending jobs for some time before its required resources become available.
By default both standard output and standard error are directed to a file of the name "slurm-%j.out", where the "%j" is replaced with the job allocation number. The file will be generated on the first node of the job allocation.  Other than the batch script itself, Slurm does no movement of user files.
When the job allocation is finally granted for the batch script, Slurm runs a single copy of the batch script on the first node in the set of allocated nodes.
The following document describes the influence of various options on the allocation of cpus to jobs and tasks. https://slurm.schedmd.com/cpu_management.html
sbatch will return 0 on success or error code on failure.
The batch script is resolved in the following order:
1. If script starts with ".", then path is constructed as: current working directory / script 2. If script starts with a "/", then path is considered absolute. 3. If script is in current working directory. 4. If script can be resolved through PATH. See path_resolution(7).
Current working directory is the calling process working directory unless the --chdir argument is passed, which will override the current working directory.
-a, --array=<indexes> Submit a job array, multiple jobs to be executed with identical parameters.  The indexes specification identifies what array index values should be used. Multiple values may be specified using a comma separated list and/or a range of values with a "-" separator. For example, "--array=0-15" or "--array=0,6,16-32".  A step function can also be specified with a suffix containing a colon and number. For example, "--array=0-15:4" is equivalent to "--array=0,4,8,12".  A maximum number of simultaneously running tasks from the job array may be specified using a "%" separator. For example "--array=0-15%4" will limit the number of simultaneously running tasks from this job array to 4.  The minimum index value is 0.  the maximum value is one less than the configuration parameter MaxArraySize.  NOTE: currently, federated job arrays only run on the local cluster.
-A, --account=<account> Charge resources used by this job to specified account.  The account is an arbitrary string. The account name may be changed after job submission using the scontrol command.
--acctg-freq Define the job accounting and profiling sampling intervals.  This can be used to override the JobAcctGatherFrequency parameter in Slurm's configuration file, slurm.conf.  The supported format is as follows:
--acctg-freq=<datatype>=<interval> where <datatype>=<interval> specifies the task sampling interval for the jobacct_gather plugin or a sampling interval for a profiling type by the acct_gather_profile plugin. Multiple, comma-separated <datatype>=<interval> intervals may be specified. Supported datatypes are as follows:
task=<interval> where <interval> is the task sampling interval in seconds for the jobacct_gather plugins and for task profiling by the acct_gather_profile plugin.  NOTE: This frequency is used to monitor memory usage. If memory limits are enforced the highest frequency a user can request is what is configured in the slurm.conf file.  They can not turn it off (=0) either.
energy=<interval> where <interval> is the sampling interval in seconds for energy profiling using the acct_gather_energy plugin
network=<interval> where <interval> is the sampling interval in seconds for infiniband profiling using the acct_gather_interconnect plugin.
filesystem=<interval> where <interval> is the sampling interval in seconds for filesystem profiling using the acct_gather_filesystem plugin.
The default value for the task sampling interval is 30 seconds. The default value for all other intervals is 0.  An interval of 0 disables sampling of the specified type.  If the task sampling interval is 0, accounting information is collected only at job termination (reducing Slurm interference with the job). Smaller (non-zero) values have a greater impact upon job performance, but a value of 30 seconds is not likely to be noticeable for applications having less than 10,000 tasks.
-B --extra-node-info=<sockets[:cores[:threads]]> Restrict node selection to nodes with at least the specified number of sockets, cores per socket and/or threads per core. NOTE: These options do not specify the resource allocation size. Each value specified is considered a minimum.  An asterisk (*) can be used as a placeholder indicating that all available resources of that type are to be utilized. Values can also be specified as min-max. The individual levels can also be specified in separate options if desired: --sockets-per-node=<sockets> --cores-per-socket=<cores> --threads-per-core=<threads> If task/affinity plugin is enabled, then specifying an allocation in this manner also results in subsequently launched tasks being bound to threads if the -B option specifies a thread count, otherwise an option of cores if a core count is specified, otherwise an option of sockets.  If SelectType is configured to select/cons_res, it must have a parameter of CR_Core, CR_Core_Memory, CR_Socket, or CR_Socket_Memory for this option to be honored.  If not specified, the scontrol show job will display 'ReqS:C:T=*:*:*'. This option applies to job allocations.  NOTE: This option is mutually exclusive with --hint, --threads-per-core and --ntasks-per-core.
--batch=<list> Nodes can have features assigned to them by the Slurm administrator.  Users can specify which of these features are required by their batch script using this options.  For example a job's allocation may include both Intel Haswell and KNL nodes with features "haswell" and "knl" respectively.  On such a configuration the batch script would normally benefit by executing on a faster Haswell node.  This would be specified using the option "--batch=haswell".  The specification can include AND and OR operators using the ampersand and vertical bar separators. For example: "--batch=haswell|broadwell" or "--batch=haswell|big_memory".  The --batch argument must be a subset of the job's --constraint=<list> argument (i.e. the job can not request only KNL nodes, but require the script to execute on a Haswell node).  If the request can not be satisfied from the resources allocated to the job, the batch script will execute on the first node of the job allocation.
--bb=<spec> Burst buffer specification. The form of the specification is system dependent.  Note the burst buffer may not be accessible from a login node, but require that salloc spawn a shell on one of its allocated compute nodes.
--bbf=<file_name> Path of file containing burst buffer specification.  The form of the specification is system dependent.  These burst buffer directives will be inserted into the submitted batch script.
-b, --begin=<time> Submit the batch script to the Slurm controller immediately, like normal, but tell the controller to defer the allocation of the job until the specified time.
Time may be of the form HH:MM:SS to run a job at a specific time of day (seconds are optional).  (If that time is already past, the next day is assumed.)  You may also specify midnight, noon, fika (3 PM) or teatime (4 PM) 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 specifying a date of the form MMDDYY or MM/DD/YY YYYY-MM-DD. Combine date and time using the following format YYYY-MM-DD[THH:MM[:SS]]. You can also give times like now + count time-units, where the time-units can be seconds (default), minutes, hours, days, or weeks and you can tell Slurm to run the job today with the keyword today and to run the job tomorrow with the keyword tomorrow.  The value may be changed after job submission using the scontrol command.  For example: --begin=16:00 --begin=now+1hour --begin=now+60           (seconds by default) --begin=2010-01-20T12:34:00
Notes on date/time specifications: - Although the 'seconds' field of the HH:MM:SS time specification is allowed by the code, note that the poll time of the Slurm scheduler is not precise enough to guarantee dispatch of the job on the exact second.  The job will be eligible to start on the next poll following the specified time. The exact poll interval depends on the Slurm scheduler (e.g., 60 seconds with the default sched/builtin). - If no time (HH:MM:SS) is specified, the default is (00:00:00). - If a date is specified without a year (e.g., MM/DD) then the current year is assumed, unless the combination of MM/DD and HH:MM:SS has already passed for that year, in which case the next year is used.
--cluster-constraint=[!]<list> Specifies features that a federated cluster must have to have a sibling job submitted to it. Slurm will attempt to submit a sibling job to a cluster if it has at least one of the specified features. If the "!" option is included, Slurm will attempt to submit a sibling job to a cluster that has none of the specified features.
--comment=<string> An arbitrary comment enclosed in double quotes if using spaces or some special characters.
-C, --constraint=<list> Nodes can have features assigned to them by the Slurm administrator.  Users can specify which of these features are required by their job using the constraint option.  Only nodes having features matching the job constraints will be used to satisfy the request.  Multiple constraints may be specified with AND, OR, matching OR, resource counts, etc. (some operators are not supported on all system types).  Supported constraint options include:
Single Name Only nodes which have the specified feature will be used. For example, --constraint="intel"
Node Count A request can specify the number of nodes needed with some feature by appending an asterisk and count after the feature name.  For example, --nodes=16 --constraint="graphics*4 ..."  indicates that the job requires 16 nodes and that at least four of those nodes must have the feature "graphics."
AND    If only nodes with all of specified features will be used. The ampersand is used for an AND operator.  For example, --constraint="intel&gpu"
OR     If only nodes with at least one of specified features will be used.  The vertical bar is used for an OR operator.  For example, --constraint="intel|amd"
Matching OR If only one of a set of possible options should be used for all allocated nodes, then use the OR operator and enclose the options within square brackets.  For example, --constraint="[rack1|rack2|rack3|rack4]" might be used to specify that all nodes must be allocated on a single rack of the cluster, but any of those four racks can be used.
Multiple Counts Specific counts of multiple resources may be specified by using the AND operator and enclosing the options within square brackets.  For example, --constraint="[rack1*2&rack2*4]" might be used to specify that two nodes must be allocated from nodes with the feature of "rack1" and four nodes must be allocated from nodes with the feature "rack2".
NOTE: This construct does not support multiple Intel KNL NUMA or MCDRAM modes. For example, while --constraint="[(knl&quad)*2&(knl&hemi)*4]" is not supported, --constraint="[haswell*2&(knl&hemi)*4]" is supported.  Specification of multiple KNL modes requires the use of a heterogeneous job.
Brackets Brackets can be used to indicate that you are looking for a set of nodes with the different requirements contained within the brackets. For example, --constraint="[(rack1|rack2)*1&(rack3)*2]" will get you one node with either the "rack1" or "rack2" features and two nodes with the "rack3" feature.  The same request without the brackets will try to find a single node that meets those requirements.
Parenthesis Parenthesis can be used to group like node features together. For example, --constraint="[(knl&snc4&flat)*4&haswell*1]" might be used to specify that four nodes with the features "knl", "snc4" and "flat" plus one node with the feature "haswell" are required. All options within parenthesis should be grouped with AND (e.g. "&") operands.
--contiguous If set, then the allocated nodes must form a contiguous set.
NOTE: If SelectPlugin=cons_res this option won't be honored with the topology/tree or topology/3d_torus plugins, both of which can modify the node ordering.
--cores-per-socket=<cores> Restrict node selection to nodes with at least the specified number of cores per socket.  See additional information under -B option above when task/affinity plugin is enabled.
--cpu-freq =<p1[-p2[:p3]]>
Request that job steps initiated by srun commands inside this sbatch script be run at some requested frequency if possible, on the CPUs selected for the step on the compute node(s).
p1 can be  [#### | low | medium | high | highm1] which will set the frequency scaling_speed to the corresponding value, and set the frequency scaling_governor to UserSpace. See below for definition of the values.
p1 can be [Conservative | OnDemand | Performance | PowerSave] which will set the scaling_governor to the corresponding value. The governor has to be in the list set by the slurm.conf option CpuFreqGovernors.
When p2 is present, p1 will be the minimum scaling frequency and p2 will be the maximum scaling frequency.
p2 can be  [#### | medium | high | highm1] p2 must be greater than p1.
p3 can be [Conservative | OnDemand | Performance | PowerSave | UserSpace] which will set the governor to the corresponding value.
If p3 is UserSpace, the frequency scaling_speed will be set by a power or energy aware scheduling strategy to a value between p1 and p2 that lets the job run within the site's power goal. The job may be delayed if p1 is higher than a frequency that allows the job to run within the goal.
If the current frequency is < min, it will be set to min. Likewise, if the current frequency is > max, it will be set to max.
Acceptable values at present include:
####          frequency in kilohertz
Low           the lowest available frequency
High          the highest available frequency
HighM1        (high minus one) will select the next highest available frequency
Medium        attempts to set a frequency in the middle of the available range
Conservative  attempts to use the Conservative CPU governor
OnDemand      attempts to use the OnDemand CPU governor (the default value)
Performance   attempts to use the Performance CPU governor
PowerSave     attempts to use the PowerSave CPU governor
UserSpace     attempts to use the UserSpace CPU governor
The following informational environment variable is set in the job step when --cpu-freq option is requested. SLURM_CPU_FREQ_REQ
This environment variable can also be used to supply the value for the CPU frequency request if it is set when the 'srun' command is issued.  The --cpu-freq on the command line will override the environment variable value.  The form on the environment variable is the same as the command line.  See the ENVIRONMENT VARIABLES section for a description of the SLURM_CPU_FREQ_REQ variable.
NOTE: This parameter is treated as a request, not a requirement. If the job step's node does not support setting the CPU frequency, or the requested value is outside the bounds of the legal frequencies, an error is logged, but the job step is allowed to continue.
NOTE: Setting the frequency for just the CPUs of the job step implies that the tasks are confined to those CPUs.  If task confinement (i.e., TaskPlugin=task/affinity or TaskPlugin=task/cgroup with the "ConstrainCores" option) is not configured, this parameter is ignored.
NOTE: When the step completes, the frequency and governor of each selected CPU is reset to the previous values.
NOTE: When submitting jobs with  the --cpu-freq option with linuxproc as the ProctrackType can cause jobs to run too quickly before Accounting is able to poll for job information. As a result not all of accounting information will be present.
--cpus-per-gpu=<ncpus> Advise Slurm that ensuing job steps will require ncpus processors per allocated GPU.  Not compatible with the --cpus-per-task option.
-c, --cpus-per-task=<ncpus> Advise the Slurm controller that ensuing job steps will require ncpus number of processors per task.  Without this option, the controller will just try to allocate one processor per task.
For instance, consider an application that has 4 tasks, each requiring 3 processors.  If our cluster is comprised of quad-processors nodes and we simply ask for 12 processors, the controller might give us only 3 nodes.  However, by using the --cpus-per-task=3 options, the controller knows that each task requires 3 processors on the same node, and the controller will grant an allocation of 4 nodes, one for each of the 4 tasks.
--deadline=<OPT> remove the job if no ending is possible before this deadline (start > (deadline - time[-min])).  Default is no deadline.  Valid time formats are: HH:MM[:SS] [AM|PM] MMDD[YY] or MM/DD[/YY] or MM.DD[.YY] MM/DD[/YY]-HH:MM[:SS] YYYY-MM-DD[THH:MM[:SS]]] now[+count[seconds(default)|minutes|hours|days|weeks]]
--delay-boot=<minutes> Do not reboot nodes in order to satisfied this job's feature specification if the job has been eligible to run for less than this time period.  If the job has waited for less than the specified period, it will use only nodes which already have the specified features.  The argument is in units of minutes.  A default value may be set by a system administrator using the delay_boot option of the SchedulerParameters configuration parameter in the slurm.conf file, otherwise the default value is zero (no delay).
-d, --dependency=<dependency_list> Defer the start of this job until the specified dependencies have been satisfied completed.  <dependency_list> is of the form <type:job_id[:job_id][,type:job_id[:job_id]]> or <type:job_id[:job_id][?type:job_id[:job_id]]>.  All dependencies must be satisfied if the "," separator is used.  Any dependency may be satisfied if the "?" separator is used.  Only one separator may be used.  Many jobs can share the same dependency and these jobs may even belong to different  users. The  value may be changed after job submission using the scontrol command. Dependencies on remote jobs are allowed in a federation.  Once a job dependency fails due to the termination state of a preceding job, the dependent job will never be run, even if the preceding job is requeued and has a different termination state in a subsequent execution.
after:job_id[[+time][:jobid[+time]...]] After the specified jobs start or are cancelled and 'time' in minutes from job start or cancellation happens, this job can begin execution. If no 'time' is given then there is no delay after start or cancellation.
afterany:job_id[:jobid...] This job can begin execution after the specified jobs have terminated.
afterburstbuffer:job_id[:jobid...] This job can begin execution after the specified jobs have terminated and any associated burst buffer stage out operations have completed.
aftercorr:job_id[:jobid...] A task of this job array can begin execution after the corresponding task ID in the specified job has completed successfully (ran to completion with an exit code of zero).
afternotok:job_id[:jobid...] This job can begin execution after the specified jobs have terminated in some failed state (non-zero exit code, node failure, timed out, etc).
afterok:job_id[:jobid...] This job can begin execution after the specified jobs have successfully executed (ran to completion with an exit code of zero).
expand:job_id Resources allocated to this job should be used to expand the specified job.  The job to expand must share the same QOS (Quality of Service) and partition.  Gang scheduling of resources in the partition is also not supported.  "expand" is not allowed for jobs that didn't originate on the same cluster as the submitted job.
singleton This job can begin execution after any previously launched jobs sharing the same job name and user have terminated. In other words, only one job by that name and owned by that user can be running or suspended at any point in time.  In a federation, a singleton dependency must be fulfilled on all clusters unless DependencyParameters=disable_remote_singleton is used in slurm.conf.
-D, --chdir=<directory> Set the working directory of the batch script to directory before it is executed. The path can be specified as full path or relative path to the directory where the command is executed.
-e, --error=<filename pattern> Instruct Slurm to connect the batch script's standard error directly to the file name specified in the "filename pattern".  By default both standard output and standard error are directed to the same file.  For job arrays, the default file name is "slurm-%A_%a.out", "%A" is replaced by the job ID and "%a" with the array index.  For other jobs, the default file name is "slurm-%j.out", where the "%j" is replaced by the job ID.  See the filename pattern section below for filename specification options.
--exclusive[=user|mcs] The job allocation can not share nodes with other running jobs (or just other users with the "=user" option or with the "=mcs" option).  The default shared/exclusive behavior depends on system configuration and the partition's OverSubscribe option takes precedence over the job's option.
--export=<[ALL,]environment variables|ALL|NONE> Identify which environment variables from the submission environment are propagated to the launched application. Note that SLURM_* variables are always propagated.
--export=ALL Default mode if --export is not specified. All of the users environment will be loaded (either from callers environment or clean environment if --get-user-env is specified).
--export=NONE Only SLURM_* variables from the user environment will be defined. User must use absolute path to the binary to be executed that will define the environment.  User can not specify explicit environment variables with NONE. --get-user-env will be ignored. This option is particularly important for jobs that are submitted on one cluster and execute on a different cluster (e.g. with different paths).  To avoid steps inheriting environment export settings (e.g. NONE) from sbatch command, the environment variable SLURM_EXPORT_ENV should be set to ALL in the job script.
--export=<[ALL,]environment variables> Exports all SLURM_* environment variables along with explicitly defined variables. Multiple environment variable names should be comma separated.  Environment variable names may be specified to propagate the current value (e.g. "--export=EDITOR") or specific values may be exported (e.g. "--export=EDITOR=/bin/emacs"). If ALL is specified, then all user environment variables will be loaded and will take precedence over any explicitly given environment variables.
Example: --export=EDITOR,ARG1=test In this example, the propagated environment will only contain the variable EDITOR from the user's environment, SLURM_* environment variables, and ARG1=test.
Example: --export=ALL,EDITOR=/bin/emacs There are two possible outcomes for this example. If the caller has the EDITOR environment variable defined, then the job's environment will inherit the variable from the caller's environment.  If the caller doesn't have an environment variable defined for EDITOR, then the job's environment will use the value given by --export.
--export-file=<filename | fd> If a number between 3 and OPEN_MAX is specified as the argument to this option, a readable file descriptor will be assumed (STDIN and STDOUT are not supported as valid arguments).  Otherwise a filename is assumed.  Export environment variables defined in <filename> or read from <fd> to the job's execution environment. The content is one or more environment variable definitions of the form NAME=value, each separated by a null character.  This allows the use of special characters in environment definitions.
-F, --nodefile=<node file> Much like --nodelist, but the list is contained in a file of name node file.  The node names of the list may also span multiple lines in the file.    Duplicate node names in the file will be ignored.  The order of the node names in the list is not important; the node names will be sorted by Slurm.