Project 16: Structured Data Shell (Nushell-Inspired)

A modern shell where pipelines pass structured data (tables, records) instead of text. Commands like ls return a table, where size > 1mb filters rows, and data flows as first-class values.

Quick Reference

Attribute Value
Primary Language Rust
Alternative Languages Go, OCaml, F#
Difficulty Level 4: Expert (The Systems Architect)
Time Estimate 1-2 months
Knowledge Area Language Design / Data Processing
Tooling Nushell
Prerequisites Projects 1-10, familiarity with Rust or similar

What You Will Build

A modern shell where pipelines pass structured data (tables, records) instead of text. Commands like ls return a table, where size > 1mb filters rows, and data flows as first-class values.

Why It Matters

This project builds core skills that appear repeatedly in real-world systems and tooling.

Core Challenges

  • Data types (tables, records, lists, primitives) → maps to type systems
  • Type-preserving pipelines (data flows, not text) → maps to functional programming
  • Query language (where, select, sort operations) → maps to DSL design
  • External command integration (parsing text output into tables) → maps to interoperability
  • Pretty printing (rendering tables, handling terminal width) → maps to presentation

Key Concepts

  • Nushell philosophy: “Philosophy” - Nushell Contributor Book (nushell.sh)
  • Structured data in shells: “The case for Nushell” by Sophia Turner (blog)
  • PowerShell objects: “PowerShell in Action” by Bruce Payette (for comparison)

Real-World Outcome

$ ./nush
nush> ls
╭───┬──────────────┬──────┬───────────┬──────────────╮
│ # │     name     │ type │   size    │   modified   │
├───┼──────────────┼──────┼───────────┼──────────────┤
│ 0 │ Cargo.toml   │ file │   1.2 KB  │ 2 hours ago  │
│ 1 │ src          │ dir  │   4.0 KB  │ 1 hour ago   │
│ 2 │ README.md    │ file │   3.5 KB  │ 3 days ago   │
╰───┴──────────────┴──────┴───────────┴──────────────╯

nush> ls | where size > 2kb | sort-by modified
╭───┬──────────────┬──────┬───────────┬──────────────╮
│ # │     name     │ type │   size    │   modified   │
├───┼──────────────┼──────┼───────────┼──────────────┤
│ 0 │ src          │ dir  │   4.0 KB  │ 1 hour ago   │
│ 1 │ README.md    │ file │   3.5 KB  │ 3 days ago   │
╰───┴──────────────┴──────┴───────────┴──────────────╯

nush> open data.json | get users | where age > 30
╭───┬─────────┬─────┬──────────────────╮
│ # │  name   │ age │      email       │
├───┼─────────┼─────┼──────────────────┤
│ 0 │ Alice   │  35 │ alice@email.com  │
│ 1 │ Charlie │  42 │ charlie@mail.org │
╰───┴─────────┴─────┴──────────────────╯

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: SHELL_INTERNALS_DEEP_DIVE_PROJECTS.md
  • “Domain-Driven Design” by Eric Evans