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.
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
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!
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.
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
You can leverage existing bash/zsh functionality as a base, but the key feature is interactive job selection.
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!
I suspect the project might have been shared in some FreeBSD or Rust-specific IRC channels or forums outside of HN, which brought in people who aren't regular HN users but are passionate about these specific technologies.
It’s exciting to see new faces, but I definitely didn’t expect this level of influx!
I think the 'weird' influx of new accounts is likely because this got picked up by some FreeBSD/Rust communities or Telegram/IRC groups where people aren't usually on HN. It’s my first time posting a project here, and I'm honestly just trying to keep up with the technical questions!
If anyone is skeptical, I'd much rather talk about the code, the job control implementation, or the FreeBSD porting process. That’s why I’m here!
System Integration: I’m prioritizing first-class support for FreeBSD-specific tools and environments (like Jails and the Ports system). While many shells treat BSD as an afterthought, I want grsh to feel like it was built specifically for the FreeBSD base system.
Technical Implementation: Currently, I’m leveraging specific behaviors of the FreeBSD terminal driver and signal handling. While the Rust codebase is portable in theory, I’m not 'watering down' the features to guarantee Linux compatibility yet. I want to exploit FreeBSD’s strengths first.
License & Philosophy: The project is under the BSD-3-Clause license, which aligns with the ecosystem's preference for permissive licensing.
Can it work on Linux/other BSDs? Yes, it can be compiled on Linux, but you might find that certain job control nuances or terminal optimizations are currently 'tuned' for the FreeBSD kernel. I’d rather have it work perfectly on one OS than 'okay-ish' on all of them.
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!
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!
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.
What does that even mean? In what way do other shells not feel native to FreeBSD?
Direct System Integration: Most shells target a generic POSIX or GNU/Linux environment. grsh is being built with FreeBSD-specific subsystems in mind—specifically Jails awareness (knowing if you are inside one and interacting with it) and planned ZFS integration for smarter path completions and status reporting.
The 'Base System' Philosophy: FreeBSD users generally prefer the 'base system' vs 'ports' distinction. I've chosen the BSD-3-Clause license and focused on keeping dependencies minimal to align with the FreeBSD architectural style, rather than bringing in the heavy baggage often found in Linux-first projects.
Signal & TTY Handling: Implementing job control directly against the FreeBSD termios and signal delivery nuances. While Rust provides abstractions, the 'feel' of a shell depends on how it handles these OS-specific edge cases.
Regarding macOS: It’s 'seamless' because macOS (via Darwin) shares that BSD heritage. The implementation for process management and terminal control translates much more naturally to macOS than it does to Linux, which often requires specific workarounds for its PTY/TTY behavior.
In short: I’m building for the BSD crowd first, not as an afterthought.
