How to track what code was loaded and from where
Every function, event, autocompletion and even variable is stored with which file it was sourced, when it was loaded and what module it was loaded from. This makes it trivial to identify buggy 3rd party code, malicious libraries, or even just bugs in your own profiles and/or modules.
» runtime: --functions -> [[ /agent/FileRef/ ]]
{
"Column": 5,
"Line": 5,
"Source": {
"DateTime": "2021-03-28T09:10:53.572197+01:00",
"Filename": "/home/lmorg/.murex_modules/murex-dev/murex-dev.mx",
"Module": "murex-dev/murex-dev"
}
}
» runtime --globals -> [[ /DEVOPSBIN/FileRef ]]
{
"Column": 1,
"Line": 0,
"Source": {
"DateTime": "2021-03-28T09:10:53.541952+01:00",
"Filename": "/home/lmorg/.murex_modules/devops/global.mx",
"Module": "devops/global"
}
}
A common shell idiom is to load shell script files via source
/ .
. 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.
[[
(element): Outputs an element from a nested structuremurex-package
: murex’s package managerruntime
: Returns runtime information on the internal state of murexsource
: Import murex code from another file of code blockThis 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.