DEV Community: Shinji Ito

Building a Unix Shell from First Principles in Rust

Shinji Ito — Wed, 26 Aug 2026 14:41:49 +0000

I’ve been working on a project called Whelk, a Unix shell built from first principles in Rust.

The goal wasn’t to build another Bash replacement.

I wanted to understand what actually happens underneath a shell — from parsing a command line to creating processes, connecting pipes, handling signals, managing jobs, and interacting with the terminal.

The project is intentionally small enough to understand, but deep enough to expose how Unix actually works.

What I Built

Whelk currently covers quite a lot of the machinery involved in a real interactive shell:

Command parsing with a lexer and AST
Quoting, escaping, and useful error locations
Environment and variable expansion
Input/output/error redirection
Concurrent pipelines
Process creation and waiting
Signal handling
Process groups
Job control with jobs, fg, and bg
Terminal mode management and resizing
History and command completion
An event loop using epoll on Linux and kqueue on BSD/macOS
Benchmarks and allocation-oriented regression tests

The project is split into relatively small Rust crates so that the boundaries between parsing, execution, processes, jobs, terminals, and events remain visible.

What I Learned

The biggest lesson has been that systems programming is often about understanding boundaries.

A shell looks simple from the outside:

command → process → output

But underneath, there are many moving parts.

Pipelines involve multiple processes communicating through file descriptors.

Job control requires understanding process groups and terminal ownership.

Signals introduce asynchronous behavior.

Terminal interaction requires changing terminal modes and restoring them correctly.

Even something as simple as pressing Ctrl-Z involves much more than detecting a key.

Building these pieces myself forced me to understand the operating system rather than treating it as an abstraction that simply works.

Rust Made the Project Interesting

Rust has been particularly useful for this kind of project.

The shell inevitably has places where it needs to interact directly with operating-system primitives, including fork, exec, file descriptors, signals, and terminal operations.

Those boundaries require unsafe code, but I’ve tried to keep the unsafe parts concentrated in the process and OS-facing layer.

That creates an interesting design constraint:

How much of the system can remain safe Rust while still exposing low-level Unix behavior?

That question has influenced the architecture quite a bit.

Performance Was Another Lesson

I initially expected parsing and command processing to be the interesting performance problems.

The benchmarks showed otherwise.

For example, parsing a pipeline is around microseconds, while starting a process is hundreds of microseconds on the same benchmark setup.

That changes how I think about optimization.

If process creation dominates the cost, spending a huge amount of effort shaving a few nanoseconds from parsing isn't particularly meaningful.

The benchmarks also uncovered a feature with a much larger cost than I expected — exactly the kind of thing that is easy to miss when you only optimize based on intuition.

Why I’m Building It

The main reason is simple:

I want to understand the systems underneath the software I use every day.

High-level abstractions are incredibly useful, but occasionally going one layer deeper is valuable.

Building a shell forced me to learn about processes, file descriptors, signals, terminals, scheduling boundaries, event notification, and the Unix process model in a much more concrete way.

And that's what I enjoy about projects like this.

The final application isn't necessarily the most important result.

The understanding you gain while building it is.

Whelk is still evolving, and there are intentionally many things it doesn't try to implement. It's not intended to become a drop-in replacement for Bash.

It's a learning project, an engineering experiment, and a way for me to make the operating system's process model visible through code.

The source is available on GitHub:

https://github.com/ferris007/whelk

Why I Contribute to Open Source: Building Something Bigger Together

Shinji Ito — Wed, 26 Aug 2026 14:38:32 +0000

I don’t contribute to open source because I have nothing else to do.

And I don’t contribute because I’m simply looking for something to put on my GitHub profile.

I contribute because I believe open source is one of the places where we can actually build the future together.

Building Something Bigger Than Ourselves

Software is strange.

A few lines of code written by one person can eventually become something used by thousands—or even millions—of people.

An idea that starts in one country can be improved by someone on the other side of the world.

That is what makes open source special to me.

You don’t need to work for the same company, live in the same city, or even speak the same native language to build something together.

You need a shared problem and the willingness to contribute.

Every issue, pull request, discussion, review, and idea can become part of something much larger than the individual who created it.

Open Source Is Also About People

I think there is another side of open source that is easy to overlook.

Open source isn't only about code.

It is also a place where people meet.

Different countries.

Different cultures.

Different ways of thinking.

Different personalities.

A developer from Japan might approach a problem differently from someone in Europe. Someone with a completely different background might notice something the original author never considered.

Those differences aren't necessarily friction.

Sometimes, they're exactly what makes a project better.

Open source creates a unique kind of global community where the first thing people can see is often not your nationality, background, or job title.

They see what you build.

They see how you think.

They see how you communicate.

They see how you help others.

Contribution Is Not Charity

I don't see open-source contribution as charity.

I see it as an exchange.

I give something to a project, but I also receive something in return.

I learn from other engineers.

I encounter problems I might never encounter in my day job.

I see different architectures, implementations, and approaches.

I become better at communicating technical ideas.

And sometimes, I meet people I would never have met otherwise.

The value isn't always immediate.

Sometimes a contribution is a small fix that hardly anyone notices.

Sometimes it becomes a feature used by thousands of people.

And sometimes the most valuable result isn't the code at all.

It's the person you meet while writing it.

We Don't Know What Comes Next

Technology changes incredibly quickly.

The tools and technologies we consider essential today may look completely different a few years from now.

That's one reason I enjoy contributing to open source.

It gives me a chance to participate in that change instead of simply watching it happen.

We don't know exactly what the future will look like.

But we can influence it.

We can experiment.

We can build.

We can challenge existing ideas.

We can improve what already exists.

And we can do it together.

My Reason

So, if someone asks me why I contribute to open source, my answer is simple:

I want to build a brighter future together with other people.

I want open source to remain more than a collection of repositories.

I want it to remain a place where ideas cross borders, where different perspectives meet, and where people with completely different backgrounds can work toward the same goal.

Most importantly, I want a contribution from one person to have the potential to become useful to someone they've never met.

That's the part of open source that keeps me contributing.

Not because I have nothing else to do.

Because I believe it's worth doing.