Skip to content

Latest commit

 

History

History
106 lines (73 loc) · 3.79 KB

GUIDE.quick-start.md

File metadata and controls

106 lines (73 loc) · 3.79 KB

Language Guide: Quick start guide for Bash developers

This is a cheat sheet reference for lazy Bash developers wishing to accelerate their introduction into murex:

Piping and redirection

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).

Embeddable subshells

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.

Globbing

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}

Exit code

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

Array expansion

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.

Back ticks

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" }