clyde

A command-line shell. Initial development is for Windows because Windows has the worst starting point when it comes to CLI shells. Assuming nothing here works and it doesn't even compile.

Background

The needs of this project reflect my professional experience working on multiplayer video games. Prior to working in the games industry, I worked in the web industry, primarily writing server software. The working practices of programmers in these industries differ substantially. The large differences in these working practices create a substantial and difficult social divide within studios that make multiplayer games. These social differences make an already-difficult category of software even more difficult to develop. The goal of this project is to reduce the tooling divide that exists between client and server developers at multiplayer game studios, with the expectation that shrinking this tooling gap can reduce the social divide that exists between game developers and server/infrastructure developers at game studios.

Windows is a hard requirement

The first gap that appears within the greater software developer landscape is the question of using Windows at all. Let us dispense with this question immediately: Windows is a necesary tool within the game development industry. Supporting Windows is a hard requirement of this project.

Many necessary tools, such as tools provided by game console manufacturers and tools that integrate with the dominant game engines (Unity and Unreal) only support Windows. If your reaction to this is "don't use those tools" or "make your game in Godot", please just stop. This is a very common reaction from professional programmers who have never worked in gamedev, who don't understand the constraints that most game developers face. Unfortunately a large portion of programming discussion happens on Hacker News, Reddit, and Lobsters, each of which uses a democratic structure.

I will not attempt to convince you that Windows is broadly unavoidable in professional game development and that Windows is a necessary tool for game development studios, even studios that employ engineers for whom Windows is not necessary for their individual role. If you want to advocate for Linux superiority, please go bother Nintendo, Sony, Microsoft, etc, not individual game developers. If you really can't get over this and feel the need to yell at me, please walk a few hundred yards into a dense forest and scream your complaints into the wilderness to feel better.

The command-line environments built into Windows are incredibly primitive. These environments are so primitive that millions of professional programmers who work primarily on Windows are led to believe that command-line environments themselves are inherently primitive.

. The limitations of built-in command-line environments on Windows is so severe that there are entire categories of professional computer programmers who believe that they are "not terminal people", often without realizing that the terminal on Linux and MacOS is a vastly different experience and different tooling ecosystem than it is on Windows. Many professional Windows developers believe that CLI environments are inherently primitive, because their only exposure to CLI environments is through the built-in Windows shells.

Windows ships with two built-in shells. The first shell is the Command Prompt, which we'll refer to as cmd.exe as it is colloquially known, even when running inside of terminal.exe. The second shell is PowerShell.

Insufficiency of cmd.exe

The insufficiency of cmd.exe is widely understood to people with experience with Unix-like operating systems such as Linux and MacOS, which typically include either bash or zsh. This insufficiency is severe enough that it drives people off of Windows entirely.

In some industries, such as games, Windows is a required development environment, because many tools are available only on Windows. Free software purists who want to insist that you can make video games on Linux, please feel free to leave now, this project is not for you.

Terimology

• executable: a shell built-in or an executable file (i.e., an .exe file)

examples

$> a

Find an executable named a somewhere on PATH and execute it in the foreground.

$> ./a

Use an executable named a within the current directory and execute it in the foreground. a must be a file in the current directory. If a would refer to both a shell built-in and a file in the current directory, use the file in the current directory.

$>