[HN Gopher] Show HN: Grsh - A high-performance shell for FreeBSD...
___________________________________________________________________
Show HN: Grsh - A high-performance shell for FreeBSD written in
Rust
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
Author : antomal
Score : 41 points
Date : 2026-01-14 17:19 UTC (5 hours ago)
(HTM) web link (grimreaper.icu)
(TXT) w3m dump (grimreaper.icu)
| antomal wrote:
| 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
| utentemedio wrote:
| 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.
| antomal wrote:
| 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!
| fabiominnelli wrote:
| Finalmente la prima Shell Italiana.
| antomal wrote:
| thanks!
| antomal wrote:
| 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.
| ladybanshee wrote:
| Could you explain the purpose of mkcd?
| antomal wrote:
| 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.
| az09mugen wrote:
| 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 ?
| antomal wrote:
| 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.
| az09mugen wrote:
| I love the concept, very good yet simple idea ! I'll steal
| it for my aliases.
| antomal wrote:
| Go ahead and 'steal' away! That's the beauty of open
| source.
|
| I actually built it into the shell precisely because I
| was tired of managing those aliases across different
| machines. Glad you found it useful!
| nosacciu wrote:
| Could you implement a feature that makes it possible to cd into a
| compressed archive as though it were a normal directory?
| antomal wrote:
| 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!
| womanpower wrote:
| 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.
| antomal wrote:
| 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
| giannicancelli wrote:
| 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.
| antomal wrote:
| 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!
| antomal wrote:
| 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.
| ladycron wrote:
| Is it possible to install it in ubuntu with apt install grsh? For
| me no
| antomal wrote:
| 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!
| ifh-hn wrote:
| I've never seen so many people create accounts just to comment on
| a Show HN before.
___________________________________________________________________
(page generated 2026-01-14 23:02 UTC)