Comment by antomal

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.