Overview of the different schedulers (or ‘run modes’) in Murex
There are a few distinct schedulers (or run modes) in Murex which are invoked by builtin commands. This means you can alter the way commands are executed dynamically within Murex shell scripts.
This is a traditional shell where anything in a pipeline (eg cmd1 -> cmd2 -> cmd3
) is executed in parallel. The scheduler only pauses launching new commands when the last command in any pipeline is still executing. A pipeline could be multiple commands (like above) or a single command (eg top
).
Normal is the default run mode. When running in a stricter mode, you can not reset the run mode back to normal. You can, however, switch to unsafe
.
This is the same as normal except that unsafe
blocks always return zero exit numbers. The purpose for this is to enable “normal” like scheduling inside stricter code blocks that might exit if the last function was a non-zero exit number.
This is the weakest of all the stricter run modes. It does check the exit number to confirm if the last function was successful, but only the last function in any given pipeline. So in cmd1 -> cmd2 -> cmd3
, if cmd1
or cmd2
fail, the try
block doesn’t exit.
The benefit of run mode is that it still supports commands running in parallel.
This runs the commands sequentially because the stderr and the exit number of each command is checked irrespective of whether that command is at the start of the pipeline (eg start -> middle -> end
), or anywhere else.
This offers better coverage of exit numbers but at the cost of parallelisation.
This is similar to try
and normal where commands in a pipeline are run in parallel. The key difference with tryerr
is that Murex validates the stderr as well as the exit number of the last command in any pipeline.
If stderr is greater than stdout (per bytes written) OR the exit number is non-zero then the scheduler exits that entire block.
This runs the commands sequentially because the stderr and the exit number of each command is checked irrespective of whether that command is at the start of the pipeline (eg start -> middle -> end
), or anywhere else.
Like with tryerr
, if stderr is greater than stdout (per bytes written) OR the exit number is non-zero then the scheduler exits that entire block. Unlike with tryerr
, this check happens on every command rather than the last command in the pipeline.
->
Arrow Pipe: Pipes stdout from the left hand command to stdin of the right hand command=>
Generic Pipe: Pipes a reformatted stdout stream from the left hand command to stdin of the right hand command?
stderr Pipe: Pipes stderr from the left hand command to stdin of the right hand command (DEPRECATED)runmode
: Alter the scheduler’s behaviour at higher scoping leveltry
: Handles non-zero exits inside a block of codetryerr
: Handles errors inside a block of codetrypipe
: Checks for non-zero exits of each function in a pipelinetrypipeerr
: Checks state of each function in a pipeline and exits block on errorunsafe
: Execute a block of code, always returning a zero exit number|
POSIX Pipe: Pipes stdout from the left hand command to stdin of the right hand commandThis document was generated from gen/user-guide/schedulers_doc.yaml.
This site's content is rebuilt automatically from murex's source code after each merge to the master
branch. Downloadable murex binaries are also built with the website.
Last built on Thu Aug 15 14:38:34 UTC 2024 against commit 50ed9d650ed9d6df391240d3c2c02e623636e508dfcdad1.
Current version is 6.2.4000 which has been verified against tests cases.