Vision: why nu-require exists

The dual-role bug

Classical shells bind two jobs to one byte stream:

  • Transport — pipe unstructured bytes between processes

  • Presentation — paint those bytes on a terminal grid

TUIs abandon the pipe. Plain CLIs keep the pipe and lose layout. Structured shells (Nushell; PowerShell pioneered objects) pass typed data in the pipeline and render only at the screen boundary.

Product decision

Tools that depend on Nushell-structured behavior should not silently degrade under bash/zsh/pwsh. They should:

  1. Detect the host shell

  2. If Nushell is installed but this process is not under it → tell the user and relaunch the same CLI inside nu (same binary path + argv)

  3. If Nushell is not installed → fail with a homepage link and optionally offer install

That is nu-require.validate().

Why relaunch (not only error)

Users will keep opening tools from Windows Terminal profiles, IDE tasks, and muscle-memory pwsh/bash sessions. Forcing them to remember “open a nu shell first” is friction. If nu is on PATH, hopping into Nushell for that one command is the polite default:

$ myCLItool status
Nushell is installed, but this shell is not Nushell. Relaunching inside Nushell…
(... tool runs under nu ...)

The tool still requires Nushell as the real host; it does not pretend bash/pwsh are supported runtimes.

What we will not do

  • Reinvent Nushell

  • Treat PowerShell as an alternate supported host for Nushell-tailored CLIs

  • Pretend TUI frameworks solve the pipe/layout split

Companion standards live in shell-architecture. Flag-syntax certification remains SOS in open-shell-org.