neulab/tldr huggingface dataset:
-s SCRIPT-FILE Load Scheme source from SCRIPT-FILE and execute as a script.  Note that in many cases it is not necessary to use -s; one may invoke guile simply as guile SCRIPT-FILE ARG...
-ds    Carry out -s SCRIPT at this point in the option sequence.  Note that this argument must be used in conjunction with -s.
--debug Start guile with the debugging VM.  By default, debugging is on when guile is invoked interactively; it is off otherwise.
--no-debug Start guile without the debugging VM, even if guile is being run interactively.
--auto-compile Compile source files automatically (default behavior).
--no-auto-compile Disable automatic source file compilation.
--listen[=P] Listen on a port or socket for remote REPL connections.  See the manual for more details.
--use-srfi=N,M... Load SRFI extensions N, M, etc.  For example, --use-srfi=8,13.
-x EXTENSION Add EXTENSION to the guile load extension list.
-h, --help Describe command-line options and exit.
-v, --version Display guile version and exit.
-q     In interactive mode, suppress loading the user's initialization file, ~/.guile.
GUILE_LOAD_PATH If $GUILE_LOAD_PATH is set before guile is started, its value is used to augment the path to search for Scheme files when loading. It should be a colon-separated list of directories, which will be prefixed to the default %load-path.
GUILE_LOAD_COMPILED_PATH If $GUILE_LOAD_COMPILED_PATH is set before guile is started, its value is used to augment the path to search for compiled Scheme files (.go files) when loading.  It should be a colon-separated list of directories, which will be prefixed to the default %load- compiled-path.
~/.guile A Guile script that is executed before any other processing occurs.  For example, the following .guile activates guile's readline interface:
(use-modules (ice-9 readline)) (activate-readline)
The full documentation for Guile is maintained as a Texinfo manual.  If the info and guile programs are properly installed at your site, the command
info guile
http://www.schemers.org provides a general introduction to the Scheme language.
There is a mailing list, bug-guile@gnu.org, for reporting Guile bugs and fixes.  But before reporting something as a bug, please try to be sure that it really is a bug, not a misunderstanding or a deliberate feature. We ask you to read the section ``Reporting Bugs'' in the Guile reference manual (or Info system) for hints on how and when to report bugs.  Also, include the version number of the Guile you are running in every bug report that you send in.  Bugs tend actually to get fixed if they can be isolated, so it is in your interest to report them in such a way that they can be easily reproduced.
Copyright (C) 2010, 2011 Free Software Foundation, Inc.
Robert Merkel <rgmerk@mira.net> wrote this manpage.  Rob Browning <rlb@cs.utexas.edu> has added to it.
guile is GNU software.  Guile is originally based on Aubrey Jaffer's SCM interpreter, and is the work of many individuals.
TASKSET(1)                        User Commands                       TASKSET(1)
taskset - set or retrieve a process's CPU affinity
taskset [options] mask command [argument...]
taskset [options] -p [mask] pid
The taskset command is used to set or retrieve the CPU affinity of a running process given its pid, or to launch a new command with a given CPU affinity. CPU affinity is a scheduler property that "bonds" a process to a given set of CPUs on the system. The Linux scheduler will honor the given CPU affinity and the process will not run on any other CPUs. Note that the Linux scheduler also supports natural CPU affinity: the scheduler attempts to keep processes on the same CPU as long as practical for performance reasons. Therefore, forcing a specific CPU affinity is useful only in certain applications.
The CPU affinity is represented as a bitmask, with the lowest order bit corresponding to the first logical CPU and the highest order bit corresponding to the last logical CPU. Not all CPUs may exist on a given system but a mask may specify more CPUs than are present. A retrieved mask will reflect only the bits that correspond to CPUs physically on the system. If an invalid mask is given (i.e., one that corresponds to no valid CPUs on the current system) an error is returned. The masks may be specified in hexadecimal (with or without a leading "0x"), or as a CPU list with the --cpu-list option. For example,
0x00000001 is processor #0,
0x00000003 is processors #0 and #1,
0xFFFFFFFF is processors #0 through #31,
32 is processors #1, #4, and #5,
--cpu-list 0-2,6 is processors #0, #1, #2, and #6.
--cpu-list 0-10:2 is processors #0, #2, #4, #6, #8 and #10. The suffix ":N" specifies stride in the range, for example 0-10:3 is interpreted as 0,3,6,9 list.
When taskset returns, it is guaranteed that the given program has been scheduled to a legal CPU.
-a, --all-tasks Set or retrieve the CPU affinity of all the tasks (threads) for a given PID.
-c, --cpu-list Interpret mask as numerical list of processors instead of a bitmask. Numbers are separated by commas and may include ranges. For example: 0,5,8-11.
-p, --pid Operate on an existing PID and do not launch a new task.
The default behavior is to run a new command with a given affinity mask: taskset mask command [arguments]
You can also retrieve the CPU affinity of an existing task: taskset -p pid
Or set it: taskset -p mask pid
A user can change the CPU affinity of a process belonging to the same user. A user must possess CAP_SYS_NICE to change the CPU affinity of a process belonging to another user. A user can retrieve the affinity mask of any process.
Written by Robert M. Love.
Copyright Â© 2004 Robert M. Love. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
chrt(1), nice(1), renice(1), sched_getaffinity(2), sched_setaffinity(2)
See sched(7) for a description of the Linux scheduling scheme.
The taskset command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
pt(3tcl)                          Parser Tools                          pt(3tcl)
pt - Parser Tools Application
package require Tcl  8.5
pt generate resultformat ?options...? resultfile inputformat inputfile
Are you lost ?  Do you have trouble understanding this document ?  In that case please read the overview provided by the Introduction to Parser Tools. This document is the entrypoint to the whole system the current package is a part of.
This document describes pt, the main application of the module, a parser generator. Its intended audience are people who wish to create a parser for some language of theirs. Should you wish to modify the application instead, please see the section about the application's Internals for the basic references.
It resides in the User Application Layer of Parser Tools.
IMAGE: arch_user_app
pt generate resultformat ?options...? resultfile inputformat inputfile This sub-command of the application reads the parsing expression grammar stored in the inputfile in the format inputformat, converts it to the resultformat under the direction of the (format-specific) set of options specified by the user and stores the result in the resultfile.
The inputfile has to exist, while the resultfile may be created, overwriting any pre-existing content of the file. Any missing directory in the path to the resultfile will be created as well.
The exact form of the result for, and the set of options supported by the known result-formats, are explained in the upcoming sections of this document, with the list below providing an index mapping between format name and its associated section. In alphabetical order:
c      A resultformat. See section C Parser.
container A resultformat. See section Grammar Container.
critcl A resultformat. See section C Parser Embedded In Tcl.
json   A input- and resultformat. See section JSON Grammar Exchange.
oo     A resultformat. See section TclOO Parser.
peg    A input- and resultformat. See section PEG Specification Language.
snit   A resultformat. See section Snit Parser.
Of the seven possible results four are parsers outright (c, critcl, oo, and snit), one (container) provides code which can be used in conjunction with a generic parser (also known as a grammar interpreter), and the last two (json and peg) are doing double-duty as input formats, allowing the transformation of grammars for exchange, reformatting, and the like.
The created parsers fall into three categories:
Specialized parsers implemented in C The fastest parsers are created when using the result formats c and critcl. The first returns the raw C code for the parser, while the latter wraps it into a Tcl package using CriTcl.
This makes the latter much easier to use than the former. On the other hand, the former can be adapted to the users' requirements through a multitude of options, allowing for things like usage of the parser outside of a Tcl environment, something the critcl format doesn't support. As such the c format is meant for more advanced users, or users with special needs.
A disadvantage of all the parsers in this section is the need to run them through a C compiler to make them actually executable. This is not something everyone has the necessary tools for. The parsers in the next section are for people under such restrictions.
Specialized parsers implemented in Tcl As the parsers in this section are implemented in Tcl they are quite a bit slower than anything from the previous section. On the other hand this allows them to be used in pure-Tcl environments, or in environments which allow only a limited set of binary packages. In the latter case it will be advantageous to lobby for the inclusion of the C-based runtime support (notes below) into the environment to reduce the impact of Tcl's on the speed of these parsers.
The relevant formats are snit and oo. Both place their result into a Tcl package containing a snit::type, or TclOO class respectively.
Of the supporting runtime, which is the package pt::rde, the user has to know nothing but that it does exist and that the parsers are dependent on it. Knowledge of the API exported by the runtime for the parsers' consumption is not required by the parsers' users.
Interpreted parsing implemented in Tcl The last category, grammar interpretation. This means that an interpreter for parsing expression grammars takes the description of the grammar to parse input for, and uses it guide the parsing process.  This is the slowest of the available options, as the interpreter has to continually run through the configured grammar, whereas the specialized parsers of the previous sections have the relevant knowledge about the grammar baked into them.
The only places where using interpretation make sense is where the grammar for some input may be changed interactively by the user, as the interpretation allows for quick turnaround after each change, whereas the previous methods require the generation of a whole new parser, which is not as fast.  On the other hand, wherever the grammar to use is fixed, the previous methods are much more advantageous as the time to generate the parser is minuscule compared to the time the parser code is in use.
The relevant result format is container.  It (quickly) generates grammar descriptions (instead of a full parser) which match the API expected by ParserTools' grammar interpreter.  The latter is provided by the package pt::peg::interp.
All the parsers generated by critcl, snit, and oo, and the grammar interpreter share a common API for access to the actual parsing functionality, making them all plug-compatible.  It is described in the Parser API specification document.
peg, a language for the specification of parsing expression grammars is meant to be human readable, and writable as well, yet strict enough to allow its processing by machine. Like any computer language. It was defined to make writing the specification of a grammar easy, something the other formats found in the Parser Tools do not lend themselves too.
For either an introduction to or the formal specification of the language, please go and read the PEG Language Tutorial.
When used as a result-format this format supports the following options:
-file string The value of this option is the name of the file or other entity from which the grammar came, for which the command is run. The default value is unknown.
-name string The value of this option is the name of the grammar we are processing.  The default value is a_pe_grammar.
-user string The value of this option is the name of the user for which the command is run. The default value is unknown.
-template string The value of this option is a string into which to put the generated text and the values of the other options. The various locations for user-data are expected to be specified with the placeholders listed below. The default value is "@code@".
@user@ To be replaced with the value of the option -user.
@format@ To be replaced with the the constant PEG.
@file@ To be replaced with the value of the option -file.
@name@ To be replaced with the value of the option -name.
@code@ To be replaced with the generated text.
The json format for parsing expression grammars was written as a data exchange format not bound to Tcl. It was defined to allow the exchange of grammars with PackRat/PEG based parser generators for other languages.
For the formal specification of the JSON grammar exchange format, please go and read The JSON Grammar Exchange Format.
-indented boolean If this option is set the system will break the generated JSON across lines and indent it according to its inner structure, with each key of a dictionary on a separate line.
If the option is not set (the default), the whole JSON object will be written on a single line, with minimum spacing between all elements.
-aligned boolean If this option is set the system will ensure that the values for the keys in a dictionary are vertically aligned with each other, for a nice table effect.  To make this work this also implies that -indented is set.
If the option is not set (the default), the output is formatted as per the value of indented, without trying to align the values for dictionary keys.
The critcl format is executable code, a parser for the grammar. It is a Tcl package with the actual parser implementation written in C and embedded in Tcl via the critcl package.
This result-format supports the following options:
-class string The value of this option is the name of the class to generate, without leading colons.  The default value is CLASS.
For a simple value X without colons, like CLASS, the parser command will be X::X. Whereas for a namespaced value X::Y the parser command will be X::Y.
-package string The value of this option is the name of the package to generate. The default value is PACKAGE.
-version string The value of this option is the version of the package to generate.  The default value is 1.
The c format is executable code, a parser for the grammar. The parser implementation is written in C and can be tweaked to the users' needs through a multitude of options.
The critcl format, for example, is implemented as a canned configuration of these options on top of the generator for c.
-template string The value of this option is a string into which to put the generated text and the other configuration settings. The various locations for user-data are expected to be specified with the placeholders listed below. The default value is "@code@".
@format@ To be replaced with the the constant C/PARAM.
@code@ To be replaced with the generated Tcl code.
The following options are special, in that they will occur within the generated code, and are replaced there as well.
@statedecl@ To be replaced with the value of the option state-decl.
@stateref@ To be replaced with the value of the option state-ref.
@strings@ To be replaced with the value of the option string-varname.
@self@ To be replaced with the value of the option self-command.
@def@  To be replaced with the value of the option fun-qualifier.
@ns@   To be replaced with the value of the option namespace.
@main@ To be replaced with the value of the option main.
@prelude@ To be replaced with the value of the option prelude.
-state-decl string A C string representing the argument declaration to use in the generated parsing functions to refer to the parsing state. In essence type and argument name.  The default value is the string RDE_PARAM p.
-state-ref string A C string representing the argument named used in the generated parsing functions to refer to the parsing state.  The default value is the string p.
-self-command string A C string representing the reference needed to call the generated parser function (methods ...) from another parser fonction, per the chosen framework (template).  The default value is the empty string.
-fun-qualifier string A C string containing the attributes to give to the generated functions (methods ...), per the chosen framework (template).  The default value is static.
-namespace string The name of the C namespace the parser functions (methods, ...) shall reside in, or a general prefix to add to the function names. The default value is the empty string.
-main string The name of the main function (method, ...) to be called by the chosen framework (template) to start parsing input.  The default value is __main.
-string-varname string The name of the variable used for the table of strings used by the generated parser, i.e. error messages, symbol names, etc.  The default value is p_string.
-prelude string A snippet of code to be inserted at the head of each generated parsing function.  The default value is the empty string.
-indent integer The number of characters to indent each line of the generated code by.  The default value is 0.
-comments boolean A flag controlling the generation of code comments containing the original parsing expression a parsing function is for.  The default value is on.
The snit format is executable code, a parser for the grammar. It is a Tcl package holding a snit::type, i.e. a class, whose instances are parsers for the input grammar.
-class string The value of this option is the name of the class to generate, without leading colons. Note, it serves double-duty as the name of the package to generate too, if option -package is not specified, see below.  The default value is CLASS, applying if neither option -class nor -package were specified.
-package string The value of this option is the name of the package to generate, without leading colons. Note, it serves double-duty as the name of the class to generate too, if option -class is not specified, see above.  The default value is PACKAGE, applying if neither option -package nor -class were specified.
The oo format is executable code, a parser for the grammar. It is a Tcl package holding a TclOO class, whose instances are parsers for the input grammar.
The container format is another form of describing parsing expression grammars. While data in this format is executable it does not constitute a parser for the grammar. It always has to be used in conjunction with the package pt::peg::interp, a grammar interpreter.
The format represents grammars by a snit::type, i.e. class, whose instances are API-compatible to the instances of the pt::peg::container package, and which are preloaded with the grammar in question.
-mode bulk|incremental The value of this option controls which methods of pt::peg::container instances are used to specify the grammar, i.e. preload it into the container. There are two legal values, as listed below. The default is bulk.
bulk   In this mode the methods start, add, modes, and rules are used to specify the grammar in a bulk manner, i.e. as a set of nonterminal symbols, and two dictionaries mapping from the symbols to their semantic modes and parsing expressions.
This mode is the default.
incremental In this mode the methods start, add, mode, and rule are used to specify the grammar piecemal, with each nonterminal having its own block of defining commands.
-template string The value of this option is a string into which to put the generated code and the other configuration settings. The various locations for user-data are expected to be specified with the placeholders listed below. The default value is "@code@".
@format@ To be replaced with the the constant CONTAINER.
@mode@ To be replaced with the value of the option -mode.
@code@ To be replaced with the generated code.
In this section we are working a complete example, starting with a PEG grammar and ending with running the parser generated from it over some input, following the outline shown in the figure below:
IMAGE: flow
Our grammar, assumed to the stored in the file "calculator.peg" is
PEG calculator (Expression) Digit      <- '0'/'1'/'2'/'3'/'4'/'5'/'6'/'7'/'8'/'9'       ; Sign       <- '-' / '+'                                     ; Number     <- Sign? Digit+                                  ; Expression <- Term (AddOp Term)*                            ; MulOp      <- '*' / '/'                                     ; Term       <- Factor (MulOp Factor)*                        ; AddOp      <- '+'/'-'                                       ; Factor     <- '(' Expression ')' / Number                   ; END;
From this we create a snit-based parser via
pt generate snit calculator.tcl -class calculator -name calculator peg calculator.peg
which leaves us with the parser package and class written to the file "calculator.tcl".  Assuming that this package is then properly installed in a place where Tcl can find it we can now use this class via a script like
package require calculator
lassign $argv input set channel [open $input r]
set parser [calculator] set ast [$parser parse $channel] $parser destroy close $channel
... now process the returned abstract syntax tree ...
where the abstract syntax tree stored in the variable will look like
set ast {Expression 0 4 {Factor 0 4 {Term 0 2 {Number 0 2 {Digit 0 0} {Digit 1 1} {Digit 2 2} } } {AddOp 3 3} {Term 4 4 {Number 4 4 {Digit 4 4} } } } }
assuming that the input file and channel contained the text
120+5 A more graphical representation of the tree would be
Regardless, at this point it is the user's responsibility to work with the tree to reach whatever goal she desires. I.e. analyze it, transform it, etc. The package pt::ast should be of help here, providing commands to walk such ASTs structures in various ways.
One important thing to note is that the parsers used here return a data structure representing the structure of the input per the grammar underlying the parser. There are no callbacks during the parsing process, i.e. no parsing actions, as most other parsers will have.
Going back to the last snippet of code, the execution of the parser for some input, note how the parser instance follows the specified Parser API.
This section is intended for users of the application which wish to modify or extend it. Users only interested in the generation of parsers can ignore it.
The main functionality of the application is encapsulated in the package pt::pgen. Please read it for more information.
BUGS, IDEAS, FEEDBACK This document, and the package it describes, will undoubtedly contain bugs and other problems.  Please report such in the category pt of the Tcllib Trackers [http://core.tcl.tk/tcllib/reportlist].  Please also report any ideas for enhancements you may have for either package and/or documentation.
EBNF, LL(k), PEG, TDPL, context-free languages, expression, grammar, matching, parser, parsing expression, parsing expression grammar, push down automaton, recursive descent, state, top-down parsing languages, transducer
Parsing and Grammars
Copyright (c) 2009 Andreas Kupries <andreas_kupries@users.sourceforge.net>
qsub(1B)                               PBS                              qsub(1B)
qsub - submit pbs job
qsub [-a date_time] [-A account_string] [-b secs] [-c checkpoint_options] [-C directive_prefix] [-d path] [-D path] [-e path] [-f] [-h] [-I] [-j join] [-k keep] [-l resource_list] [-m mail_options] [-M user_list] [-N name] [-o path] [-p priority] [-P proxy_username[:group]]  [-q destination] [-r c] [-S path_list] [-t num_jobs] [-T prologue/epilogue script_name] [-u user_list] [-v variable_list] [-V] [-w] path [-W additional_attributes] [-x] [-X] [-z] [script]
To create a job is to submit an executable script to a batch server.  The batch server will be the default server unless the -q option is specified.  See discussion of PBS_DEFAULT under Environment Variables below.  Typically, the script is a shell script which will be executed by a command shell such as sh or csh.
Options on the qsub command allow the specification of attributes which affect the behavior of the job.
The qsub command will pass certain environment variables in the Variable_List attribute of the job.  These variables will be available to the job.  The value for the following variables will be taken from the environment of the qsub command: HOME, LANG, LOGNAME, PATH, MAIL, SHELL, and TZ.  These values will be assigned to a new name which is the current name prefixed with the string "PBS_O_".  For example, the job will have access to an environment variable named PBS_O_HOME which have the value of the variable HOME in the qsub command environment.
In addition to the above, the following environment variables will be available to the batch job.
PBS_O_HOST the name of the host upon which the qsub command is running.
PBS_SERVER the hostname of the pbs_server which qsub submits the job to.
PBS_O_QUEUE the name of the original queue to which the job was submitted.
PBS_O_WORKDIR the absolute path of the current working directory of the qsub command.
PBS_ARRAYID each member of a job array is assigned a unique identifier (see -t)
PBS_ENVIRONMENT set to PBS_BATCH to indicate the job is a batch job, or to PBS_INTERACTIVE to indicate the job is a PBS interactive job, see -I option.
PBS_JOBID the job identifier assigned to the job by the batch system.
PBS_JOBNAME the job name supplied by the user.
PBS_NODEFILE the name of the file contain the list of nodes assigned to the job (for parallel and cluster systems).
PBS_QUEUE the name of the queue from which the job is executed.
-a date_time Declares the time after which the job is eligible for execution.
The date_time argument is in the form: [[[[CC]YY]MM]DD]hhmm[.SS]
Where CC is the first two digits of the year (the century), YY is the second two digits of the year, MM is the two digits for the month, DD is the day of the month, hh is the hour, mm is the minute, and the optional SS is the seconds.
If the month, MM, is not specified, it will default to the current month if the specified day DD, is in the future. Otherwise, the month will be set to next month.  Likewise, if the day, DD, is not specified, it will default to today if the time hhmm is in the future.  Otherwise, the day will be set to tomorrow.  For example, if you submit a job at 11:15am with a time of -a 1110, the job will be eligible to run at 11:10am tomorrow.
-A account_string Defines the account string associated with the job.  The account_string is an undefined string of characters and is interpreted by the server which executes the job.  See section 2.7.1 of the PBS ERS.
-b seconds Defines the maximum number of seconds qsub will block attempting to contact pbs_server.  If pbs_server is down, or for a variety of communication failures, qsub will continually retry connecting to pbs_server for job submission.  This value overrides the CLIENTRETRY parameter in torque.cfg.  This is a non-portable TORQUE extension.  Portability-minded users can use the PBS_CLIENTRETRY environmental variable.  A negative value is interpreted as infinity.  The default is 0.
-c checkpoint_options Defines the options that will apply to the job.  If the job executes upon a host which does not support checkpoint, these options will be ignored.
Valid checkpoint options are:
none No checkpointing is to be performed.
enabled Specify that checkpointing is allowed but must be explicitly invoked by either the qhold or qchkpt commands.
shutdown Specify that checkpointing is to be done on a job at pbs_mom shutdown.
periodic Specify that periodic checkpointing is enabled. The default interval is 10 minutes and can be changed by the $checkpoint_interval option in the mom config file or by specifying an interval when the job is submitted
interval=minutes Checkpointing is to be performed at an interval of minutes, which is the integer number of minutes of wall time used by the job.  This value must be greater than zero.
depth=number Specify a number (depth) of checkpoint images to be kept in the checkpoint directory.
dir=path Specify a checkpoint directory (default is /var/spool/torque/checkpoint).
-C directive_prefix Defines the prefix that declares a directive to the qsub command within the script file.  See the paragraph on script directives in the Extended Description section.
If the -C option is presented with a directive_prefix argument that is the null string, qsub will not scan the script file for directives.
-d path Defines the working directory path to be used for the job.  If the -d option is not specified, the default working directory is the home directory.  This option sets the environment variable PBS_O_INITDIR.
-D path Defines the root directory to be used for the job.  This option sets the environment variable PBS_O_ROOTDIR.
-e path Defines the path to be used for the standard error stream of the batch job.  The path argument is of the form: [hostname:][path_name] where hostname is the name of a host to which the file will be returned and path_name is the path name on that host in the syntax recognized by POSIX.  The argument will be interpreted as follows:
path_name Where path_name is not an absolute path name, then the qsub command will expand the path name relative to the current working directory of the command.  The command will supply the name of the host upon which it is executing for the hostname component.
hostname:path_name Where path_name is not an absolute path name, then the qsub command will not expand the path name relative to the current working directory of the command.  On delivery of the standard error, the path name will be expanded relative to the user's home directory on the hostname system.
path_name Where path_name specifies an absolute path name, then the qsub will supply the name of the host on which it is executing for the hostname
hostname:path_name Where path_name specifies an absolute path name, the path will be used as specified.  hostname.
hostname: Where hostname specifies the name of the host that the file should be returned to. The path will be the default file name.
If the -e option is not specified or the path_name is not specified or is specified and is a directory, the default file name for the standard error stream will be used.  The default name has the following form: job_name.esequence_number where job_name is the name of the job, see -N option, and sequence_number is the job number assigned when the job is submitted.
-f      Specifies that the job is fault tolerant. The fault_tolerant attribute will be set to true, which indicates that the job can survive the loss of a mom other than the "mother superior" mom (the first node in the exec hosts )
-h      Specifies that a user hold be applied to the job at submission time.
-I      Declares that the job is to be run "interactively".  The job will be queued and scheduled as any PBS batch job, but when executed, the standard input, output, and error streams of the job are connected through qsub to the terminal session in which qsub is running.  Interactive jobs are forced to not rerunable.  See the "Extended Description" paragraph for addition information of interactive jobs.
-j join Declares if the standard error stream of the job will be merged with the standard output stream of the job.
An option argument value of oe directs that the two streams will be merged, intermixed, as standard output.  An option argument value of eo directs that the two streams will be merged, intermixed, as standard error.
If the join argument is n or the option is not specified, the two streams will be two separate files.
-k keep Defines which (if either) of standard output or standard error will be retained on the execution host.  If set for a stream, this option overrides the path name for that stream.  If not set, neither stream is retained on the execution host.
The argument is either the single letter "e" or "o", or the letters "e" and "o" combined in either order.  Or the argument is the letter "n".
e  The standard error stream is to retained on the execution host.  The  stream will be placed in the home directory of the user under whose user id the job executed.  The file name will be the default file name given by: job_name.esequence where job_name is the name specified for the job, and sequence is the sequence number component of the job identifier.
o  The standard output stream is to retained on the execution host.  The  stream will be placed in the home directory of the user under whose user id the job executed.  The file name will be the default file name given by: job_name.osequence where job_name is the name specified for the job, and sequence is the sequence number component of the job identifier.
eo Both the standard output and standard error streams will be retained.
oe Both the standard output and standard error streams will be retained.
n  Neither stream is retained.
-l resource_list Defines the resources that are required by the job and establishes a limit to the amount of resource that can be consumed.  If not set for a generally available resource, such as CPU time, the limit is infinite.  The resource_list argument is of the form: resource_name[=[value]][,resource_name[=[value]],...]
-m mail_options Defines the set of conditions under which the execution server will send a mail message about the job.  The mail_options argument is a string which consists of either the single character "n", or one or more of the characters "a", "b", and "e".
If the character "n" is specified, no mail will be sent.
For the letters "a", "b", and "e":
a  mail is sent when the job is aborted by the batch system.
b  mail is sent when the job begins execution.
e  mail is sent when the job terminates.
If the -m option is not specified, mail will be sent if the job is aborted.
-M user_list Declares the list of users to whom mail is sent by the execution server when it sends mail about the job.
The user_list argument is of the form: user[@host][,user[@host],...] If unset, the list defaults to the submitting user at the qsub host, i.e. the job owner.
-N name Declares a name for the job.  The name specified may be up to and including 15 characters in length.  It must consist of printable, non white space characters with the first character alphabetic.
If the -N option is not specified, the job name will be the base name of the job script file specified on the command line.  If no script file name was specified and the script was read from the standard input, then the job name will be set to STDIN.
-o path Defines the path to be used for the standard output stream of the batch job.  The path argument is of the form: [hostname:][path_name] where hostname is the name of a host to which the file will be returned and path_name is the path name on that host in the syntax recognized by POSIX.  The argument will be interpreted as follows:
hostname:path_name Where path_name is not an absolute path name, then the qsub command will not expand the path name relative to the current working directory of the command.  On delivery of the standard output, the path name will be expanded relative to the user's home directory on the hostname system.
If the -o option is not specified or the path_name is not specified or is specified and is a directory, the default file name for the standard output stream will be used.  The default name has the following form: job_name.osequence_number where job_name is the name of the job, see -N option, and sequence_number is the job number assigned when the job is submitted.
-p priority Defines the priority of the job.  The priority argument must be a integer between -1024 and +1023 inclusive.  The default is no priority which is equivalent to a priority of zero.
-P proxy_user[:group] Proxy user for whom the job should be submitted.  This option is only available for the super user.
-q destination Defines the destination of the job.  The destination names a queue, a server, or a queue at a server.
The qsub command will submit the script to the server defined by the destination argument.  If the destination is a routing queue, the job may be routed by the server to a new destination.
If the -q option is not specified, the qsub command will submit the script to the default server.  See PBS_DEFAULT under the Environment Variables section on this man page and the PBS ERS section 2.7.4, "Default Server".
If the -q option is specified, it is in one of the following three forms: queue @server queue@server
If the destination argument names a queue and does not name a server, the job will be submitted to the named queue at the default server.
If the destination argument names a server and does not name a queue, the job will be submitted to the default queue at the named server.
If the destination argument names both a queue and a server, the job will be submitted to the named queue at the named server.
-r y|n  Declares whether the job is rerunable.  See the qrerun command. The option argument is a single character, either y or n.
If the argument is "y", the job is rerunable.  If the argument is "n", the job is not rerunable.  The default value is 'y', rerunable.
-S path_list Declares the shell that interprets the job script.
The option argument path_list is in the form: path[@host][,path[@host],...] Only one path may be specified for any host named.  Only one path may be specified without the corresponding host name.  The path selected will be the one with the host name that matched the name of the execution host.  If no matching host is found, then the path specified without a host will be selected, if present.
If the -S option is not specified, the option argument is the null string, or no entry from the path_list is selected, the execution will use the user's login shell on the execution host.
-t array_request Specifies the task ids of a job array.  Single task arrays are allowed.
The array_request argument is an integer id or a range of integers. Multiple ids or id ranges can be combined in a comma delimted list. Examples : -t 1-100 or -t 1,10,50-100
-T script_name Allows for per job prologue and epilogue scripts. The full script name will be prologue.[name] or epilogue.[name]. For the job submission, only request the name of the prologue or epilogue script.
Example: qsub -T prescript Specifies to use the script prologue.prescript
-u user_list Defines the user name under which the job is to run on the execution system.
The user_list argument is of the form: user[@host][,user[@host],...] Only one user name may be given per specified host.  Only one of the user specifications may be supplied without the corresponding host specification.  That user name will used for execution on any host not named in the argument list.  If unset, the user list defaults to the user who is running qsub.
-v variable_list Expands the list of environment variables that are exported to the job.
In addition to the variables described in the "Description" section above, variable_list names environment variables from the qsub command environment which are made available to the job when it executes.  The variable_list is a comma separated list of strings of the form variable or variable=value.  These variables and their values are passed to the job.
-V      Declares that all environment variables in the qsub command's environment are to be exported to the batch job.
-w path Defines the working directory path to be used for the job.  If the -w option is not specified, the default working directory is the current directory.  This option sets the environment variable PBS_O_WORKDIR.
-W additional_attributes The -W option allows for the specification of additional job attributes.  The general syntax of the -W is in the form: -W attr_name=attr_value[,attr_name=attr_value...] Note if white space occurs anywhere within the option argument string or the equal sign, "=", occurs within an attribute_value string, then the string must be enclosed with either single or double quote marks.
PBS currently supports the following attributes within the -W option.
depend=dependency_list Defines the dependency between this and other jobs.  The dependency_list is in the form: type[:argument[:argument...][,type:argument...]. The argument is either a numeric count or a PBS job id according to type .  If argument is a count, it must be greater than 0.  If it is a job id and not fully specified in the form seq_number.server.name, it will be expanded according to the default server rules which apply to job IDs on most commands.  If argument is null (the preceding colon need not be specified), the dependency of the corresponding type is cleared (unset).
synccount:count This job is the first in a set of jobs to be executed at the same time.  Count is the number of additional jobs in the set.
syncwith:jobid This job is an additional member of a set of jobs to be executed at the same time.  In the above and following dependency types, jobid is the job identifier of the first job in the set.
after:jobid[:jobid...] This job may be scheduled for execution at any point after jobs jobid have started execution.
afterok:jobid[:jobid...] This job may be scheduled for execution only after jobs jobid have terminated with no errors.  See the csh warning under "Extended Description".
afternotok:jobid[:jobid...] This job may be scheduled for execution only after jobs jobid have terminated with errors.  See the csh warning under "Extended Description".
afterany:jobid[:jobid...] This job may be scheduled for execution after jobs jobid have terminated, with or without errors.
on:count This job may be scheduled for execution after count dependencies on other jobs have been satisfied.  This form is used in conjunction with one of the before forms, see below.
before:jobid[:jobid...] When this job has begun execution, then jobs jobid... may begin.
beforeok:jobid[:jobid...] If this job terminates execution without errors, then jobs jobid... may begin.  See the csh warning under "Extended Description".
beforenotok:jobid[:jobid...] If this job terminates execution with errors, then jobs jobid... may begin.  See the csh warning under "Extended Description".
beforeany:jobid[:jobid...] When this job terminates execution, jobs jobid... may begin.
If any of the before forms are used, the jobs referenced by jobid must have been submitted with a dependency type of on.
If any of the before forms are used, the jobs referenced by jobid must have the same owner as the job being submitted.  Otherwise, the dependency is ignored.
Error processing of the existence, state, or condition of the job on which the newly submitted job is a deferred service, i.e. the check is performed after the job is queued.  If an error is detected, the new job will be deleted by the server. Mail will be sent to the job submitter stating the error.
Dependency examples: qsub -W depend=afterok:123.big.iron.com /tmp/script qsub -W depend=before:234.hunk1.com:235.hunk1.com /tmp/script
group_list=g_list Defines the group name under which the job is to run on the execution system.  The g_list argument is of the form: group[@host][,group[@host],...] Only one group name may be given per specified host.  Only one of the group specifications may be supplied without the corresponding host specification.  That group name will used for execution on any host not named in the argument list.  If not set, the group_list defaults to the primary group of the user under which the job will be run.
interactive=true If the interactive attribute is specified, the job is an interactive job.  The -I option is a alternative method of specifying this attribute.
stagein=file_list stageout=file_list Specifies which files are staged (copied) in before job start or staged out after the job completes execution.  On completion of the job, all staged-in and staged-out files are removed from the execution system.  The file_list is in the form local_file@hostname:remote_file[,...] regardless of the direction of the copy.  The name local_file is the name of the file on the system where the job executed.  It may be an absolute path or relative to the home directory of the user.  The name remote_file is the destination name on the host specified by hostname.  The name may be absolute or relative to the user's home directory on the destination host.  The use of wildcards in the file name is not recommended.  The file names map to a remote copy program (rcp) call on the execution system in the follow manner: For stagein:   rcp hostname:remote_file local_file For stageout:  rcp local_file hostname:remote_file Data staging examples: -W stagein=/tmp/input.txt@headnode:/home/user/input.txt -W stageout=/tmp/output.txt@headnode:/home/user/output.txt If TORQUE has been compiled with wordexp support, then variables can be used in the specified paths.  Currently only $PBS_JOBID, $HOME, and $TMPDIR are supported for stagein.
umask=XXX Sets umask used to create stdout and stderr spool files in pbs_mom spool directory. Values starting with 0 are treated as octal values, otherwise the value is treated as a decimal umask value.
-x      When running an interactive job, the -x flag makes it so that the script won't be parsed for PBS directives, but instead will be a command that is launched once the interactive job has started. The job will terminate at the completion of this command.
-X      Enables X11 forwarding.  The DISPLAY environment variable must be set.
-z      Directs that the qsub command is not to write the job identifier assigned to the job to the command's standard output.
The qsub command accepts a script operand that is the path to the script of the job.  If the path is relative, it will be expanded relative to the working directory of the qsub command.
If the script operand is not provided or the operand is the single character "-", the qsub command reads the script from standard input. When the script is being read from Standard Input, qsub will copy the file to a temporary file.  This temporary file is passed to the library interface routine pbs_submit.  The temporary file is removed by qsub after pbs_submit returns or upon the receipt of a signal which would cause qsub to terminate.
The qsub command reads the script for the job from standard input if the script operand is missing or is the single character "-".
The script file is read by the qsub command.  Qsub acts upon any directives found in the script.
When the job is created, a copy of the script file is made and that copy cannot be modified.
Unless the -z option is set, the job identifier assigned to the job will be written to standard output if the job is successfully created.
The qsub command will write a diagnostic message to standard error for each error occurrence.
The values of some or all of the variables in the qsub command's environment are exported with the job, see the -v and -V options.
The environment variable PBS_DEFAULT defines the name of the default server.   Typically, it corresponds to the system name of the host on which the server is running.  If PBS_DEFAULT is not set, the default is defined by an administrator established file.
The environment variable PBS_DPREFIX determines the prefix string which identifies directives in the script.
The environment variable PBS_CLIENTRETRY defines the maximum number of seconds qsub will block.  See the -b option above.  Despite the name, currently qsub is the only client that supports this option.
TORQUE.CFG The torque.cfg file, located in PBS_SERVER_HOME (/var/spool/torque by default) controls the behavior of the qsub command. This file contains a list of parameters and values separated by whitespace
QSUBSLEEP takes an integer operand which specifies time to sleep when running qsub command.  Used to prevent users from overwhelming the scheduler.
SUBMITFILTER specifies the path to the submit filter used to pre-process job submission. The default path is $(libexecdir)/qsub_filter, which falls back to /usr/local/sbin/torque_submitfilter for backwards compatibility. This torque.cfg parameter overrides this default.
SERVERHOST specifies the value for the PBS_SERVER environment variable
QSUBHOST specifies the hostname for the jobs QSUB_O_HOST variable
QSUBSENDUID specifies a uid to use for the jobs PBS_O_UID variable