This is a cheat sheet reference for lazy Bash developers wishing to accelerate their introduction into murex:
murex supports the |
pipe just like Bash but the preferred pipe
token in murex the arrow, ->
(those two token are interchangeable).
Redirection of stdout and stderr is very different in murex. There is
no support for the 2>
or &1
tokens, instead you name the pipe as
the first parameter:
err: <!out> "error message redirected to stdout"
out: <err> "output redirected to stderr"
You can also use named pipes this way to join up parts of the script that otherwise wouldn't be part of the same pipeline. See GUIDE.syntax for more details on named pipes.
To redirect to a file you can use the >
or >>
functions. They work
similarly to bash except that they are functions rather than tokens:
out: "message" ->> new-file.txt
out: "message" ->>> append-file.txt
(these can be written as -> >
/ -> >>
respectively since they are
literally just inbuilt functions).
There are two types of embeddable subshells: strings and arrays.
-
string subshells,
${ command }
, take the results from the subshell and return it as a single parameter. Equivalent to the following in bash:command "$(subshell command)"
. -
array subshells,
@{ command }
, take the results from the subshell and expand it as parameters. Arrays can be multiple lines (like in Bash) or array objects in more complex data formats like JSON. Unlike bash, other white spaces such as tabs and space characters are not counted as separators for walking through arrays. This is intentional to allow line formatting and space characters in file names. Array shells are equivalent to the following in Bash:command $(subshell command)
Examples:
ls -l ${out: file name} # works because file name contain space
ls -l @{out: file1 file2 file3} # fails because not an array
ls -l @{out: file1\nfile2\nfile3} # works because output is an array
The reason murex breaks from the POSIX tradition of using backticks and parentheses is because murex works on the principle that everything inside a curly bracket is considered a new block of code. Typically that would mean a subshell however sometimes it could be configuration code in the form of inlined JSON.
There isn't auto-expansion of globbing to protect against accidental damage. Instead globbing is achieved via subshells using either:
g
(traditional globbing)rx
(regexp matching in current directory only)f
(file or directory type matching)
Examples:
# all text files via globbing:
ls -l @{g *.txt}
# all text and markdown files via regexp:
ls -l @{rx '\.(txt|md)$'}
# all files via type matching:
ls -l @{f +f}
You can also using type matching against globbing and regexp to filter out types in conjunction with file name matching:
# all directories named *.txt
ls -l @{g *.txt -> f +d}
In bash the variable $?
would store the exit code. This doesn't exist
in murex. Instead there a separate command exitnum
:
open: test/fox.txt -> grep: foobar; exitnum
In bash you can expand arrays using the following syntax: a{1..5}b
. In
murex this is another subshell process: a: a[1..5]b
. As you can see,
murex also uses square brackets instead as well. There are a few other
changes, read GUIDE.arrays-and-maps
for more on using the array
builtin.
In murex back ticks do not spawn subshells. Back ticks are treated
like a regular, printable, character. Their only special function is
quoting strings in =
, eg:
if { = `quoted string`==variable } { out "do something" }