looney.eu
INFRASTRUCTURE / AUTOMATION / DEVELOPMENT
Fixing things that don't need fixing and breaking things that didn't need breaking.
I script workflows, deploy infrastructure, preach vim over nano, get unreasonably excited about open source tools and appreciate topping all that off with well-spent game time among friends.
Use keyboard to navigate → ↑ ↓ · press ~ for the prompt, try "help"
GET IN TOUCH
INFO
Infrastructure
Projects
Crew-for-hire platform for Star Citizen. Recruiters post operations and assemble crews. Crew members list availability and build reputation through review-based rankings. Organisations manage squads, ranks, and fleets -- all tied to RSI-verified identities.
features
A foobar2000 component that renders animated GIF files as album art. Drop it in, point the artwork panel at a .gif, and your covers come alive — static art is so last decade.
C++ library that indexes a local music collection and resolves cover art by track metadata. Scans directories on startup, watches for changes, and returns matching cover art fast enough for real-time use in discord-music-presence.
Single-binary task and project manager built as a faster replacement for Beads. It combines an LMDB-backed CLI, live web UI, and MCP tools for agent-friendly planning across projects.
CLI that answers "why is my shell doing this?" — inspects a shell session, applies per-shell startup-file rules, safely parses source statements, detects tooling hooks (starship, direnv, nvm, ...), and labels every file with a confidence level instead of pretending static analysis can prove runtime behavior.
Five service hosts spanning macOS and Linux, connected over Tailscale, with a Windows gaming and generation machine alongside them and shared Kopia storage on noc-wardrobe. Runs media, communications, game servers, a knowledge archive, local models, and monitoring.
BLOG
↑↓ pick a post · ↵ read · inside a post: j/k scroll, n next, q back
What the fuck is a DHCP, Adam?
If you have to ask this question, I both pity you and envy you equally. DNS is the root of all problems in IT, if you think something is broken, it is not “something”, it is DNS. DHCP is its slightly less evil cousin, and the one this post is actually about, because sometimes I confuse the two as within intranet, they’re not all too far separated.
There is only one other thing hated as much, that being IPv6, thankfully I haven’t gone through enough hell with that yet to make a post about it, but it’s certainly lurking in the darkness to absolutely obliterate my joy in life.
Just so we’re on the same page, DNS is what gets you from google.com in your URL to a webpage with a search box.
It translates a domain name to an IP so your browser can render a page or your terminal can get a ping reply, it stands for Domain Name System and is one of the most ancient relics the internet relies on.
If global DNS stopped working tomorrow, everything as you know it on the internet would also stop working, bar a handful of applications that have prepared for doomsday.
DHCP is the thing that hands your device an IP address in the first place, so it has somewhere to be found at. Dynamic Host Configuration Protocol, it’s the reason you don’t have to type an IP into every laptop, printer and audio mixer you plug into the wall.
What are they like to work with?
Generally speaking, they just work, these are standards that are almost older than most people reading this article I’m sure, so they’ve had time to mature and become mostly reasonable.
However, even in a best case scenario, it is simply a leap of trust that the old bones of industry will carry on and work as intended. Even more so when we delve into the AD and legacy system support.
You just need to expect it to work in fundamental ways, if it doesn’t, confusion ensues.
Where does AD (Active Directory) play a role?
Just like with the global internet, most intranets (private networks) rely on some form of local DNS to operate key functions or to allow sysadmins like myself to access key resources without having to remember IP addresses.
We take a piece of hardware, say an audio mixer, and we tell the AD DHCP server that whenever it sees this device, always hand it 10.0.0.4, that’s a reservation.
Then we tell DNS that mixer-001 points at 10.0.0.4. I can then access this audio mixer from anywhere with network access to that IP by typing in the easy to remember name instead.
This is also very important for mission critical servers, certificates are issued for hostnames rather than IPs, so if DNS stops resolving the name, clients can no longer reach the service by the name the cert is valid for, and the application falls over.
All in all, DNS and DHCP play just as important a role in intranets as they do on the world wide web.
Are there any gimmicks with Windows and DHCP one should know?
Oh god yes, yes there are… The whole reason for me writing this blog is purely because of my utter rage when I found out Windows is still using legacy MAC address formatting. Here was me, trying to create a reservation, it asking for the MAC address to point the reservation at, I type it in within the standard used by nearly everything on the planet, this being 12 hex characters, 6 octets, each a pair separated by a colon, e.g 12:34:56:78:91:01, but to my dismay, Windows has decided that they should use a separate standard compared to just about every other operating system and application out there.
Microsoft fucking Windows has decided that rather, you should just drop the colons, either use dashes or just raw dog your MAC address straight into the field, so instead of nice orderly octets you get 123456789101
And just you wait, you think that’s where the bullshittery stops? OH NO, mind you, when you then do an arp lookup within Windows to check IPs and their subsequent MAC addresses, you would think they’d respond in the same format they just made you type, right?
NOPE, FUCK YOU! Instead, you get a DASHED variant of a MAC address like this 12-34-56-78-91-01 This is where I almost rolled over from laughter upon seeing this absolute nightmare.
In fairness to Microsoft, and I hate saying that, Cisco does 1234.5678.9101 which is somehow worse I found, so the “everyone else agreed on colons” argument has one very large hole in it. Doesn’t make it any less archaic though, I understand not wanting to change underlying systems from the Windows NT era, but not even accepting the format everything else adopted 20 years ago is beyond believable, even for Microsoft.
My overall thoughts managing DHCP within AD.
It’s alright, if you completely ignore the absolute bastardisation of MAC address formatting, the actual MMC snap-in and GUI management of DHCP is pretty good and you can reliably find devices on specific VLANs that are un-reserved and get them a reservation very easily when it’s all set up nicely.
I appreciate it, but I am disgusted by it.
Warmly, Adam.
Cable socks: what?
Ah, to ask this question means you still have intact thumbs, not for long I’m afraid! Cable socks are a wonderful or horrible piece of kit that us IT boys deploy to rooms, workstations and the likes whenever there’s a bunch of cables that look messy and need to instead look presentable.
It’s generally a good idea to deploy cable socks in any customer facing locations to avoid people thinking you don’t take care of the premises.
They come in all shapes and forms, you have the evil plastic ones that WILL cut you, and WILL cause your thumbs to dislocate. Don’t use those ones, do not.
Then you have the happy fabric ones with lovely self-folding and stretch, those are the ones you want, they’re lovely to work with comparatively.
Other types exist, but those are the main two I’ve seen.
Avoid trying to use the plastic ones around cables that have a connection point in the run, they tend to tug in odd ways and pull out USB connections or HDMIs, ask me how I know.
So, thumbs - you like those?
Just know, with cable socks, there tends to be a specific motion you’ll get used to with your hands that will indeed put your thumbs under an enjoyable amount of strain, you will feel muscles in your hands you have never felt using these things, especially the plastic kind.
It is highly advised that you wear gloves, something light and flexible just to avoid cutting yourself especially on the plastic kind, once again — ask me how I know.
Things I wish I had going into socking
Please for the love of shit invest in a hot knife or rope cutter if you plan on running more than a handful of meters once or twice, in my case, I’ve had to run over 60 meters, and I very much wish a hot knife was available, using a Stanley blade works, but it is not efficient and you end up scratching up surfaces you don’t want to scratch or poking yourself, the plastic kind doesn’t like to cut, neither does the fabric kind.
PUT FIRE ON THEM
If you don’t have a hot knife, get a very solid pair of scissors and a lighter to seal up the ends and prevent fraying, it will fray otherwise, and won’t look amazing.
My overall thoughts on socking
This is only my first day of the workload, but there’s something really fun about it, turning mess into beautiful clean lines of fabric material just has a great serotonin to it, or I’m just autistic, not sure.
Warmly, Adam.
What in the world is an Intune?
If you ever have the enjoyable opportunity to work with Intune, it’s honestly a nice bit of kit that can sometimes feel confusing and/or deranged to those learning it. It’s a cloud service provided by Microsoft that allows you to remotely configure devices (not just Windows, not just computers) with incredibly comprehensive policies & setup flows, if you ever thought that imaging systems is archaic, Intune has your answer, obviously if you’re happy to pay the price. You heard that right, if you want Intune, you will be paying for it, Microsoft knows how nice this software is and charge reasonably for it all things considered
You do not need to purchase Intune-specific licensing if you already have 365 Education A3, please research what licenses include intune access, I almost made this mistake, for full details, see the Microsoft wiki entry.
Key takeaways so far
ESP is great when you are licensed appropriately
If you plan on using app installation through ESP (Enrollment Status Page), ensure the account testing the flow is licensed for Intune.
An unlicensed account can cause ESP to stall during application identification or installation. Licensing is not the only possible cause, however. Broken detection rules, incorrect assignments, network issues and failed installers can produce similar behaviour.
Some apps are not as simple as pointing at the Windows Store
For many enterprise and endpoint applications, the recommended Intune deployment method will be documented by the vendor, commonly as an Intune Win32 app.
A Win32 app packages MSI, EXE, PowerShell and other traditional installers into an .intunewin file.
Intune then adds the useful Ansible-like behaviour around it: requirements, detection rules, retries, assignments and installation reporting.
The device showing as assigned but not showing in devices, what gives?
This one I didn’t even think was a problem, I just assumed it was slow to reflect in the dashboard, as one thing you learn about Intune is that at times, it can be slow and feel so very outdated for how sophisticated it is.
This wasn’t one of those times, this was me being naïve during my first deployment. Turns out, the MDM url for the Intune endpoint was set incorrectly on the Intune side, so when the device tried to call home, things were not perfectly working & thus didn’t register to devices.
Your first deployment goes wrong, what now?
If you mess up the flow, don’t stress, pending things are Entra joined and Intune enrolled, you can always recover via script or application policies after the fact, Intune makes life a lot easier for remediation post-deploy.
Autopilot registration is not Intune enrolment
A device appearing under Windows Autopilot devices only means Microsoft recognises its serial number and hardware hash and knows which deployment profile it should receive.
It does not mean the current Windows installation is enrolled in Intune. The device only becomes Microsoft Entra joined and Intune managed after it completes the Autopilot flow. This distinction matters when troubleshooting devices that show an assigned Autopilot profile but do not yet appear under managed Windows devices.
Likewise, deleting an Intune managed-device record is different from deleting the Autopilot registration. Removing the Autopilot registration removes the serial-bound deployment capability, while wiping or reinstalling Windows can leave that cloud registration intact for the next OOBE.
Scope your things.
ESP, policy, deploy groups, be verbose with creating profiles & scoping relevant flows to relevant categories, pending you document it well and identify what’s what, all this does is benefit the greater I.T services team & comply wit ITIL methods.
Block mission-critical apps behind ESP, not all apps.
I learned this the slightly more hard way, thought my ESP flow was broken when in fact I had just blocked the flow by putting the entire 365 suite as a required install. This meant instead of the user getting up & running with missions critical apps, they were waiting 15-20 minutes for the ESP flow to complete, which may make your users think something is broken.
Wrapping up.
So far, my time spent with Intune has been enjoyable, I think there’s a lot I still need to peel apart and dig under, but I’m excited to do so, I’ve learned a lot of hard lessons already, I’m sure it has many more to give.
Warmly, Adam.
WIKI
Static analysis cannot prove runtime shell behavior, and shellwhy refuses to pretend otherwise. Every startup file in a report carries one of six labels:
Static mode
The default. It identifies the target shell from --shell, $SHELL, or parent-process metadata; infers login / interactive / SSH / terminal context from flags, argv, TTY state, and environment; applies the startup rules for that shell and mode; checks which files exist; and shows files skipped by precedence — bash reading only the first existing ~/.bash_profile, ~/.bash_login, or ~/.profile is the classic case. Simple source statements are parsed without evaluating shell code.
What it cannot do: prove conditional branches, dynamic paths, plugin-manager side effects, aliases, functions, exports, or PATH changes created at runtime. Those stay possible at best.
Trace mode
shellwhy trace launches a fresh target shell and observes file access through a platform backend — currently strace on Linux, with dtruss/fs_usage planned for macOS. Observed files are merged into the report as confirmed. The trade-off: trace mode runs the user’s startup code, because it starts a real shell. Use static mode when analysis must be non-invasive.
Documentation for each project, fed from Obsidian as markdown. Pick a page from the tree — or jump straight in:
From anywhere on the site: man segments in the prompt lands here.
The Machines section on this site’s home page is live homelab data. It comes from a static JSON file, /homelab-status.json, regenerated every 60 seconds — no backend behind the website, just a file push.
Pipeline
- The dashboard combines agent reports with reachability and service checks for hosts without an agent.
- A LaunchAgent runs a push script each minute: it fetches that view, projects it through a public-services allowlist, folds in 24 hours of hourly history, and uploads the result to the webroots of both sites.
- The site fetches
/homelab-status.jsonclient-side and renders the machine chassis — no JS means no section, nothing else breaks.
The allowlist is the privacy boundary: only explicitly listed services appear publicly, under display labels chosen for the site. A consolidated entry can group several internal services under one light — it shows online only when all of them are.
Payload
{
"current": {
"updated": "2026-09-11T19:00:00Z",
"machines": [
{
"id": "noc-turnus",
"label": "noc-turnus",
"online": true,
"uptime": "18d",
"services": [
{ "id": "local-prompter", "label": "Local Prompter", "online": true }
]
}
]
},
"history": []
}
The feed includes names, reachability, uptime and allowlisted service flags, with hourly history alongside the current snapshot. Retired OpenClaw is excluded, and noc-claw’s capture services are labelled as logs rather than live bots.
For noc-wardrobe, the SFTP indicator measures transport reachability, with uptime unavailable. It does not establish snapshot freshness, repository authentication or restore success.
noc-local, noc-tux and noc-claw run a FastAPI agent exposing a common HTTP API over Tailscale. The dashboard combines these reports with separate checks for hosts without an agent, including noc-turnus.
Endpoints
Unknown services 404; unknown actions 400. The logs action takes an optional line count and returns the service’s recent output.
Service registry
Each agent reads a config.yaml describing its host’s services: an id, a label, and how the service is managed. Platform handlers translate the uniform API onto the native service manager: systemctl on Linux, launchctl on macOS, and the Docker API for containers. After changing the shared catalogue, restart the affected host’s agent to load it; the dashboard then picks it up on the next poll.
The public status feed described in status API is an allowlisted projection of what these agents report.
Five service hosts run macOS and Linux across the home network and a VPS, connected over Tailscale. A Windows workstation handles gaming and GPU generation alongside them. The repository holds service configuration, deployment scripts and operational documentation.
Machines
Roles were checked against running services on 11 September 2026. noc-claw is being audited for cleanup and a future infrastructure role, with noc-turnus designated as the AI host. Its archive services remain live while preservation checks finish; gbrain does not need to remain running once its data is safely preserved. OpenClaw and its Lamb helpers remain disabled.
How it hangs together
The dashboard on noc-local uses the agent API on noc-local, noc-tux and noc-claw, alongside separate checks for other hosts. noc-turnus has Glances metrics and a private HTTPS service, while GPU generation runs on noc-gaming.
Syncthing shares the working tree directly between noc-local, noc-tux, noc-claw and noc-turnus, while noc-local remains the canonical Git writer. All six compute hosts also hold a daily encrypted recovery kit with Git history, private notes, task state and recovery keys; Kopia keeps an offsite copy on noc-wardrobe. Restoring services still requires their backed-up data and host-specific setup, and noc-turnus application-state backup onboarding remains outstanding.
A public slice of monitoring feeds the Machines section through the status JSON. Its indicators report monitored service availability.
Elsewhere
The repository is mirrored to GitHub from a self-hosted Forgejo, with selected configuration encrypted by git-crypt.
A foobar2000 component that renders animated GIF files as album art. Drop it in, point the artwork panel at a .gif, and your covers come alive — with transparency, smooth scaling, and graceful fallbacks when there’s no GIF to be found.
Features
- Animated GIF playback in the Album Art Viewer
- Static images too: JPG, PNG, WEBP, BMP
- Embedded album art fallback when no external file matches
- Transparency and smooth scaling
Install & use
Grab the pre-built .fb2k-component from the releases page and drag it into foobar2000 (or copy the .dll into components/), then add Album Art Viewer to your layout from UI elements.
Name your art files so the component finds them, next to the music:
Requires foobar2000 2.1+ (x64) on Windows 10 or newer.
Building
C++ against the foobar2000 SDK (2025-03-07+) with WTL 10, built with Visual Studio 2022 / MSBuild — the README walks through the SDK layout and the wtl.props path setup. MIT-licensed.
One header, one config struct, one lookup call.
#include <gindexer/gindexer.h>
gindexer::config cfg;
cfg.dirs = {"/home/user/music"};
cfg.splitter = split; // your artist-splitting logic
gindexer::indexer idx(std::move(cfg));
auto result = idx.lookup("Radiohead", "Creep", "Pablo Honey");
if (result) {
// result->cover — path to the cover art (or the audio file itself
// when the art is embedded; check result->embedded)
// result->artist / title / album — the matched track's tags
}
A miss means the track isn’t in the index — the watcher keeps things current, so “not indexed yet” isn’t a state you see.
Config
External cover art must sit in the same directory as the audio file it belongs to.
Building
CMake 3.27+ and a C++17 compiler. Dependencies — TagLib, efsw, LMDB, lmdbxx, Catch2 — are fetched automatically via FetchContent:
cmake -B build
cmake --build build
ctest --test-dir build --output-on-failure # with -DBUILD_TESTING=ON
A C++ library that indexes a local music collection and resolves cover art by track metadata. Written for discord-music-presence, where lookups need to be fast enough not to be noticeable: give it an artist / title / album query, get back the path to the matching cover art. If nothing matches, you get nothing back. That’s the whole thing.
How it works
Tags are read via TagLib — ID3 is the source of truth, not filenames or folder structure. The index lives in memory by default; set db_path to persist it via LMDB, which makes warm starts near-instant (the constructor returns in a few milliseconds and a background thread reconciles anything that changed while the app wasn’t running). A file watcher (efsw) keeps the index current while running.
Lookups use bigram similarity (Sørensen–Dice) so minor tag inconsistencies between what the OS reports and what’s in the file don’t cause misses. A composite score — title 50%, artist 35%, album 15% — is compared against a configurable threshold; set exact = true for strict matching instead.
Cover art resolves two ways: external files matched by case-insensitive regex (default cover\.gif), or embedded pictures read from the audio tags when embedded is on.
Performance
Benchmarked on a 4,470-track library (Windows 11, SSD), external-art mode:
Supported formats: mp3, flac, ogg, opus, m4a, aac, wav, aiff, wv, ape, mpc, wma — anything TagLib can read tags from.
Integration details live in the API page.
Segments ships as a single binary named sg. The install scripts download a pre-built binary for your platform and fall back to building from source when none is available.
macOS / Linux
curl -fsSL https://git.nocfa.net/NocFA/segments/raw/branch/main/scripts/install.sh | bash
Windows
powershell -ExecutionPolicy Bypass -Command "irm https://git.nocfa.net/NocFA/segments/raw/branch/main/scripts/install.ps1 | iex"
Installs to %USERPROFILE%\.local\bin and adds it to the user PATH. If a source build is needed, the script auto-installs Go and MinGW-w64 via winget.
From source
git clone https://git.nocfa.net/NocFA/segments.git
cd segments
make install
Quick start
sg setup # configure integrations (Pi, Claude Code, OpenCode)
sg start # start the server
Then open http://localhost:8765 for the web UI, and sg init inside a project directory to start tracking it. sg setup is the required first step — it wires the MCP server and editor integrations.
A performant, lightweight, single-binary task and project manager, written in Go. Built as a faster, leaner alternative to Beads: same job, LMDB under the hood, no Dolt, no fuss. One binary carries the CLI, a live web UI, and an MCP server for AI coding agents.
Synopsis
sg <command> [flags]
Why
Beads is slow, heavy, and leans on a Dolt DB infrastructure that is miserable to live with. Segments keeps the idea — projects, tasks, priorities, dependency chains — and drops the weight. It is especially nice for solo power users, but nothing stops you from reverse-proxying the dashboard for a team, or orchestrating downstream actions off its state.
Surfaces
Features
- Projects and tasks with priorities, statuses, dependency chains, and rich-text bodies
- Three interchangeable web themes (Obsidian, Console, Dossier), each with light and dark modes
- Three views: grouped List, drag-and-drop Kanban, and a top-down dependency Graph
- Real-time updates over WebSocket — edits from another tab, the CLI, or an MCP agent show up live
- Command palette and full keyboard-first navigation
sg nextto pick the best unblocked task,sg statsfor a progress dashboard,sg exportfor JSONL snapshots- Beads import for migrating an existing backlog
Status
Work in progress, but stable enough for daily use. Release series so far: 0.1 foundation (LMDB storage, core CLI, first MCP integrations, basic web UI), 0.2 TUI ergonomics and Windows support, 0.3 the three-theme GUI with Graph/Kanban/List views, 0.4 (current) MCP and session polish — globally addressable task IDs, SessionStart hooks, a stdio shim for multi-client MCP. 0.5 targets optimisation, 0.6 GUI polish.
Start with install.
Segments speaks MCP so coding agents can plan against the same task state you see in the CLI and web UI. sg setup wires the integrations: Claude Code, OpenCode, and a Pi extension embedded in the binary for task-aware AI sessions.
Scoping
Every tool call auto-resolves the current project from the agent’s working directory — an MCP call from inside a repo is about that repo’s tasks unless the agent explicitly asks otherwise (all_projects=true, or --all on the CLI). Task IDs are globally addressable: a full UUID or unique prefix resolves across all projects.
Tools
Session integration
A SessionStart hook prints an orientation banner — in-progress claims, recently closed tasks — so an agent starts each session knowing the state of play. Agents claim work by setting a task in-progress, which every other session and the web UI see live. A stdio shim lets multiple MCP clients share one server instance.
Changes made by agents surface in the web UI over WebSocket as they happen, which makes it easy to watch an agent burn through a queue.
sg start serves a live dashboard at http://localhost:8765. Pick a theme from the dropdown in the top bar — each supports light and dark modes.
Views
Real-time
Every tab connects over WebSocket and receives live deltas for task and project changes, whether those come from another tab, the CLI, or an MCP agent. New tasks slide in; edits pulse briefly.
Keyboard
Ctrl+K / Cmd+K opens a command palette that fuzzy-jumps between projects, views, and tasks. Beyond that:
An aggregated All tasks scope spans every project, plus a ready-queue filter for tasks with no outstanding blockers.
Static analysis cannot prove runtime shell behavior, and shellwhy refuses to pretend otherwise. Every startup file in a report carries one of six labels:
Static mode
The default. It identifies the target shell from --shell, $SHELL, or parent-process metadata; infers login / interactive / SSH / terminal context from flags, argv, TTY state, and environment; applies the startup rules for that shell and mode; checks which files exist; and shows files skipped by precedence — bash reading only the first existing ~/.bash_profile, ~/.bash_login, or ~/.profile is the classic case. Simple source statements are parsed without evaluating shell code.
What it cannot do: prove conditional branches, dynamic paths, plugin-manager side effects, aliases, functions, exports, or PATH changes created at runtime. Those stay possible at best.
Trace mode
shellwhy trace launches a fresh target shell and observes file access through a platform backend — currently strace on Linux, with dtruss/fs_usage planned for macOS. Observed files are merged into the report as confirmed. The trade-off: trace mode runs the user’s startup code, because it starts a real shell. Use static mode when analysis must be non-invasive.
The daily loop Segments is built around: capture everything, then always know what to pick up next.
sg init # once, in the project directory
sg add # capture work as it appears
sg next # what should I do now?
sg done <id> # ship it
The ready queue
A task is ready when it is a todo with no outstanding blockers. sg next ranks the ready queue — highest priority first, oldest wins ties — and prints the best pick followed by the rest. Dependency chains (task B blocked by task A) keep downstream work out of the queue until its blockers land.
Priorities
Projects
sg list scopes to the project matching the working-directory name, so a plain sg list inside a repo shows that repo’s tasks. The web UI’s All tasks scope aggregates across every project when you want the portfolio view.
Snapshots and migration
sg export streams task state as JSONL — one event per line — suitable for git-tracked snapshots or downstream pipelines. Configure a path in config.yaml to have every CLI / MCP mutation append automatically. Coming from Beads, sg beads imports an existing backlog wholesale.
The full command surface of sg. Aliases are shown in parentheses.
Server
Tasks
Setup
Maintenance
Info
How these compose day to day is covered in workflow.
shellwhy answers a practical dotfiles question: “why is my shell doing this?” It inspects the current or requested shell mode, applies startup-file rules, safely parses obvious source statements, detects common shell tooling hooks, and reports what is inferred, possible, missing, skipped, or observed. Written in Rust; MIT/Apache-2.0 dual-licensed.
There was no standardised way to check how a shell is configured and which files are affecting the running process — this is that tool.
Features
- Static startup-file rules for
bash,zsh, andfish, with conservative fallbacks forsh/dash,ksh/mksh,tcsh/csh, andnu - Safe static parsing for obvious
source fileand. filestatements — no shell code is executed - Detection for common tooling hooks:
starship,oh-my-zsh,zinit,direnv,asdf,pyenv,nvm,fnm,fisher,tide - Human-readable, plain, and JSON output
- Linux trace mode using
straceto observe what actually loads
Usage
shellwhy # infer and explain the current shell
shellwhy --shell bash # explain bash startup for this user
shellwhy --shell zsh --login --interactive # a specific mode
shellwhy --shell bash --json # machine-readable
shellwhy trace --shell fish # observe via strace (Linux)
shellwhy explain # why shell-startup certainty is hard
Install
cargo install --path . # from a checkout
Every reported file carries a confidence label rather than a pretence of certainty — the confidence model is the core design idea.