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!
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!
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!
I actually built it into the shell precisely because I was tired of managing those aliases across different machines. Glad you found it useful!
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.