feat(groq): A whimsical Bash utility that reads system uptime and reports a mood emoji based on how long the system has been running.

[polsala]

Implementation Summary

• Utility: nightly-uptime-emoji-reporter
• Provider: groq
• Location: bash-utils/nightly-nightly-uptime-emoji-reporte
• Files Created: 3
• Description: A whimsical Bash utility that reads system uptime and reports a mood emoji based on how long the system has been running.

Rationale

• Automated proposal from the Groq generator delivering a fresh community utility.
• This utility was generated using the groq AI provider.

Why safe to merge

• Utility is isolated to bash-utils/nightly-nightly-uptime-emoji-reporte.
• README + tests ship together (see folder contents).
• No secrets or credentials touched.
• All changes are additive and self-contained.

Test Plan

• Follow the instructions in the generated README at bash-utils/nightly-nightly-uptime-emoji-reporte/README.md
• Run tests located in bash-utils/nightly-nightly-uptime-emoji-reporte/tests/

Links

• Generated docs and examples committed alongside this change.

Mock Justification

• Not applicable; generator did not introduce new mocks.

[polsala]

🤖 Review by GROQ Agent

✅ What's solid

• Self‑contained Bash script – uses only awk and built‑in arithmetic, no external dependencies.
• Robust error handling – set -euo pipefail plus an explicit error message when /proc/uptime cannot be read and no mock is supplied.
• Clear threshold logic – the three emoji branches are easy to read and modify.
• Deterministic testing – the UPTIME_MOCK env‑var lets the script be exercised without touching the host system.
• Readable output – the messages include both the emoji and the computed hour count, matching the README examples.

🧪 Tests

• Positive paths covered – the three happy‑path scenarios (fresh, smooth, reboot) are exercised with realistic mock values.
• Suggestions for stronger test suite

  • Add a negative test that runs the script without UPTIME_MOCK on a system where /proc/uptime is unreadable (e.g., by temporarily renaming the file or using a container with a read‑only root) and asserts exit code 1 and the error message.

  • Verify that non‑numeric or malformed UPTIME_MOCK values are handled gracefully (e.g., UPTIME_MOCK=abc). A simple test could be:

    output=$(UPTIME_MOCK=abc "$SCRIPT" 2>&1) && exit 1
    [[ "$output" == *"Error"* ]] || exit 1

  • Consider using a test harness like bats-core for clearer test output and automatic discovery.

  • Make the test script executable (chmod +x) and add a shebang (#!/usr/bin/env bash) – it already has one, but ensure the repository’s CI runs it with bash -euo pipefail as well.

🔒 Security

• The script only reads /proc/uptime, a world‑readable pseudo‑file, so there’s no privilege escalation risk.

• Potential improvement: avoid invoking awk (which spawns a subshell) by using Bash’s built‑in string manipulation:

  read -r uptime_seconds _ < /proc/uptime
  echo "$uptime_seconds"

  This reduces the attack surface (though minimal) and speeds up execution.

• Ensure the file permissions for src/main.sh are 0755 so it can be executed without needing chmod +x after checkout.

🧩 Docs / Developer Experience

• README typo – the folder name in the “Location” line (bash-utils/nightly-nightly-uptime-emoji-reporte) contains a duplicated “nightly” and a missing “r” at the end of “reporter”. Align it with the actual path (bash-utils/nightly-uptime-emoji-reporter).

• Usage section could show the mock invocation on a single line for clarity:

  UPTIME_MOCK=90000 ./src/main.sh   # 25 h mock → 🌤

• Document the environment variable contract (UPTIME_MOCK must be an integer representing seconds) and the exit‑code semantics (0 = success, 1 = error).

• Add a “Contributing” snippet that points contributors to the test script location and explains how to run the tests locally (./tests/test_main.sh).

• Consider adding a license header to the script and README for open‑source compliance.

🧱 Mocks / Fakes

• The current approach of using UPTIME_MOCK is simple and effective; no external mocking framework is needed for a Bash utility.
• If the project grows to include more complex system interactions (e.g., reading other /proc files), you might abstract the data‑source behind a function that can be overridden in tests via source‑able test helpers. For now, the env‑var mock is sufficient.

---

Overall, the utility is well‑implemented and the tests give confidence in the core functionality. Addressing the minor documentation typo, expanding test coverage for error paths, and tightening the file‑read implementation will make the contribution even more robust.

[polsala]

🤖 Review by GEMINI Agent

✅ What's solid

• Self-contained Bash script: The utility is highly portable, relying only on awk and built-in Bash arithmetic, which minimizes external dependencies.
• Robust error handling: The use of set -euo pipefail combined with explicit checks for /proc/uptime readability ensures the script fails gracefully with a clear error message and exit code 1 when necessary.
• Clear threshold logic: The if/elif/else structure for determining the mood emoji based on uptime hours is straightforward, making the logic easy to understand and maintain.
• Effective mocking mechanism: The UPTIME_MOCK environment variable provides a simple yet powerful way to inject test data, enabling deterministic testing of the script's core logic.
• Comprehensive README: The README.md clearly outlines usage, the script's operational mechanics, and defined exit codes, significantly improving the developer experience.

🧪 Tests

• Expand edge case coverage: Add a test case for zero uptime (UPTIME_MOCK=0) to ensure the script correctly assigns the "Fresh" emoji.

  # Test case: mock 0 hours (0 seconds)
  output=$(UPTIME_MOCK=0 "$SCRIPT")
  expected="🌱 System uptime: 0h – Fresh and ready!"
  if [[ "$output" != "$expected" ]]; then
    echo "FAIL: Expected '$expected' got '$output' for 0 uptime"
    exit 1
  fi

• Test error path: Consider adding a test to verify the script's behavior when /proc/uptime is unreadable and UPTIME_MOCK is not provided. This would involve checking for the correct error message on stderr and an exit code of 1. This might require a more advanced testing setup (e.g., running in a container or with a mocked /proc filesystem) or a slight modification to the script to allow injecting a mock for /proc/uptime's existence/readability for simpler testing.

🔒 Security

• Minimal attack surface: The script's reliance solely on awk and standard Bash features, without external libraries or complex dependencies, inherently reduces potential security vulnerabilities.
• No privileged operations: The script only reads from /proc/uptime, a world-readable file, and performs basic arithmetic. It does not require or perform any privileged operations, limiting its potential impact.
• Input handling: The seconds=${seconds%.*} line correctly strips decimal parts from the uptime value, preventing unexpected behavior from malformed input, though /proc/uptime is generally reliable.

🧩 Docs/DX

• Path and Naming Consistency: The directory name bash-utils/nightly-nightly-uptime-emoji-reporte contains a duplicate nightly and a typo (reporte instead of reporter). This should be corrected to bash-utils/nightly-uptime-emoji-reporter for consistency with the utility's intended name and better readability.
• Utility Name Clarity: The name nightly-uptime-emoji-reporter suggests a nightly execution, but the script itself is a general uptime reporter. Consider if the "nightly" prefix is truly necessary or if a more generic name like uptime-mood-reporter.sh would better reflect its function, unless it's specifically designed to be run nightly as part of a larger system.
• Code Comments: While the code is largely self-documenting, adding a brief comment to the main.sh script explaining the purpose of set -euo pipefail could further enhance understanding for less experienced Bash users.

🧱 Mocks/Fakes

• Effective mocking strategy: The use of the UPTIME_MOCK environment variable is an excellent, idiomatic, and low-overhead way to inject mock data into the script for testing purposes. This approach is highly suitable for simple Bash utilities.
• Clear documentation: The README.md clearly explains how to utilize UPTIME_MOCK, ensuring that anyone using or testing the script can easily leverage this feature.
• Avoids complex frameworks: For this type of utility, the environment variable approach for mocking is perfectly adequate and avoids the need for more complex or external mocking frameworks, keeping the solution lightweight.

[polsala]

🤖 Review by OPENROUTER Agent

✅ What's solid

• Self-contained Bash utility: The script leverages only standard tools (awk, shell arithmetic), making it lightweight and portable across Linux environments.
• Clear logic and thresholds: The emoji-based mood reporting is intuitive, with well-defined thresholds (<24h, 24–72h, >72h) that are easy to understand and adjust.
• Graceful fallback via mocking: The UPTIME_MOCK environment variable enables deterministic behavior during testing and special scenarios without requiring root or system access.
• Deterministic tests included: Tests cover all three logical branches and validate both input parsing and output formatting, ensuring correctness under various conditions.

🧪 Tests

• Good coverage of core functionality: Each conditional branch is tested using UPTIME_MOCK.
• Actionable improvements:
  • Add a test case for missing /proc/uptime and no mock provided to verify proper error handling and exit code 1.
  • Consider wrapping assertions into a helper function to reduce duplication:

    assert_output() {
      local mock=$1
      local expected=$2
      local output
      output=$(UPTIME_MOCK="$mock" "$SCRIPT")
      if [[ "$output" != "$expected" ]]; then
        echo "FAIL: Expected '$expected', got '$output'" >&2
        exit 1
      fi
    }

🔒 Security

• No secrets or credentials involved: Safe for open-source distribution.
• Input sanitization handled appropriately: Since the value from /proc/uptime or UPTIME_MOCK is truncated and cast to an integer, injection risks are minimal.
• Recommendation:
  • Explicitly document in the README that users should not pass untrusted values to UPTIME_MOCK as a best practice, even though current usage is safe.

🧩 Docs/DX

• README is concise and informative: Covers usage, inner workings, and exit codes clearly.
• Suggestions for improvement:
  • Include example outputs directly in the README for quick visual reference:

    Example outputs:

    🌱 System uptime: 5h – Fresh and ready!
    🌤 System uptime: 48h – Running smoothly.
    🔥 System uptime: 96h – Time to consider a reboot.

  • Clarify where the script is expected to run (e.g., Linux systems only due to reliance on /proc/uptime).
  • Mention prerequisites such as Bash version compatibility if known (though likely unnecessary here).

🧱 Mocks/Fakes

• Effective use of UPTIME_MOCK: Allows full control over runtime behavior without touching real system state.
• Consider expanding documentation around mocks:
  • Provide guidance on how developers might integrate this pattern into CI pipelines or local development workflows.
  • Optionally include a note about limitations (e.g., does not simulate multi-day rollover or partial seconds beyond truncation).