Show HN: Grsh – A high-performance shell for FreeBSD written in Rust

6 hours ago (grimreaper.icu)

I built GRSH because I wanted a modern, memory-safe shell that feels native to FreeBSD but works seamlessly on macOS.

While there are many shells out there, GRSH is my take on a minimal, fast, and secure command interpreter written entirely in Rust. It's designed for users who want the safety guarantees of Rust without the overhead of more bloated alternatives.

I'm currently working on the official FreeBSD port. I’d love to get feedback on the shell's behavior and performance from the community.

Github: https://github.com/antoniomalara301289/grsh

I have an idea for a feature-rich shell tailored for women’s health and productivity. The core idea is a menstrual cycle calendar integrated into the shell with these features: • Cycle tracking: Track period start/end, ovulation, and fertile days. • Notifications: Send email reminders when the period is expected to start. • Server-friendly: Run in the background on a server, integrating with cron or systemd. • Privacy-first: All data stored locally with optional encrypted backups. • CLI-friendly interface: Commands like cycle status, cycle next, cycle log.

It would be a complex, useful, and empowering tool for anyone who wants to combine shell productivity with personal health. I’d love to explore implementing this in Rust.

  • This is a very unique and thoughtful feature request! I love the idea of making the shell more personal and empowering by integrating health tracking with terminal productivity.

    From a technical standpoint, implementing this in Rust would be great because of the strong focus on privacy and memory safety. The 'privacy-first' and 'local storage' aspects you mentioned align perfectly with the philosophy of GRSH.

    While my current roadmap is focused on core shell stability and the FreeBSD port, GRSH is designed to be extensible. This could be a fantastic candidate for a built-in module or a dedicated plugin.

    If you're interested in exploring how to implement this in Rust for GRSH, please feel free to open a discussion on the GitHub repo. I’d love to see how we can make the terminal a more inclusive and useful space for everyone

I would like the shell to support advanced job control: Ability to suspend processes (Ctrl+Z) and resume them (fg, bg). Display all active jobs with jobs. Interactively select which job to resume, for example via a numbered menu or a list to choose from, instead of manually typing fg %<job_number>. , support both foreground and background jobs and allow managing multiple jobs simultaneously.

You can leverage existing bash/zsh functionality as a base, but the key feature is interactive job selection.

  • Actually, GRSH already supports this!

    You can use Ctrl+Z to suspend, and fg for basic job control. Regarding the interactive selection you mentioned: that’s one of the core features I wanted to get right from the start. Instead of memorizing job IDs, you can manage them interactively.

    I’m a big fan of reducing the cognitive load when multitasking in the terminal, so I’m glad we share the same vision for a more modern job control experience!

Thanks everyone for the incredible feedback! I'm seeing great suggestions about transparent archive navigation and plugin systems. I'm focusing on the FreeBSD port right now, but I'll be opening issues for these features on GitHub tonight. The interest in job control and Rust implementation details has been amazing.

I've been working on GRSH because I wanted to explore building core system utilities using Rust's memory safety guarantees, with a specific focus on the FreeBSD ecosystem.

While the shell is still in its early stages, my goal is to create a lightweight, fast, and secure alternative to traditional shells that feels at home on both FreeBSD and macOS.

Key features I'm focusing on:

Zero-cost abstractions for process management.

Native performance on BSD-based systems.

Minimalist design without the bloat of modern 'all-in-one' shells.

I'm also developing DIR (a visual disk analyzer for FreeBSD) as part of this 'Grim Reaper' toolset.

I would love to hear your feedback on the implementation or any specific features you'd like to see in a Rust-based shell for Unix systems.

Source Code: https://github.com/antoniomalara301289/grsh Project Page: https://grimreaper.icu

Thanks for the question! For Job Control, I’m currently implementing a custom management system to handle foreground and background process groups.

Regarding signal propagation, I’m leaning towards a direct integration with libc to maintain that 'native' feel you mentioned, specifically for managing tcsetpgrp and ensuring the terminal is correctly assigned to the active process group.

One feature I’m particularly proud of is what I call 'Pinning': it allows the user to pin a specific process and recall it instantly. This is part of my effort to make GRSH feel more interactive than a standard POSIX shell.

As for async signal handling, I'm currently refining the core loop to ensure that complex pipelines don't leave zombie processes or mismanaged groups on the FreeBSD kernel. It's a work in progress, and feedback on the current implementation in the repo is more than welcome!

I'm seeing some great technical questions about process lifecycles and Rust invariants. To clarify: regarding job control, when a process is recalled, it currently rejoins the foreground process group. I'm leveraging Rust's ownership model to ensure FDs are closed properly, but I'm still refining the signal semantics for SIGTSTP.

Great to see more Rust-based tooling coming to FreeBSD. Regarding the architecture, how are you handling Job Control and signal propagation? Specifically, are you using a custom wrapper for libc to manage tcsetpgrp and foreground process groups, or are you leveraging a specific Rust crate for asynchronous signal handling? I’m curious to see how GRSH maintains the 'native' feel when managing complex pipelines on the FreeBSD kernel.

Is it possible to install it in ubuntu with apt install grsh? For me no

  • Not yet! grsh is currently in its early stages, and I haven't submitted it to the official Ubuntu/Debian repositories yet.

    However, since it's written in Rust, you can easily install it from source on Ubuntu:

    Install Rust: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

    Clone the repo and run: cargo install --path .

    I am currently prioritizing the FreeBSD Ports collection, but creating a .deb package or a PPA for Ubuntu is definitely on the roadmap. If anyone wants to help with the packaging, feel free to reach out on GitHub!

Could you implement a feature that makes it possible to cd into a compressed archive as though it were a normal directory?

  • That's an ambitious and fascinating feature request!

    Implementing transparent archive navigation (mounting archives as virtual directories) is definitely on my 'dream features' list for GRSH. Since the shell is written in Rust, I've been looking into FUSE-based solutions or leveraging something like libarchive to create a virtual file system layer.

    It’s a bit complex to get right—especially for performance and write support—but I've opened an issue on GitHub to track this idea. I'd love to explore this once the FreeBSD Port and core stability are finalized.

    Thanks for the great suggestion!

Could you explain the purpose of mkcd?

  • Not the author, but my first guess is to create a folder and cd into it with just one command instead of 2 with the said argument, isn't it ?

    • Exactly. It's a small quality-of-life feature to avoid the repetitive mkdir && cd sequence. In GRSH, it also ensures the directory is created with the necessary permissions before the shell attempts to switch into it.

      2 replies →

  • It’s a shortcut

    Its purpose is to combine mkdir -p and cd into a single atomic-like action. Instead of typing: mkdir -p my_project && cd my_project

    You simply run: mkcd my_project

    It's designed to reduce friction during development, especially when you're frequently creating new nested directory structures.