LARBS: the CSV-driven shell script that installs an Arch Linux environment as root

What LARBS does and who it is for: one script, one CSV, one Arch install

LARBS stands for Luke's Auto-Rice Bootstrapping Scripts. Its purpose is to take a fresh Arch or Artix Linux installation and configure it into a complete working environment without manual package installation or dotfile setup. The README describes the result as a minimal terminal-and-vim-based environment and a "fully configured diving-board for work or more customization."

The target user is someone starting from scratch on Arch or Artix who wants to reproduce a curated environment, either Luke Smith's own setup or a customized variant. LARBS does not help with the initial Arch installation itself; it assumes you have already reached a point where you are logged in as root on a running Arch or Artix system.

The scope is intentionally limited. LARBS is not a package manager, not a dotfile manager for an existing system, and not a general-purpose provisioning tool. It is a bootstrap script: run once, deploy the environment, and then maintain it manually or fork the script for your own use.

The two-line install command and what running as root means for the process

The README gives a two-command install sequence. First, download the script; then run it:

curl -LO larbs.xyz/larbs.sh
sh larbs.sh

The script must be run as root on an Arch-based distribution. Running as root is necessary because the script creates a new user, installs system packages via pacman, and edits system configuration. The download comes from larbs.xyz rather than directly from the GitHub repository: you are trusting that URL and its contents at run time, not a pinned commit.

The script itself is divided into functions for readability and troubleshooting. The README says most of it should be self-explanatory when read, and the functions can be inspected before the script is run. This is relevant because auditing any script before piping it to a shell as root is the right thing to do.

The progs.csv format: three columns, three installation methods, and one ordering rule

LARBS reads a three-column CSV to know what to install. The tag column in column 1 accepts exactly 3 values: blank (main pacman repository), A (AUR), and G (git repository installed with `make && sudo make install`). Each value maps to a different code path inside installationloop.

The second column is the program name for the repository, or the git URL if the tag is G. The third column is a description, which must be a verb phrase because LARBS uses it to print a grammatical sentence during installation. Descriptions that contain commas must be wrapped in double quotes to avoid breaking CSV parsing.

Order matters. LARBS installs from the top row to the bottom, so if a program in row 20 depends on a library in row 50, the install will fail. The README says to "tactically order" the file for your own build, meaning dependency order is the author's responsibility rather than the script's.

Reading the CSV tells you what is installed and why, because every entry has a verb-phrase description; that makes it usable as documentation without running the script.

How the newperms function builds AUR packages as a non-root user

AUR packages cannot be built as root; pacman and makepkg both refuse to run under the root account for build steps. LARBS runs as root but still needs to build AUR packages, which requires a user account.

The solution in the script is the `newperms` function. Before AUR packages are installed, newperms temporarily grants the newly created user passwordless sudo access. The README acknowledges this is done "ad-hocly, but effectively": a direct admission in the script's own documentation that the mechanism is improvised, even though it works.

After the full installation finishes, newperms runs again to remove those broad permissions. The final state is more restricted: the user can run only three commands without a password: `shutdown`, `reboot`, and `pacman -Syu`. Everything else requires a password. This means anyone examining a LARBS-installed system will find a user account with exactly those three passwordless sudo rules set.

The `installationloop` function handles the actual installation iteration, reading each row of the CSV and calling the appropriate install command based on the tag. Custom tags can be added by modifying the relevant section of installationloop.

The -r, -p, and -a flags for replacing the default dotfiles, program list, and AUR helper

By default, LARBS installs Luke Smith's dotfiles from the voidrice repository at github.com/lukesmithxyz/voidrice and reads the program list from static/progs.csv in the LARBS repository. Both defaults can be replaced.

Three flags change those defaults:

- `-r` replaces the default dotfiles repository with a custom URL - `-p` replaces the default programs list with a local file path or a URL - `-a` replaces the default AUR helper with a custom one

The AUR helper flag has a constraint: the replacement must support the `-S` flag for installation, or the relevant line inside the script must be changed manually before running. This means drop-in substitution only works for helpers that share that interface.

Modifying the default variables at the beginning of the script is the alternative to flags, which makes the changes permanent in your fork rather than requiring you to pass flags each time.

What LARBS cannot do: no Debian or Fedora support, no idempotency, no rollback

LARBS works only on Arch-based distributions because it calls pacman directly. The README names Arch and Artix as the supported targets. Anyone on Debian, Ubuntu, Fedora, or any other non-Arch derivative cannot use LARBS without rewriting the package management portions of the script.

The script has no idempotency mechanism. Running it a second time on an already-configured system would attempt to re-install every program in the CSV and re-deploy the dotfiles, overwriting any changes made after the first run. The README does not describe what happens in that case or how to avoid it.

No rollback capability is described. If the install fails partway through, the system is in a partially configured state, and recovery is manual. The README says the function structure makes troubleshooting easier, but it documents no recovery procedure.

For comparison, Ansible achieves similar goals (deploying a specific set of packages and configuration files) with idempotency baked in: tasks check their current state before acting, can target multiple distributions through different playbooks, and support multiple target machines. The trade-off is that Ansible requires Python, YAML playbook authoring, and an inventory file; LARBS requires none of that and installs in two commands.

Why the download URL differs from the GitHub repository and what to check before running

The install command downloads larbs.sh from larbs.xyz, not from github.com/LukeSmithxyz/LARBS. The GitHub repository holds the canonical source, but the script fetched by curl comes from a separately maintained web server. Whether the version at larbs.xyz matches the current commit in the repository is something the README does not address. A developer who wants to verify what they are running should compare the downloaded script against the repository contents before executing it as root.

The project is GPL-3.0 and the last push was on 2026-08-31; the repository has no GitHub releases.

Editorial conclusion

LARBS suits Arch and Artix users who want to bootstrap a terminal-and-vim environment from a CSV-defined program list and a dotfiles repository in two commands. Users on other distributions, or anyone who wants idempotent configuration management that can be re-run safely on an existing system, will need a different approach: LARBS makes no attempt to track what is already installed, and running it on a system that already has a conflicting configuration is not addressed in the README. Before running larbs.sh as root, read both the script itself and the progs.csv at static/progs.csv in the repository, since the script installs every entry in that list and gives the newly created user permanent passwordless sudo for shutdown, reboot, and pacman -Syu.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. LukeSmithxyz/LARBS on GitHub
4. README