Yori is a CMD replacement shell that keeps the Windows command line honest

CMD, with the parts CMD never had

Yori is a CMD replacement shell that supports backquotes, job control, and improves tab completion, file matching, aliases, command history, and more.

The list is a specification of what is missing from the shell it replaces. Backquotes mean you can capture the output of one command inside the argument list of another, which is the single feature people miss most when they move from a Unix shell to CMD. Job control means a long running program can be suspended, brought back and put in the background, which CMD does not offer at all. The improvements to tab completion, file matching, aliases and history are the incremental quality of life changes that make a command line feel modern.

There is a second half to the project that is easy to miss. It includes a handful of native Win32 tools that implement commonly needed tasks, and the important word in that sentence is any shell. These are standalone executables, not shell builtins, so they work from cmd.exe, from PowerShell, or from anything else on the machine.

The implementation is C, the licence is MIT, the homepage is at malsmith.net, and the project is the work of the same author who maintains the site.

The repository is not archived, and the last push was on 2026-08-15, so the code is reachable even though the release history stopped earlier.

The code status update at the top of the README

The first section of the README is not a feature list. It is called Code status update, and it says this project has been a fun respite from corporate life, that GitHub is now requiring 2FA for contributions, that this seems like a good time to go elsewhere, and that the author is supposed to lose the account in the next day or two. If code updates stop soon, the note says, that is why.

Read plainly, that is a maintainer announcing the end of active development. The project was a side project, the platform it was hosted on has changed its policy, and the author has decided to stop rather than to set the project up on another account.

For an evaluation this is the single most important paragraph in the repository, and it is placed above the description for exactly that reason. A shell is infrastructure, and infrastructure that nobody maintains is a liability in a different way from a library that is merely stale. A stale library still works, and you can read it. A shell that nobody updates will not get fixed when Windows changes, and the compatibility surface of a Win32 shell is exactly the kind of thing that changes under you.

The release list backs up the picture. v2.0 was published on 2023-07-01, v1.90 on 2023-01-03 and v1.80 on 2022-07-05, so the last published version is more than three years old.

The honest conclusion is that Yori is a finished, usable piece of software that its author has handed over rather than maintained, and that is a different proposition from a project with a roadmap.

Building it with NMAKE, and how the architecture is chosen

Compiling currently requires Visual C++, version 2 or newer, and to compile you run NMAKE. Once compiled, YMAKE.EXE allows for more efficient subsequent compilation, using all cores in the machine, and for build options you run NMAKE buildhelp.

That is a build system from the era when Windows had no other option, and it has a consequence worth naming. The toolchain is NMAKE and the Microsoft C compiler, so building Yori today means working inside a Visual Studio command prompt rather than with a modern build tool, and the two-step dance of NMAKE then YMAKE is the incremental build system on top of it.

The Makefile at the root of the repository shows how much of the project is a single compiler invocation across the whole tree. The first variables are the build switches, with ANALYZE, DEBUG, FDI, KERNELBASE and YORI_BUILD_ID defaulting to zero and ARCH starting out as win32, and then the architecture is detected by asking the compiler what it supports.

ANALYZE=0
ARCH=win32
DEBUG=0

The detection block tests the compiler's help output for x64, then AMD64, then ARM64, then ARM, then Itanium, then MIPS, then PowerPC, and finally Alpha, setting ARCH to amd64, arm64, arm, ia64, mips, ppc or axp as it goes, with win32 as the fallback. The last architecture in that list is Alpha, which is a good indication of the age of the code base.

The rest of the Makefile sets up the output directories, which are per architecture, with a bin directory, a sym directory and a modules directory under bin for the architecture, and it includes config/common.mk. It also notes that old versions of NMAKE have a limit on the line length they can process, which is the sort of constraint that only appears once you have a build that is too big for its build system.

A directory per tool, dozens of them

The top level listing is the clearest evidence of the project's scope, because it is a list of tool directories and there are a lot of them.

The listing includes airplan, assoc, attrib, base64, battery, builtins, cab, cal, charmap, clip, clmp, cls, co, compact, completion, config, contool, copy, cpuinfo, crt, cshot, cut, cvtvt, date, df, dir, dircase, du, echo, edit, env, envdiff, erase, err, expr, extents, finfo, for, fscmp, get, grpcmp, hash, help, hexdump, hexedit, hilite, iconv, initool, intcmp, kernelbase and kill, among others.

Each of those is a separate executable built from its own directory, which is how the project keeps a couple of dozen utilities in one repository without them becoming one program. The names are the argument for the project existing: a lot of these are the small conveniences a Windows user ends up installing from somewhere else, each one a separate download.

The names also tell you which platform this is for. dircase, cvtvt, cshot, charmap and assoc are all tools that only make sense on Windows, and several of them exist because the Windows command line lacks something the Unix one has. The builtins/ directory is the shell's own command set, and completion/ is the tab completion machinery.

The other files in the tree are the infrastructure: a Doxyfile for the documentation, a guide.html, a TODO, a Makefile and a.gitignore.

The design decision is that these tools are native Win32 executables that work with any shell, so Yori is not a closed environment. You can use the shell without the tools, and the tools without the shell.

System requirements and the installer

The system requirements section is precise about a range that spans a decade of Windows releases.

For the core shell and components, NT 3.1 or newer for 32 bit, and XP 64 or newer for 64 bit. Individual features may require newer versions, and the note about the installer is that ysetup.exe works best with NT 4 and IE 4 or newer.

The table of older versions adds the detail. For Nano Server, use the native AMD64 installer. For 95, 98 or Me, those releases are not supported and extensive changes would be required to execute on them. For NT 4 for MIPS, use the MIPS installer.

Two things stand out. The 32 bit build still targets NT 3.1, which is remarkable for a program written in modern C, and it means Yori runs on the kind of machine that a Windows terminal server or an embedded device still has. And the explicit exclusion of Windows 95, 98 and Me is stated as a design decision rather than a bug, with the explanation that it would need extensive changes.

The installers are per architecture, with amd64 and mips builds linked separately, which is the direct consequence of a codebase that still supports architectures nobody ships any more.

Installing is a matter of running ysetup.exe, and the note that it works best with NT 4 and IE 4 or newer is a reminder of how old the installer's assumptions are.

What to do with a shell that is not being maintained

There is a legitimate case for adopting Yori, and it is a narrow one.

If your work requires the Windows command line and you are not permitted to install a Unix-like environment, Yori gives you job control, backquotes and better completion without changing the operating system. And because the bundled tools are ordinary Win32 executables that work with any shell, they remain useful even if you stop using Yori itself and go back to cmd.exe.

That second point is the underrated one. The utilities in this repository are the durable part. A base64, a hexdump, a cut, a date, a du, a finfo and a grpcmp are exactly the small programs that a Windows user otherwise collects from a dozen download sites, and they are MIT licensed, so you can keep them after the shell stops being maintained.

The risk is the shell itself. A Win32 shell that nobody updates will keep working as long as Windows keeps the APIs it uses, and the repository's own documentation shows how old those assumptions are, with Alpha and MIPS in the architecture detection and NT 3.1 in the requirements.

So the sensible way to treat it is as finished software rather than a dependency. Read the source, vendor what you need, and do not plan to send patches upstream, because the README says that path is closed.

Editorial conclusion

Adopt Yori when you have to live in the Windows command line and want job control, backquotes and better completion without moving to a Unix-like environment. Do not adopt it for anything that needs ongoing upstream work, because the README states the author may lose the GitHub account and that code updates are likely to stop, and the last tagged release is from 2023. Verify first which of the bundled utilities you actually need, since the repository is a directory per tool with dozens of them, and that the build environment has Visual C++ version 2 or newer, because the project is compiled with NMAKE.

Frequently asked questions

Official sources

1. License: MIT
2. malxau/yori on GitHub
3. Project website
4. README
5. Releases