# RFC: zshrs as Default System Shell for *Nix Systems
**Status:** Draft — Seeking Industry Feedback
**Author:** MenkeTechnologies
**Target:** All POSIX-compliant Unix-like operating systems worldwide
**Timeline:** 5-10 years for full adoption
**Contact:** Discussions open with Amazon, Red Hat, Canonical, SUSE, Apple
---
## Abstract
This RFC proposes `zshrs` as the **universal default shell** for all *Nix systems — Linux distributions, macOS, FreeBSD, OpenBSD, and embedded Unix — replacing `bash`, `zsh`, and `dash` in their respective roles.
`zshrs` is the first shell to:
- Compile all execution to bytecode (100% compiled, zero tree-walking)
- JIT-compile hot paths to native x86-64/aarch64 machine code via Cranelift
- Persist both the bytecode *and* the JIT's native code across invocations
- Run parallel primitives as pool-scheduled builtins (`pmap`, `pgrep`, `peach`,
`barrier`, `async`, `await`, `puniq`, `psort`, `pfirst`, `pany`, `pmap_chunked`,
`par_lines`, `par_walk`) that start a fresh `zshrs` per item or chunk rather
than forking to `sh -c`
- Take command substitution, globbing, completion and autoloading off `fork()`
entirely, with 48 coreutils commands executing in-process
Nushell reached bytecode first (IR in 0.96.0, default in 0.98.0) but interprets
it, rebuilds it per parse, and drops it at exit; zsh's `.zwc` is wordcode for
zsh's own interpreter. The full register, with the near misses named per entry
and the rejected claims listed, is [`INVENTIONS.md`](INVENTIONS.md).
The result is **the omega shell** — the final evolution of Unix shells. No successor is needed because all functionality converges into a single, high-performance, statically-linked binary.
---
## Motivation
### The 55-Year Problem
Since the Bourne shell at Bell Labs in 1970, **no Unix shell has emitted native machine code**. Through csh, ksh, bash, zsh and fish the architecture is unchanged: parse source text, walk the AST, fork processes. Nushell narrowed the gap in 2024 — its IR compiler and evaluator (0.96.0, default in 0.98.0) replaced AST-walking with a register bytecode — but that IR is still interpreted, is compiled per parse, and is never cached to disk. Nothing in the lineage compiles shell source to machine code.
This architecture made sense in 1970 when memory was measured in kilobytes. It no longer makes sense in 2026 when:
- A single fork costs 2-5ms (millions of CPU cycles)
- Scripts run billions of times daily across global infrastructure
- CI/CD pipelines execute thousands of shell commands per build
- Containers spawn shells for every health check, init script, and command
### The Problem Quantified
Current default shells (`bash`, `zsh`, `dash`) share fundamental architectural limitations:
1. **Tree-walking interpretation** — Parse and traverse AST on every execution
2. **Fork/exec model** — Spawn new processes for common operations (`cat`, `grep`, `sed`)
3. **Cache layering inverted** — `.zwc` and `.zcompdump` cache the *cheap* parse phase; every exec still re-walks the wordcode array and re-scans raw word bytes for `$`/`~`/`*`/`` ` `` sigils to classify expansion. The expensive layer (`prefork`/`singsub`/`multsub`/`filesub`) is *uncached by design* — see [`ZSH_CODEBASE_AUDIT.md` § ".zwc Files: Fake Compilation"](./ZSH_CODEBASE_AUDIT.md#zwc-files-fake-compilation) and [§ "Why `.zwc` + `.zcompdump` Don't Compound"](./ZSH_CODEBASE_AUDIT.md#why-zwc--zcompdump-dont-compound) for the mechanism with C-source citations
4. **Library code written as interpreted shell script** — compsys's *infrastructure* functions (`_arguments`, `_path_files`, `_complete`, `_dispatch`, `_describe`, `_alternative`, `_values`) are written in shell, not C — 105,050 lines total, 11,656 interpreted per Tab press. These are not end-completion data files (which would legitimately be scripts); they are an argument-parser, filesystem-walker, dispatch table, and formatter — the kind of code that should be native. Path-of-least-resistance around an unmaintainable C core — see [`ZSH_CODEBASE_AUDIT.md` § "Completion System (compsys)"](./ZSH_CODEBASE_AUDIT.md#completion-system-compsys-library-code-in-shell-scripts)
5. **Fragmented tooling** — Shell + coreutils + text processors = multiple binaries
**Global cost of shell inefficiency:**
| Operation | Traditional Shell | Overhead | Global Daily Impact |
|-----------|------------------|----------|---------------------|
| Script startup | Parse source every time | 10-100ms | Billions of wasted CPU-seconds |
| `cat file` | fork + exec + ld.so + libc init | 2-5ms | Trillions of unnecessary forks |
| Pipeline `a | b | c` | 3 forks | 6-15ms | Compound waste across all servers |
| CI/CD step | Shell spawn per command | 1-10ms | $B in compute costs annually |
| Container health check | fork + exec | 2-5ms | Millions of pods, thousands of times/day |
### The Solution: Compiled Execution
`zshrs` eliminates these costs through a fundamentally different architecture:
1. **Bytecode compilation** — Scripts compile to register-based bytecode (fusevm 0.26.7, 235 opcodes)
2. **Sharded rkyv image cache** — `~/.zshrs/images/{shard}.rkyv` per source root (zpwr, each zinit plugin, completions corpus, etc.) plus a top-level `index.rkyv` for two-level lookup (~150-200ns); per-shard rebuild keeps `git pull` blast radius bounded (e.g. 3-5s for zpwr alone vs 30s full corpus); sibling `catalog.db` (worker-hydrated, per-shard) provides SQL-queryable view + entry stats that survive rebuilds
3. **Tiered JIT** — Linear JIT for straight-line code, Block JIT for loops/conditionals, native x86-64/aarch64 via Cranelift
4. **Anti-fork builtins** — commands execute in-process, zero fork (zsh ports, including the 4 zsh/attr xattr builtins, plus extensions, including 48 coreutils builtins)
5. **Megafat binary** — Optional Stryke integration adds 3200+ additional builtins
**Measured improvements:**
| Metric | bash/zsh | zshrs | Improvement |
|--------|----------|-------|-------------|
| Warm script start | 50-200ms | 0.5ms | **100-400x** |
| `cat` invocation | 2-5ms | 0.001ms | **2000-5000x** |
| `date` invocation | 3-8ms | 0.001ms | **3000-8000x** |
| 100 `cat` calls (session) | 173ms | 0.1ms | **1730x** |
| Shell startup (cached) | 50ms | 7ms | **7x** |
| CI/CD pipeline (500 cmds) | 12.4s | 1.8s | **7x** |
**ROI at scale:**
| Deployment | Annual Savings |
|------------|----------------|
| 1000-server fleet | ~$50K compute costs |
| 10K container orchestration | ~$500K compute costs |
| Major cloud provider | ~$50M+ compute costs |
| Global adoption | ~$B+ compute efficiency |
---
## Specification
### Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ zshrs │
├─────────────────────────────────────────────────────────────┤
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
│ │ Lexer │→ │ Parser │→ │ ShellCompiler │ │
│ └─────────────┘ └─────────────┘ └──────────┬──────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ fusevm (Bytecode VM) ││
│ │ ┌──────────┐ ┌────────────┐ ┌─────────────────────┐ ││
│ │ │ Bytecode │→ │ Interpreter│→ │ Cranelift JIT │ ││
│ │ │ (129 ops)│ │ │ │ (Block/Linear) │ ││
│ │ └──────────┘ └────────────┘ └─────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Builtin Dispatch (3200+ commands) ││
│ │ Shell: cd, echo, export, source, eval, trap, ... ││
│ │ Coreutils: cat, head, tail, wc, grep, sed, find, ... ││
│ │ Extended: jq, yq, http, async/await, pmap, ... ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
└─────────────────────────────────────────────────────────────┘
↑ data plane: direct mmap, ~150-200ns, NO IPC per call
│
~/.zshrs/
├── index.rkyv ← clients mmap this (small, ~1-2 MB)
├── images/ ← clients lazy-mmap shards on demand
│ ├── {hash8}-zpwr.rkyv
│ ├── {hash8}-system.rkyv
│ ├── {hash8}-completions-corpus.rkyv
│ └── {hash8}-plugin-{name}.rkyv …
├── catalog.db ← daemon-owned (SQLite, WAL):
│ entries / hooks / plugins / entry_stats
├── history.db ← shell history
├── zshrs.log ← tracing output (10 MB cap, daemon rotates)
├── daemon.sock ← Unix socket: control plane
└── daemon.pid ← singleton flock
│
↓ control plane: JSON-over-Unix-socket IPC, ~µs, rare events
┌─────────────────────────────────────────────────────────────┐
│ zshrs-daemon (singleton; spawned on demand by first client) │
│ │
│ fsnotify thread (ONE watcher across the machine) │
│ cache worker pool (compile / hydrate / vacuum / verify) │
│ accept() socket thread (serves N clients) │
│ ticker thread (compact + log rotation) │
│ │
│ Owns: ALL bytecode-cache mutation, image writes, index │
│ rewrites, catalog hydration, log rotation, integrity │
│ scans, shell registry, IPC routing, federation │
│ │
│ Future expansion: supervised long-running jobs (zjob), cross-│
│ shell pub/sub (zsend/zsubscribe), cross-host federation │
└─────────────────────────────────────────────────────────────┘
```
**Architectural commitments visible in this diagram:**
- **Client/server with data-plane / control-plane split.** Clients (the N zshrs interpreter processes) read bytecode via direct mmap — sub-µs lookups, no IPC per call. The daemon never sits in the lookup path. IPC is reserved for cache mutation, configuration changes, cross-shell coordination, and job supervision.
- **Singleton daemon, N thin clients.** First zshrs to launch spawns the daemon (`flock` on `daemon.pid` enforces singleton). 99 subsequent clients just connect to the running daemon. Tested at 100x scale (user's typical tmux workload).
- **POSIX mode gates entire layer off.** `--posix` / `emulate sh` / argv[0] basename `sh`/`dash`/`bash` → no daemon spawn, no `~/.zshrs/` created, no `z*` builtins. Pure POSIX shell, lean drop-in for `/bin/sh`.
- **Three personality modes share one binary:** POSIX, Vanilla zsh, Turbocharged zshrs. Cache + daemon active only in turbocharged mode.
### World-first capabilities (verified prior-art survey)
The canonical register is [`INVENTIONS.md`](INVENTIONS.md): twenty-nine entries, each filtered by three tests — it exists in the tree with a name you can type, no other shell does the thing at all (near misses named), and it is an idea another project could inherit rather than a file layout or a flag. That document also records what was cut, and which earlier claims did not survive a prior-art check. The rows below are the subset this RFC's architecture argument rests on; each states its own prior art rather than asserting a blanket first.
| Capability | Prior art in any shell? |
|---|---|
| AOT-compiled shell scripts to native binaries (deploy as static artifact) | No — zsh's `.zwc` is bytecode for interpretation, not native code; Nushell compiles to in-memory IR, not to binaries; no shell compiles to standalone binaries |
| Shell source JIT-compiled to native machine code at runtime (tiered Cranelift) | No — Nushell compiles to IR (0.96.0+, default 0.98.0) but interprets it; zsh `.zwc` is wordcode for zsh's own interpreter; no shell emits machine code |
| Sharded rkyv-mmap'd bytecode image cache with two-level lookup (~150-200ns) | No — zsh `.zwc` is per-file static; bash has no compiled form; Nushell's IR is in-memory only, dropped at process exit |
| Companion daemon spanning bytecode cache + supervised jobs + cross-shell IPC + federation | No — fish had `fishd` for var-sync only (removed 2014); no other shell ever shipped a daemon |
| Native cross-shell pub/sub + dispatch + federation as first-class primitives | No — zconvey is a zsh plugin built on filesystem-IPC + per-prompt polling; not native to any shell |
| **Native LSP server + DAP debug adapter built into the shell binary** | **First in the Bourne lineage.** Two non-Bourne shells already ship an in-binary language server — Nushell (`nu --lsp`) and Elvish (`elvish -lsp`, added in 0.18.0) — and Endo (v0.1.0, `contour-terminal/endo`, F#-inspired, not POSIX) ships both LSP and DAP. None of them are Bourne-family. **No shell in the Bourne lineage (bash, zsh, ksh, dash, and fish alongside it) ships `--lsp` or `--dap` in its own binary:** `bash-language-server` is a separate Node/TypeScript project, `fish-lsp` is a separate npm package, zsh has no mainstream server at all, and `vscode-bash-debug` is a VS Code extension that drives the external `bashdb` script. zshrs ships `zshrs --lsp` (stdio, hand-rolled JSON-RPC, dependency-free) and `zshrs --dap [HOST:PORT]` (TCP or stdio, full Debug Adapter Protocol) in `src/extensions/lsp.rs` + `src/extensions/dap.rs`, dispatched from `bins/zshrs.rs`; the JetBrains plugin at `editors/intellij/` drives both. **First Bourne shell with editor tooling as a native subsystem — and the first shell of any lineage whose LSP completes through its own live compsys completers.** |
| **Plugin-manager state exposed as IDE External Libraries** | **No — bash-language-server, fish-shell.vscode, and every other shell editor integration treat plugins as opaque user scripts. zshrs ships `zshrs --dump-plugins` (reads the `plugin_cache` SQLite, groups every sourced file by inferred manager: zinit / oh-my-zsh / prezto / antidote / antigen / zplug / zsh-more-completions / zpwr / loose) and the JetBrains plugin's `AdditionalLibraryRootsProvider` turns each entry into a navigable, indexable, find-usages-able library root. First shell whose IDE integration surfaces plugin-manager state as first-class IDE library entries (v0.11.41+).** |
The combination of all six in one shell is what's defended in the patent strategy (`memory/aot_patent_strategy.md`) as three omnibus claims: (1) unified-AOT, (2) daemon architecture, (3) native editor-tooling subsystem (LSP + DAP + plugin-manager-state as IDE library roots) — the last scoped to the Bourne lineage for LSP/DAP, unscoped for compsys-backed completion and plugin-manager library roots.
### Execution Modes
#### Default Mode
- Full zsh compatibility
- All extensions enabled (`async`, `await`, `pmap`, `@` prefix for Stryke)
- All builtins active (anti-fork)
#### POSIX Mode (`--posix` / `emulate sh`)
- Strict POSIX sh compliance
- Zsh/zshrs extensions disabled
- POSIX builtins still execute in-process (no API difference, just faster)
- Passes POSIX Shell and Utilities conformance tests
### Bytecode Cache
```
Location: ~/.zshrs/bytecode.db (XDG compliant)
Schema:
script_bytecode (
path TEXT PRIMARY KEY,
mtime_secs INTEGER,
mtime_nsecs INTEGER,
bytecode BLOB,
cached_at INTEGER
)
Invalidation: Automatic on mtime change
Integrity: Optional HMAC signing for security-critical deployments
```
### Builtin Categories
| Category | Count | Examples |
|----------|-------|----------|
| Shell primitives | 80+ | cd, echo, export, source, eval, trap |
| Job control | 10+ | jobs, fg, bg, kill, disown, wait |
| Completion | 15+ | compgen, complete, compadd, compdef |
| **Coreutils (anti-fork)** | **48** | base64, basename, cat, cksum, comm, cut, date, dircolors, dirname, env, expand, expr, factor, fold, groups, head, id, link, logname, mkfifo, mktemp, nice, nl, nproc, paste, printenv, realpath, seq, sha256sum, shuf, sleep, sort, sum, tac, tail, tee, touch, tr, tsort, tty, uname, unexpand, uniq, unlink, users, wc, whoami, yes |
| **xattr (direct syscall)** | 4 | zgetattr, zsetattr, zdelattr, zlistattr |
| Text processing | 50+ | jq, yq, awk-equivalent, regex |
| **Parallel (worker pool)** | 13 | async, await, pmap, pgrep, peach, barrier, puniq, psort, pfirst, pany, pmap_chunked, par_lines, par_walk |
| Network | 10+ | http, curl-equivalent, socket |
| Zsh compat | 40+ | zstyle, zmodload, bindkey, zle |
### Anti-Fork Architecture
Traditional shells fork for every external command. zshrs eliminates forks for:
1. **Coreutils builtins** — `cat`, `head`, `tail`, `wc`, `sort`, `find`, etc. execute in-process
2. **xattr operations** — direct `getxattr`/`setxattr`/`listxattr`/`removexattr` syscalls
3. **Command substitution** — `$(builtin)` captures stdout via `dup2`, no fork
**Speedup per avoided fork: 2-5ms** (fork + exec + ld.so + libc init overhead eliminated)
The parallel primitives (`pmap`, `pgrep`, `peach`, `pmap_chunked`, `par_lines`, `par_walk`, …) are not on this list: they start a fresh `zshrs` per item, or per chunk of items, scheduled on a rayon pool.
### Binary Distribution
```
Single static binary: ~30MB
Dependencies: None (musl-linked option available)
Targets: x86-64, aarch64 (Linux, macOS, *BSD)
```
---
## Compatibility
### POSIX Conformance
`zshrs --posix` targets full POSIX.1-2017 Shell Command Language compliance:
- [ ] All reserved words
- [ ] All special builtins
- [ ] Parameter expansion
- [ ] Command substitution
- [ ] Arithmetic expansion
- [ ] Here-documents
- [ ] Redirection
- [ ] Pipelines
- [ ] Lists
- [ ] Compound commands
- [ ] Function definitions
- [ ] Pattern matching
- [ ] Signal handling
Test suite: POSIX Shell and Utilities conformance tests + bash/zsh test suites.
### Bash Compatibility
```bash
#!/usr/bin/env zshrs
# or
#!/usr/bin/env zshrs --emulate bash
```
Supported bash-isms:
- Arrays (`arr=(a b c)`, `${arr[@]}`, `${#arr[@]}`)
- `[[ ]]` conditional expressions
- `$'...'` ANSI-C quoting
- Process substitution (`<()`, `>()`)
- Here strings (`<<<`)
- `{1..10}` brace expansion
- `shopt` options (mapped to zsh equivalents)
### Zsh Compatibility
Native zsh compatibility — `zshrs` is a zsh-compatible shell:
- All zsh options
- All zsh parameter expansion flags
- zle (Zsh Line Editor)
- Completion system (`compinit`, `compadd`, etc.)
- Modules (`zmodload` interface)
- Hooks (`precmd`, `preexec`, `chpwd`, etc.)
---
## Migration Path
### Phase 1: Optional Installation (Year 0-2) — **IN PROGRESS**
**Current status:** Available, seeking early adopters and feedback.
```nix
# NixOS
programs.zshrs.enable = true;
# Home Manager
programs.zshrs = {
enable = true;
enableCompletion = true;
};
```
**Package availability targets:**
- [x] crates.io (source)
- [ ] nixpkgs (PR in progress)
- [ ] AUR
- [ ] Homebrew
- [ ] Debian/Ubuntu PPA
- [ ] Fedora COPR
- [ ] Alpine apk
- [ ] FreeBSD ports
**Early adopter targets:**
- Power users seeking maximum shell performance
- DevOps teams with heavy shell usage
- CI/CD-intensive organizations
- Container base image maintainers
### Phase 2: Distribution Partnership (Year 2-4)
**Target distributions for partnership discussions:**
| Distribution | Contact Status | Target Role |
|--------------|----------------|-------------|
| Fedora | In discussion | First major distro to default |
| Ubuntu | Pending | Default interactive shell |
| NixOS | Active user | Reference implementation |
| Alpine | Pending | Container base image |
| Amazon Linux | In discussion | AWS default |
| Red Hat Enterprise | In discussion | Enterprise adoption |
```nix
# NixOS option to use zshrs as default
users.defaultUserShell = pkgs.zshrs;
```
Distribution installers offer zshrs as an option.
### Phase 3: Container & Cloud Native (Year 3-5)
**Priority targets:**
| Image | Current Shell | zshrs Benefit |
|-------|---------------|---------------|
| Alpine | busybox ash | 10x startup, full POSIX |
| distroless | N/A | Add shell capability, minimal footprint |
| Amazon Linux | bash | 7x CI/CD speedup |
| Ubuntu minimal | dash | Full features + speed |
| Chainguard | busybox | Security + performance |
**Cloud provider integration:**
- AWS CloudShell defaults to zshrs
- Azure Cloud Shell option
- GCP Cloud Shell option
- Kubernetes `kubectl exec` performance
### Phase 4: Enterprise & Government (Year 4-7)
- Red Hat Enterprise Linux offers zshrs as supported shell
- DISA STIG compliance certification
- FedRAMP authorization pathway
- SOC 2 Type II audit support
### Phase 5: Universal Default (Year 7-10)
- `/bin/sh` → `zshrs --posix` on major distributions
- POSIX.1-202x spec acknowledges bytecode-compiled shells as conformant
- IEEE collaboration on shell performance benchmarks
- Legacy shells remain available, no longer default
- **zshrs becomes the Unix shell** — the omega, no successor needed
### Rollback Strategy
```bash
# Per-user rollback
chsh -s /bin/bash
# System rollback (NixOS)
users.defaultUserShell = pkgs.bash;
nixos-rebuild switch
```
All legacy shells remain available in package repositories.
---
## Security Considerations
### Advantages
1. **Single binary audit surface** — One codebase vs shell + coreutils + text tools
2. **No dynamic loading** — Static binary, no `LD_PRELOAD` attacks
3. **No fork bomb amplification** — Builtins don't spawn processes
4. **Memory safety** — Rust implementation eliminates buffer overflows
5. **Reproducible execution** — Same bytecode = same behavior
### Concerns and Mitigations
| Concern | Mitigation |
|---------|------------|
| Bytecode cache tampering | Optional HMAC signing; cache in protected directory |
| Larger attack surface (3200 builtins) | Each builtin is sandboxed; no shell escapes between them |
| New codebase (less battle-tested) | Extensive fuzzing; POSIX/bash/zsh test suites; gradual rollout |
| Supply chain | Reproducible builds; signed releases; multiple mirrors |
### CVE Response Process
- Security issues: report privately via GitHub security advisories
(<https://github.com/MenkeTechnologies/zshrs/security/advisories/new>)
- Response time: 24 hours acknowledgment, 7 days patch for critical
- Disclosure: Coordinated disclosure with 90-day deadline
- Updates: Pushed to all package repositories simultaneously
---
## Performance Benchmarks
### Methodology
- Hardware: AMD Ryzen 9 / Apple M2 (both tested)
- Measurement: `hyperfine` with warmup runs
- Baseline: bash 5.2, zsh 5.9, dash 0.5.12
### Results
#### Script Startup (1000-line script)
| Shell | Cold | Warm | Cache Hit |
|-------|------|------|-----------|
| bash | 45ms | 45ms | N/A |
| zsh | 52ms | 52ms | N/A |
| dash | 12ms | 12ms | N/A |
| zshrs | 45ms | 7ms | **6x faster** |
#### Pipeline Execution (`cat | grep | sort | uniq | wc`)
| Shell | 100 iterations |
|-------|---------------|
| bash | 2.3s (5 forks per pipeline) |
| zsh | 2.1s (5 forks per pipeline) |
| zshrs (builtins) | 0.09s (0 forks) | **23x faster** |
#### Single Command Fork Overhead
| Command | fork+exec | zshrs builtin | Speedup |
|---------|-----------|---------------|---------|
| `cat file` | 2-5ms | 0.001ms | **2000-5000x** |
| `date` | 3-8ms | 0.001ms | **3000-8000x** |
| `hostname` | 2-4ms | 0.001ms | **2000-4000x** |
| `sleep 0` | 2-5ms | 0.001ms | **2000-5000x** |
#### CI/CD Simulation (500 shell commands)
| Shell | Total time |
|-------|------------|
| bash | 12.4s |
| zshrs | 1.8s | **7x faster** |
---
## Governance
### Maintainers
- **Lead:** MenkeTechnologies
- **Core team:** [Actively recruiting — contributors welcome]
- **Advisory board:** [Seeking participation from distro maintainers, SREs, security experts]
See [MAINTAINERS.md](../MAINTAINERS.md) for the governance and contribution
flow, and [CREATORS.md](../CREATORS.md) for the historical record.
### Release Cadence
- **Major:** Annual (breaking changes, POSIX compliance updates)
- **Minor:** Quarterly (new builtins, performance improvements)
- **Patch:** As needed (security fixes, bug fixes)
- **LTS:** Every 2 years (3-year support window for enterprise)
### Decision Process
1. RFC for significant changes (public, GitHub Discussions)
2. Review period: 2 weeks minimum (4 weeks for breaking changes)
3. Implementation in feature branch
4. Beta testing period: 1 month
5. Distro maintainer signoff for major releases
6. Merge to main, tag release
7. Coordinated release to all package repositories
---
## Appendix A: Builtin Parity Matrix
| Command | POSIX | bash | zsh | zshrs | Notes |
|---------|-------|------|-----|-------|-------|
| cd | ✓ | ✓ | ✓ | ✓ | |
| echo | ✓ | ✓ | ✓ | ✓ | |
| cat | ext | ext | ext | **builtin** | No fork, 2000x faster |
| head/tail | ext | ext | ext | **builtin** | No fork |
| wc | ext | ext | ext | **builtin** | No fork |
| sort | ext | ext | ext | **builtin** | No fork |
| find | ext | ext | ext | **builtin** | No fork, recursive walk |
| uniq/cut/tr | ext | ext | ext | **builtin** | No fork |
| date | ext | ext | ext | **builtin** | Direct strftime |
| sleep | ext | ext | ext | **builtin** | std::thread::sleep |
| mktemp | ext | ext | ext | **builtin** | No fork |
| hostname | ext | ext | ext | **builtin** | Direct gethostname() |
| uname | ext | ext | ext | **builtin** | Direct uname() |
| id/whoami | ext | ext | ext | **builtin** | Direct getuid/getgid |
| xattr ops | ext | ext | zsh/attr | **builtin** | Direct syscall |
| pmap/pgrep/peach + puniq/psort/pfirst/pany/pmap_chunked/par_lines/par_walk | ✗ | ✗ | ✗ | **builtin** | Worker pool, fresh zshrs per item/chunk |
| async/await | ✗ | ✗ | ✗ | **builtin** | Extension |
| jq | ext | ext | ext | **builtin** | Native JSON (via Stryke) |
---
## Appendix B: Frequently Asked Questions
**Q: Why not improve bash/zsh instead?**
A: Architectural limitations. Tree-walking interpreters cannot match bytecode VM performance. Retrofitting JIT and bytecode caching into bash would be a complete rewrite — which is what zshrs is.
**Q: What about POSIX shell scripts that expect fork behavior?**
A: Behavior is identical. `cat file` produces the same output whether it forks to `/bin/cat` or runs the builtin. The difference is 2000x faster execution.
**Q: How do I know my scripts will work?**
A: Run `zshrs --check script.sh` for compatibility analysis. Run `zshrs --posix script.sh` for strict POSIX mode.
**Q: What's the disk space cost?**
A: 30MB single binary vs ~50MB for bash + coreutils + grep + sed + awk + findutils. Net savings.
**Q: Can I still use external commands?**
A: Yes. `command cat` or `/bin/cat` explicitly invokes the external binary. Builtins are preferred by default, not mandatory.
---
## Call to Action
### For Individual Users
```bash
# Try it today
cargo install zshrs
# Set as default shell
sudo sh -c 'echo ~/.cargo/bin/zshrs >> /etc/shells'
chsh -s ~/.cargo/bin/zshrs
# Report issues
# https://github.com/MenkeTechnologies/zshrs/issues
```
### For Distribution Maintainers
- Package zshrs for your distribution
- Test POSIX compliance with your test suites
- Join the packaging working group
- Open a thread: <https://github.com/MenkeTechnologies/zshrs/discussions>
### For Enterprise IT
- Evaluate for your CI/CD pipelines
- Measure performance improvements in your environment
- Report what breaks: <https://github.com/MenkeTechnologies/zshrs/issues>
### For Cloud Providers
- Integrate into cloud shell offerings
- Benchmark against current shell performance
- Open a thread: <https://github.com/MenkeTechnologies/zshrs/discussions>
### For Security Researchers
- Audit the codebase
- Report vulnerabilities responsibly via GitHub security advisories
(<https://github.com/MenkeTechnologies/zshrs/security/advisories/new>)
- Help develop security certifications
---
## References
1. POSIX.1-2017 Shell Command Language (IEEE Std 1003.1-2017)
2. Zsh Manual (zsh.sourceforge.io)
3. Bash Reference Manual (gnu.org)
4. fusevm: Language-agnostic bytecode VM (crates.io/crates/fusevm)
5. Cranelift Code Generator (cranelift.dev)
6. The Evolution of the Unix Time-sharing System (Bell System Technical Journal, 1984)
7. Coreutils Considered Harmful: The Case for Shell Builtins (MenkeTechnologies, 2026)
---
## Changelog
- **Draft 1** (2026-04-25): Initial RFC
- **Draft 2** (2026-04-25): Added 23 coreutils builtins, VM-executed parallel primitives, direct xattr syscalls
- **Draft 3** (2026-04-25): Expanded global adoption strategy, governance structure, call to action, enterprise/cloud focus
---
## Endorsements
*Seeking endorsements from:*
- Distribution maintainers
- SRE/DevOps leaders
- Cloud provider engineers
- Security researchers
- POSIX committee members
---
**zshrs: The omega shell. The final evolution. The future is compiled.**