NESH 0.2.0 - a UEFI shell with a scripting language (test request: real firmware)

This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
Post Reply
nicfio
Posts: 1
Joined: Sun Sep 20, 2026 2:40 am

NESH 0.2.0 - a UEFI shell with a scripting language (test request: real firmware)

Post by nicfio »

NESH is a command shell for UEFI firmware, written from scratch: no EDK2 code, one 360 KB file, nesh.efi, built with a freestanding gcc and a small ELF-to-PE32+ converter. I started it because the EDK2 shell is hard to script and hard to build, and I wanted a shell that a sysadmin can actually automate.

What is in it:
  • The UEFI Shell command set, rewritten - files, disks, UEFI variables, drivers and devices, PCI/SMBIOS/ACPI, memory, network, editors. The EDK2 option letters are accepted as well, so existing habits keep working.
  • A real scripting language (NESH BASIC, .nsb): variables, loops, SUB/FUNCTION, arrays, strings, menus, file I/O, and RUN / RUN$() to drive commands and capture their output.
  • Machine-readable output: every interesting command takes -data and prints key=value records that scripts read with RECORDS() and FIELD$() - the idea of -sfo, but usable.
  • EFI_SHELL_PROTOCOL 2.2 is implemented, so UEFI Shell applications (including EDK2 ones) run under NESH.
  • Boot management: bootmgr, with dry run, confirmation, automatic backups of the boot variables and a check for entries pointing at missing files. bcfg is there too for the classic syntax.
  • Network: IPv4 and IPv6 - ifconfig/ifconfig6, ping/ping6, tftp, http.
  • Secure Boot aware: while Secure Boot is active, low-level hardware writes (mm on I/O ports and PCI config, pci -s, ...) are refused, reads still work.
  • Documentation: a user manual and a developer manual, both generated and checked against the code by the test suite.
A taste of the scripting side - an interactive boot menu built from the firmware's own boot entries, in about ten lines:

Code: Select all

n = RECORDS(RUN$("bootmgr list -data"), r$())
FOR i = 0 TO n - 1
  items$ = items$ + FIELD$(r$(i), "description") + "|"
NEXT
c = MENU("Start which system?", items$, 10, 1)
RUN "bootmgr next -B " + FIELD$(r$(c - 1), "id")
RUN "reset"
It also starts an EFI stub Linux kernel directly, with a command line built by the script, so one vmlinuz can have several menu entries with different options. (Verified in QEMU with a Debian 6.12 kernel, initrd included.)

Links
Source and releases: https://github.com/nic-fio/NG-EFI_SHELL
Documentation: https://nic-fio.github.io/NG-EFI_SHELL/
Bootable disk image (dd it to a USB stick and boot it): https://github.com/nic-fio/NG-EFI_SHELL ... sh-usb.img
Just the binary: https://github.com/nic-fio/NG-EFI_SHELL/releases/latest (copy it to \EFI\BOOT\BOOTX64.EFI)

Test request
Everything so far has been tested in QEMU with OVMF only - including Secure Boot with my own test keys - and QEMU is not firmware. What I would like to know from real machines:
  1. Does it start at all, and what firmware is it (vendor, version, machine)?
  2. map and ls: are all your volumes there - NVMe, USB sticks, several disks, a removable drive plugged in while NESH is running?
  3. Do your UEFI Shell applications run under it (shell protocol compatibility)?
  4. bootmgr list / bootmgr check against the entries your firmware really has, and whether bootmgr next + reset does what it says.
  5. Network: ifconfig, ping, tftp, http, and IPv6 autoconfiguration with ifconfig6 -s eth0 auto.
  6. Screen: mode -max and mode -fill (the second one reconnects the console driver to get a text mode that fills the panel), and gop to change the resolution.
  7. Anything a command refuses, or any firmware that hangs - that is the most useful report of all.
Reports here or as issues on GitHub; a paste of sysinfo and inventory.nsb output tells me most of what I need.

Licence - so nobody has to guess: Apache 2.0 with the Commons Clause. Free to use, at home or at work, free to copy, modify and share, keeping the notices and saying what you changed; what you may not do is sell it, or sell a product or service whose value comes substantially from it - that needs a commercial licence, which I grant on request: open an issue on GitHub and ask. That makes it source-available, not OSI open source, and I would rather say so up front than be asked. The licence travels with the downloads: LICENSE and NOTICE.md are attached to the release, LICENSE.txt and NOTICE.txt are on the bootable image.
Post Reply