Top AI Repos — open-source AI, indexed and scored
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Guidance for mollusks (WIP)
| Date | Stars |
|---|---|
| 2026-07-24 | 499 |
| 2026-07-25 | 499 |
| 2026-07-28 | 499 |
| 2026-07-30 | 499 |
| 2026-08-06 | 499 |
Today
— stars today
This week
— stars this week
This month
— stars this month
Momentum
0.0
growth rate 0.00%/day
> All the broken
> Too many broken
> Shells
> In our shellmounds
— [Grayceon, Shellmounds](https://grayceon.bandcamp.com/track/shellmounds)
# Build Your Own Shell
This is the material for a series of workshops I ran at my workplace
on how to write a Unix shell.
The focus is slightly more on building an interactive shell than a
scripting-oriented shell, only because I think this is more
gratifying, even if it's less useful.
Be warned that some of the suggestions and discussion make opinionated
choices without discussing equally-valid alternatives.
This is a work in progress and there may remain many infelicities.
Patches Thoughtfully Considered. Feel free to report issues via
[Github](https://github.com/tokenrove/build-your-own-shell/issues).
## Why write your own shell?
The shell is at the heart of Unix. It's the glue that makes all the
little Unix tools work together so well. Understanding it sheds light
on many of Unix's important ideas, and writing our own is the best
path to that understanding.
This workshop has three goals:
- to give you a better understanding of how Unix processes work;
- this will make you better at designing and understanding software
that runs on Unix;
- to clarify some common misunderstandings of POSIX shells;
- this will make you more effective at using and scripting
ubiquitous shells like bash;
- to help you build a working implementation of a shell you can be
excited about working on.
- there are endless personal customizations you can make to your
own shell, and can help you think about how you interact with
your computer and how it might be different.
(some of this rationale is expanded on in my blog post, [Building
shells with a grain of salt])
[Building shells with a grain of salt]: https://www.cipht.net/2017/10/17/build-your-own-shell.html
## How to use this repository
I've tried to break this up into progressive stages that cover mostly
orthogonal topics. Each stage contains a description of the
facilities that will be discussed, a list of manpages to consult, and
a set of tests. I've tried to also hint at some functionality that is
fun but not necessary for the tests to pass.
In the root of this repository, there is a script called `validate`;
you can run all the tests against your shell-in-progress by specifying
the path to your shell's executable, like this:
``` shell
$ ./validate ../mysh/mysh
```
It should tell you what stage you need to implement next. You can
also run a stage by itself, or an individual test:
```shell
$ ./validate ../mysh/mysh stage_2
$ ./validate ../mysh/mysh stage_3 03
```
To run the tests, you will need [`expect`], which is usually in a
package called `expect`, and a C compiler. The way the tests are
implemented is less robust than one might hope, but should suffice for
our pedagogical goals. They are unfortunately somewhat timing
sensitive, such that some tests will be flaky. If you encounter a
specifically flaky test, please let me know.
The tests assume you will be implementing a vanilla Bourne-flavored
shell with some ksh influences. Feel free to experiment with
alternate syntax, but if so, you may need to adjust the tests. Except
where specifically noted, `bash` (and `ksh`) should pass all the
tests, so you can "test the tests" that way. (Try `./validate
/bin/bash`.) Likewise, `cat` should fail all the tests.
Originally, I targeted plain `/bin/sh`, but I decided the material in
stage 5 was too important. Still, `dash` will pass everything but
stage 5. There are also some other minor compatibility differences
with some existing shells; you may run into them if you try them out.
Any failure (of a supposedly POSIX shell) that isn't documented in the
comments of a test should be reported as a bug.
[`prove`]: http://perldoc.perl.org/prove.html
[`expect`]: http://wiki.tcl.tk/201
# Stages
## 1: [fork/exec/wait](stage_1.md)
In which we discuss the basics of Unix processes, write the simplExcerpt of 13,049 characters
Read on GitHubWould you bet a product on this? Bounded 0–100 and slow moving.
matched fp:eb983d3260dade54, topic:tutorial, readme:a list of