Show HN: Grsh – A high-performance shell for FreeBSD written in Rust (grimreaper.icu)

50 points by antomal ↗ HN
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

23 comments

[ 441 ms ] story [ 256 ms ] thread
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

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.
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.
Could you implement a feature that makes it possible to cd into a compressed archive as though it were a normal directory?
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.

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.

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.
Is it possible to install it in ubuntu with apt install grsh? For me no
I've never seen so many people create accounts just to comment on a Show HN before.
What does the "focus on the FreeBSD ecosystem" and "feels native to FreeBSD" mean in practice? I.e. are there FreeBSD specific features being utilised that prevent it working on Linux, or other BSDs?
> native to FreeBSD but works seamlessly on macOS

What does that even mean? In what way do other shells not feel native to FreeBSD?