An introduction to murex modules and packages
murex has it’s own module system with namespacing and a package manager. But why should a shell need all this?
The answer comes from years of me using Bash and wishing my Bash environment could be consistent across multiple machines. So this document is authored from the perspective of my personal usage (“me” being Laurence Morgan, the original author of murex).
What murex’s package system provides is:
Before I address those points in more detail, a bit of background into what modules and packages are:
murex comes with it’s own package manager to make managing plugins easier.
The format of the packages is a directory, typically located at
~/.murex_modules, which contains one or more murex scripts. Each script can be it’s own module. ie there are multiple modules that can be grouped together and distributed as a single package.
The way packages and modules are represented is as a path:
murex-package is a package management tool for administrating murex modules and packages.
Package database are stored locally at
~/.murex_modules/packages.json. This file is portable so any new machine can have
packages.json imported. The easiest way of doing this is using
murex-package which can import from a local path or HTTP(S) URI and automatically download any packages described in the database.
For example the command I run on any new dev machine to import all of my DevOps tools and terminal preferences is the following:
murex-package: import https://gist.githubusercontent.com/lmorg/770c71786935b44ba6667eaa9d470888/raw/fb7b79d592672d90ecb733944e144d722f77fdee/packages.json
Namespacing allows for
private functions which allows you to write smaller functions. Smaller functions are easier to write tests against (murex also has an inbuilt testing and debugging tools).
Packages can be hosted via HTTP(S) or git. Anyone can import anyone elses packages using
murex-package: install https://github.com/lmorg/murex-module-murex-dev.git
Updating packages is easy:
All code loaded in murex, every function, variable and event (etc) is stored in memory with metadata about where it was loaded from; which package, file and at what time. This is called
For more information on
FileRef see the link below.
A common shell idiom is to load shell script files via
.. When this is done the module string (as seen in the
FileRef structures described above) will be
source/hash where hash will be a unique hash of the file path and load time.
Thus no two sourced files will share the same module string. Even the same file but modified and sourced twice (before and after the edit) will have different module strings due to the load time being part of the hashed data.
Any functions, variables, events, auto-completions, etc created manually, directly, in the interactive shell will have a module string of
murex and an empty Filename string.
murex-package: murex’s package manager
private: Define a private function block
source: Import murex code from another file of code block
test: murex’s test framework - define tests, run tests and debug shell scripts
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 Mon Feb 13 09:18:06 UTC 2023 against commit f339958f33995895c1d997efcdbb8408d2c8d45f8b5f934.
Current version is which has been verified against 13950 tests cases.