GO — Healthy across the board

• Last commit today
• 21+ active contributors
• Distributed ownership (top contributor 33% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

uutils coreutils is a cross-platform Rust reimplementation of GNU coreutils (cat, ls, grep, sed, etc.), aiming to be a drop-in replacement while improving performance and UTF-8 support. It replaces ~100 Unix command-line tools with a single Rust binary that runs identically on Linux, macOS, Windows, and other platforms, eliminating the need to port shell scripts across OSes. Monorepo organized by tool: src/ contains ~100 subdirectories (one per coreutils command), each with its own mod.rs and tests. Shared code lives in uucore/ crate (src/uucore/). Build system: Makefile orchestrates tests and documentation; .cargo/config.toml and Cargo.toml define workspace with unified version management (workspace.edition, workspace.rust-version). CI pipelines in .github/workflows/ test on multiple platforms and architectures.

Systems programmers, DevOps engineers, and open-source contributors who need GNU coreutils on non-Linux platforms (Windows, macOS) or want faster alternatives; package maintainers and Linux distributions seeking a modern, memory-safe reimplementation.

Actively developed and production-ready: 7.5M+ lines of Rust code, comprehensive CI/CD via 20+ GitHub Actions workflows (CICD.yml, GnuTests.yml, fuzzing.yml), extensive test coverage tracked via codecov, and regular releases with prebuilt binaries at latest-commit tag. No signs of stagnation — the project has well-organized issue tracking and active community engagement.

Standard open source risks apply.

Active development across fuzzing (identify edge cases), internationalization/localization (Fluent translation files in .github/fluent_linter_config.yml, Weblate integration), cross-platform bug fixes (Android, FreeBSD, OpenBSD workflows), and GNU compatibility testing (GnuTests.yml compares output against real GNU coreutils). Recent additions likely include more feature completeness and performance optimizations based on CI/CD pipeline breadth.

git clone https://github.com/uutils/coreutils.git
cd coreutils
cargo build --release
./target/release/coreutils --help

Or build a specific tool: cargo build -p ls --release. Tests: cargo test or make test.

Daily commands: Development: cargo build && cargo run -- <command> <args> (e.g., cargo run -- ls -la). Or use the Makefile: make builds all, make test runs tests. For dev container: open in VSCode with .devcontainer/devcontainer.json config (includes Dockerfile with Rust toolchain). Benchmarks: .github/workflows/benchmarks.yml shows the test setup.

• Cargo.toml — Root workspace manifest defining all coreutils utilities, features, and dependencies; critical for understanding project structure and feature flags.
• build.rs — Build script handling multi-call binary setup and code generation; essential for understanding how individual utilities are compiled into a single binary.
• src/bin/coreutils.rs — Main entry point implementing the multicall dispatcher that routes to individual utility implementations based on argv[0].
• .github/workflows/CICD.yml — Primary CI/CD pipeline defining how builds, tests, and releases are validated across platforms; critical for contribution quality standards.
• CONTRIBUTING.md — Contribution guidelines documenting code style, testing requirements, and process for adding new utilities to the codebase.
• docs/src/DEVELOPMENT.md — Detailed development guide explaining the module structure, utility implementation patterns, and local setup for developers.
• GNUmakefile — Build orchestration file showing how to compile, test, and verify utilities match GNU coreutils behavior.

• Multicall Dispatcher (coreutils.rs + build.rs) (Rust std, regex) — Routes CLI invocation by argv[0] name to correct utility module and coordinates initialization
  • Failure mode: Unknown utility name -> exit code 127; corrupted dispatch table -> panic
• Clap-based Argument Parsing (Clap v4) — Each utility defines CLI schema in Clap; validates flags, options, and positional args against GNU spec
  • Failure mode: Invalid flag -> print error + usage; missing required arg -> print error + exit 2
• Core Utility Logic (Rust std, platform-specific crates (nix, fs_extra, regex, etc.)) — Implements algorithm for each utility (cat, ls, grep, etc.); handles platform differences via feature flags
  • Failure mode: File not found -> exit 1; permission denied -> exit 1; internal panic -> exit 101
• Localization (uuhelp + messages.ftl) — Provides translated strings

Add a New Utility

1. Create a new utility module directory src/uu_<name>/ with lib.rs and main.rs (src/uu_cat/lib.rs)
2. Implement the UUApp trait in lib.rs with clap argument parsing and main execution logic (src/uu_cat/src/lib.rs)
3. Add the new utility as a workspace member in Cargo.toml (Cargo.toml)
4. Add utility feature flag and integration to build.rs multicall dispatcher (build.rs)
5. Create tests in src/uu_<name>/tests/ and add to CI test matrix (.github/workflows/CICD.yml)

Add a New Platform Feature Flag

1. Define the feature in the [features] section of Cargo.toml (e.g., feat_unix_selinux) (Cargo.toml)
2. Use #[cfg(feature = "feat_unix_selinux")] conditionally in utility code (src/uu_cat/src/lib.rs)
3. Add platform-specific CI workflow (e.g., .github/workflows/freebsd.yml) to test feature (.github/workflows/freebsd.yml)

Implement Localization (l10n) String

1. Add translatable string to Fluent format in src/uu_<name>/src/messages.ftl (src/uu_cat/src/messages.ftl)
2. Reference the string in Rust code using uuhelp's localization macros (src/uu_cat/src/lib.rs)
3. Verify linting with .github/fluent_linter_config.yml and run l10n CI in .github/workflows/l10n.yml (.github/fluent_linter_config.yml)

• Rust — Memory-safe systems language enabling safe cross-platform rewrites of C coreutils with zero-cost abstractions and strong type safety
• Clap — Declarative CLI argument parsing framework reducing boilerplate for complex GNU-compatible flag and option handling
• Multicall Binary Pattern — Single compiled binary dispatching to multiple utilities by program name (via symlinks or aliases), reducing artifact size and compile time vs. separate binaries
• Fluent (.ftl) for Localization — Standardized i18n format enabling community translation without code changes; integrates with Weblate
• GitHub Actions Workflows — Automated CI/CD for multi-platform testing (Linux, macOS, Windows, FreeBSD, Android, WASI) ensuring GNU compatibility parity

• Multicall binary dispatcher vs. separate per-utility binaries

  • Why: Reduces compilation time, artifact size, and complexity at the cost of tighter coupling in build.rs
  • Consequence: Single binary must be copied/symlinked with different names; cannot disable utilities post-compile

• Feature flags for platform-specific code (e.g., feat_unix_selinux) rather than compile-time conditional dependencies

  • Why: Enables single codebase supporting multiple OSes without fragmentation; reduces maintenance burden
  • Consequence: Runtime checks still required even when features disabled; increases binary size marginally

• Close GNU behavioral parity rather than simplification

  • Why: Drop-in replacement use case requires exact flag compatibility and edge-case behavior matching
  • Consequence: High complexity per utility; slower feature velocity than simplified reimplementation

• Fluent for i18n rather than simple string constants

  • Why: Professional localization workflow; plural forms and locale-aware formatting
  • Consequence: Added complexity in message definitions; requires .ftl file maintenance per utility

• Real-time performance optimization; focus is correctness over speed
• Support for GNU coreutils extensions beyond standard POSIX/GNU flags
• Bundled package manager or system integration tools (only reimplements core utilities)

1. Fuzzing discovers real bugs: fuzzing.yml is not just CI theater; it actively finds crashes, so assume edge cases exist. 2. Platform-specific behavior required: Each tool must pass tests on Linux, macOS, Windows, FreeBSD, OpenBSD, Android, WASI — behavior differences across platforms can cause failures. 3. GNU compatibility is strict: GnuTests.yml will fail the build if output (including error messages and exit codes) differs from GNU coreutils; byte-for-byte matching is often required. 4. Large workspace compile times: 100+ tool crates means first cargo build is slow; use cargo build -p <tool> to speed up iteration. 5. Fluent translation files: adding new strings requires updating .ftl files in multiple languages (Weblate manages translations); missing translations can break i18n.

• Cross-platform abstraction via feature flags — uutils must produce identical behavior on Linux/macOS/Windows despite OS differences; feat_os_unix, feat_os_windows, and conditional compilation achieve this — essential to understand when modifying system-level tools like chmod, chown, or mount
• GNU coreutils compatibility testing — The project goal is drop-in compatibility; GnuTests.yml runs tools side-by-side against real GNU coreutils to catch output and exit-code mismatches — understanding this testing strategy is critical for debugging 'works locally but fails CI' bugs
• Fluent localization (FTL format) — uutils supports UTF-8 and internationalization via Fluent; unlike simple string files, Fluent handles complex pluralization, grammatical agreement, and bidirectional text — relevant when adding new command output or error messages
• Memory-mapped I/O for large files — Tools like od, head, tail deal with multi-gigabyte files efficiently; memmap crate enables zero-copy reading — understanding this is essential for performance and avoiding OOM in tools handling streaming or large data
• POSIX ACLs and capability inheritance — feat_acl enables support for access control lists (beyond simple rwx permissions); libselinux and kqueue dependencies hint at advanced permission handling on FreeBSD/Linux — critical for chmod, ls, and install tools on modern systems
• Workspace crate organization and feature propagation — uutils is a single Cargo workspace containing 100+ tool crates; features defined in root Cargo.toml cascade to subcrates (e.g., feat_systemd_logind affects pinky, uptime, who, uucore) — understanding this dependency graph prevents build breakage when features change
• Fuzzing for discovering edge cases — The fuzzing.yml workflow uses cargo-fuzz to find crashes in tool logic (parsing, numeric overflow, malformed input) — this is how uutils catches security issues and correctness bugs that manual testing misses

• BurntSushi/ripgrep — Alternative high-performance Rust reimplementation of a GNU tool (grep); shares philosophy of safety and speed over the original C version
• sharkdp/fd — Rust rewrite of find command with modern UX; demonstrates single-tool rewrite strategy that uutils generalizes across 100+ tools
• starship/starship — Cross-platform Rust tool ecosystem project; uses similar Cargo workspace structure and CI/CD patterns for multi-platform support
• rustup-rs/rustup — Rust toolchain installer with heavy cross-platform and Windows support; valuable reference for platform-specific testing and binary distribution strategies
• coreutils/coreutils — Original GNU coreutils in C; uutils maintains compatibility by diffing behavior against this — developers often need to reference GNU source for edge cases

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for cross-platform GNU compatibility

The repo has extensive CI workflows (GnuTests.yml, GnuComment.yml) but lacks visible centralized integration test documentation and test case organization. With a cross-platform Rust rewrite of GNU coreutils, a dedicated test suite mapping GNU test outputs to uutils behavior would reduce regressions and improve contributor confidence. This could reference .github/workflows/GnuTests.yml and create a structured test harness.

• [ ] Review .github/workflows/GnuTests.yml to understand current GNU test integration
• [ ] Create tests/gnu_compat/ directory with organized test modules per utility (e.g., tests/gnu_compat/test_ls.rs, tests/gnu_compat/test_grep.rs)
• [ ] Add test helpers in tests/common/mod.rs for standardized GNU output comparison
• [ ] Document test execution in DEVELOPMENT.md with examples for running GNU compatibility tests
• [ ] Add CI step to .github/workflows/code-quality.yml to validate new GNU compatibility tests

Implement missing feature documentation for platform-specific builds in docs/

The Cargo.toml defines multiple conditional features (feat_systemd_logind, feat_acl, feat_external_libstdbuf, unix/windows) but docs/src/ lacks a dedicated guide. The DEVELOPMENT.md file exists but doesn't detail feature flag combinations needed for different platforms. Add a feature matrix document to help contributors understand build requirements.

• [ ] Create docs/src/features.md documenting all feature flags and their platform availability
• [ ] Add a table in docs/src/build.md showing feature combinations for Linux, macOS, Windows, FreeBSD, OpenBSD, Android, WASI
• [ ] Document dependency requirements per feature (e.g., libacl for feat_acl on Linux, as hinted in Cargo.toml comments)
• [ ] Update docs/book.toml to include the new features chapter in the sidebar
• [ ] Add examples of feature flag usage in CONTRIBUTING.md for feature development workflow

Add missing CI workflow for hermetic builds (no external dependencies)

The repo has 12+ workflows (CICD.yml, GnuTests.yml, code-quality.yml, etc.) but no validation that each utility builds independently without optional features. This could catch broken builds when developers break dependency assumptions. Add a workflow that tests cargo build -p <each-util> --no-default-features to ensure modularity.

• [ ] Create .github/workflows/hermetic-builds.yml that iterates over all workspace packages in src/uu/*/Cargo.toml
• [ ] Test each utility with --no-default-features and --all-features combinations
• [ ] Compare against .github/workflows/CICD.yml and .github/workflows/code-quality.yml to avoid duplication
• [ ] Document expected failures in docs/src/CONTRIBUTING.md if certain utilities require specific features
• [ ] Add badge to README.md once workflow is stable (following pattern of existing badges for CodeCov, Discord, etc.)

• Add more comprehensive tests for numeric edge cases in src/numfmt/ and src/od/ — the bigdecimal and datetime dependencies suggest these tools handle complex input, but test coverage gaps likely exist for overflow/underflow scenarios.
• Implement missing --help message translations: search for TODO or FIXME in src/*/lib.rs where Fluent message IDs are hardcoded but not localized; pick one tool and add translations to the .ftl files.
• Verify cross-platform behavior of ACL operations in src/chmod/ and src/ls/ with feat_acl flag enabled on Linux (requires libacl headers); write integration tests that compare output on Linux vs. non-Linux systems to catch feature gaps.

The uutils/coreutils project demonstrates a solid security posture with a defined security policy and responsible vulnerability disclosure process. The codebase is a Rust rewrite of GNU coreutils, which inherently benefits from Rust's memory safety features. Primary concerns are minor: the public email in SECURITY.md could be better protected, and GitHub Actions workflows should be audited for proper secret handling and permission scoping. The project includes fuzzing infrastructure, which is a positive security practice. No critical vulnerabilities or hardcoded secrets are evident from the provided file structure and excerpts. The project's dependency management appears sound with a deny.toml file for security audits and comprehensive CI/CD testing across multiple platforms.

• Medium · Security Policy Disclosure Email in Public Repository — SECURITY.md. The SECURITY.md file contains a public email address (sylvestre@debian.org) for reporting security vulnerabilities. While this is intentional for vulnerability disclosure, it exposes a maintainer's email to potential spam, phishing, or social engineering attacks. Fix: Consider using a dedicated security@uutils.org email alias or GitHub's security advisory feature instead of a personal email. Alternatively, use a contact form on a security page that doesn't expose the email in plain text in the repository.
• Low · Incomplete Cargo.toml File — Cargo.toml. The Cargo.toml file provided is truncated mid-sentence in the feat_acl feature description. This could indicate incomplete configuration or documentation, though the actual build file may be complete. Fix: Ensure the Cargo.toml file is complete and valid. Review the full feat_acl documentation to ensure all dependencies and configurations are properly specified.
• Low · Multiple Workflow Files Require Review — .github/workflows/. The presence of numerous GitHub Actions workflows (.github/workflows/*.yml) suggests complex CI/CD automation. Without reviewing the actual content, potential issues could include: insecure secret handling, overly permissive permissions, or vulnerable action versions. Fix: Audit all GitHub Actions workflows for: 1) Proper secret management (avoid logging secrets), 2) Least privilege principle for permissions, 3) Use of pinned action versions with checksums, 4) No use of 'pull_request_target' without safeguards, 5) Regular updates to all actions.
• Low · Fuzzing Workflow Present — .github/workflows/fuzzing.yml. The presence of a fuzzing workflow (.github/workflows/fuzzing.yml) is good for security, but fuzzing infrastructure requires careful configuration to prevent resource exhaustion and to properly handle findings. Fix: Verify that fuzzing: 1) Has appropriate resource limits, 2) Safely handles crashes/sanitizer findings, 3) Doesn't expose sensitive information in logs, 4) Has a process for triaging and fixing discovered issues.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/uutils/coreutils shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live uutils/coreutils repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/uutils/coreutils.

What it runs against: a local clone of uutils/coreutils — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in uutils/coreutils | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of uutils/coreutils. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/uutils/coreutils.git
#   cd coreutils
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of uutils/coreutils and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "uutils/coreutils(\\.git)?\\b" \\
  && ok "origin remote is uutils/coreutils" \\
  || miss "origin remote is not uutils/coreutils (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "build.rs" \\
  && ok "build.rs" \\
  || miss "missing critical file: build.rs"
test -f "src/bin/coreutils.rs" \\
  && ok "src/bin/coreutils.rs" \\
  || miss "missing critical file: src/bin/coreutils.rs"
test -f ".github/workflows/CICD.yml" \\
  && ok ".github/workflows/CICD.yml" \\
  || miss "missing critical file: .github/workflows/CICD.yml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/uutils/coreutils"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.