It's not in the official repo just yet, but the Port is already under review on FreeBSD Bugzilla! I’m currently working through the review process to get it merged into the official ports collection. In the meantime, you can build it from source via Cargo or check out the progress on the Bugzilla ticket.
Great question! While you could technically hack a similar behavior using a shell function (not a simple alias, as aliases don't handle positional arguments well), grsh implements mkcd as a native builtin.
By baking it into the shell in Rust, I can ensure atomic execution and better error handling without relying on the user's specific .bashrc or .zshrc hacks. It's about providing a 'batteries-included' experience where common workflows are first-class citizens of the shell itself.
That’s a fair point. To be concrete, 'native to FreeBSD' in the context of grsh refers to three design choices where general-purpose shells often feel like guests:
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.
I can promise you there are no agents or bots here—just a solo dev who's been working on a Rust shell for FreeBSD in his spare time.
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!
I noticed that too, and I can assure you it’s purely organic. I’m just as surprised as you are!
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!
Great question. In practice, 'native to FreeBSD' means a few things for grsh:
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.
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!
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.
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!
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
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.
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.
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.
This looks very interesting! It reminds me of the approach taken by HTMX or Alpine.js, but with deeper control flow logic. In your opinion, what is the main advantage of hyTags over HTMX for developers managing complex UI states?
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!