# How to Use Pre and Post Install Hooks to Run Custom Scripts When Installing MongoDB with m > Learn to use pre and post install hooks with m to run custom scripts automatically during MongoDB installations. Enhance your workflow effortlessly. - Repository: [Aaron Heckmann/m](https://github.com/aheckmann/m) - Tags: how-to-guide - Published: 2026-02-23 --- **The `m` MongoDB version manager executes custom scripts automatically before and after installation by reading executable absolute paths from `$M_DIR/pre_install` and `$M_DIR/post_install` files.** The `aheckmann/m` repository provides a lightweight Bash-based version manager for MongoDB that supports **pre and post install hooks** for automation. This hook system allows you to run arbitrary scripts during the installation lifecycle, enabling tasks like logging, environment validation, or notifications without manual intervention. ## Understanding the Hook Architecture Hooks in `m` are stored as plain-text lists of executable paths inside the **m** data directory (`$M_DIR`), which defaults to `$HOME/.local/m`. The system recognizes two lifecycle events for hooks: `install` (triggered when running `m install ` or `m `) and `change` (triggered when switching active versions via `m as `). For the `install` event, `m` looks for two specific files: - `$M_DIR/pre_install` – scripts to execute before downloading the MongoDB binary - `$M_DIR/post_install` – scripts to execute after successful installation According to the source code in `bin/m`, the `validate_event` function ensures only `install` and `change` are accepted as valid hook events. Each script path listed in these files must be **executable** (`chmod +x`) and specified as an **absolute path** to prevent execution of untrusted or ambiguous code. ## Registering Pre and Post Install Hooks You register hooks using the `m pre` and `m post` subcommands followed by the event type and absolute script path. The `install_hook` function (lines 335–395 in `bin/m`) handles appending validated paths to the appropriate hook file. ```bash # Register a script to run before installation m pre install /home/user/scripts/prepare_env.sh # Register a script to run after installation m post install /home/user/scripts/notify_complete.sh ``` Scripts must meet strict validation criteria enforced by the hook system. If a script is not executable or uses a relative path, `m` will reject the registration and exit with an error. This security measure ensures that only explicitly trusted code runs during the installation process. ## Managing and Listing Existing Hooks To view currently registered hooks, invoke the command without a script path. The `list_pres()` function (lines 40–48 in `bin/m`) and its counterpart `list_posts()` display the contents of the respective hook files: ```bash # List all pre-install hooks m pre install # List all post-install hooks m post install ``` Removing hooks follows a similar syntax. To delete a specific hook, append `rm` followed by the absolute path. To remove all hooks for an event, use `rm` without specifying a path: ```bash # Remove a specific pre-install hook m pre install rm /home/user/scripts/prepare_env.sh # Remove ALL post-install hooks (empties the file) m post install rm ``` ## Execution Flow During Installation When you execute `m 7.0.14` or `m install 7.0.14`, the main entry point in `bin/m` orchestrates the following sequence: 1. **Pre-install phase**: The `pre()` function (lines 12–20) reads `$M_DIR/pre_install` line-by-line and executes each script synchronously, waiting for completion before proceeding. 2. **Installation phase**: `m` downloads and extracts the requested MongoDB binary to `$M_DIR/versions/`. 3. **Post-install phase**: The `post()` function reads `$M_DIR/post_install` and executes each registered script, passing the installed version number as an argument. Because hooks run **synchronously**, a failing pre-install hook will halt the installation process entirely, while a failing post-install hook will report errors but leave the installation intact. ## Practical Example: Logging MongoDB Installations The following workflow demonstrates setting up hooks that log installation timestamps and print completion messages: ```bash # 1. Create the pre-install logging script echo '#!/usr/bin/env bash' > $HOME/scripts/m_install_log.sh echo 'date >> $HOME/.local/m/install.log' >> $HOME/scripts/m_install_log.sh chmod +x $HOME/scripts/m_install_log.sh # 2. Register as pre-install hook m pre install $HOME/scripts/m_install_log.sh # 3. Verify registration m pre install # 4. Create post-install notification script echo '#!/usr/bin/env bash' > $HOME/scripts/m_install_done.sh echo 'echo "MongoDB $1 installed successfully!"' >> $HOME/scripts/m_install_done.sh chmod +x $HOME/scripts/m_install_done.sh m post install $HOME/scripts/m_install_done.sh # 5. Install a version to trigger both hooks m 7.0.14 ``` After running `m 7.0.14`, you will see the date appended to `install.log` before the download begins, followed by the success message "MongoDB 7.0.14 installed successfully!" after completion. ## Summary - **Hook storage**: Scripts are listed in `$M_DIR/pre_install` and `$M_DIR/post_install` as absolute paths. - **CLI management**: Use `m pre install ` and `m post install ` to add hooks; use `rm` to remove them. - **Security requirements**: Scripts must be executable and use absolute paths, enforced by the `validate_event` and `install_hook` functions in `bin/m`. - **Execution order**: The `pre()` function runs before download, then installation occurs, then the `post()` function runs with the version number as an argument. - **Synchronous operation**: `m` waits for each hook to complete before proceeding, ensuring deterministic installation behavior. ## Frequently Asked Questions ### Can I use relative paths like `~/scripts/hook.sh` when registering hooks? No. The `install_hook` function in `bin/m` explicitly requires absolute paths (e.g., [`/home/username/scripts/hook.sh`](https://github.com/aheckmann/m/blob/main//home/username/scripts/hook.sh)) to prevent ambiguity about which script should execute. Relative paths will be rejected during registration. ### Do hooks run for the `change` event as well as `install`? Yes. The hook system supports both `install` and `change` events. When switching active MongoDB versions using `m as `, `m` checks for `pre_change` and `post_change` files in `$M_DIR` and executes them using the same `pre()` and `post()` functions. ### What happens if a pre-install hook fails or returns a non-zero exit code? Because hooks execute synchronously, a failing pre-install hook (non-zero exit status) will halt the entire installation process immediately. The MongoDB binary will not be downloaded, and no post-install hooks will run. Post-install hook failures are logged but do not rollback the installation. ### How can I view the raw hook files directly? The hook files are plain text stored in your **m** data directory. You can inspect them directly with: ```bash cat "$HOME/.local/m/pre_install" cat "$HOME/.local/m/post_install" ``` These files contain one absolute script path per line, matching the output of `m pre install` and `m post install`.