Patrick Ferris 2025 5 19 https://patrick.sirref.org/pouzin-shell/ pouzin-shell /pouzin-shell/ Metashells › Louis Pouzin's "SHELL" I spent some time reading part of the multics design documentation this week. Louis Pouzin coined the term "SHELL" in this document, and I was reminded yet again just how important it is to be a good writer even as a "computer science researcher". For example, this excerpt from the requirements section of the document The previous definitions imply that a command MUST be designed while keeping in mind the user, sitting at his console, wondering about what might be going on, mistyping or forgetting arguments, even if fully aware of the conventions, and possibly interfering with the command by hasty quits, carriage returns, and other temperamental reactions. And then later, when defining the "SHELL". We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under console control (presently called command level). This procedure acts as an interface between console messages and subroutine. The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure, inside of another program if it were called. Hereafter, for simplification, we shall refer to that procedure as the "SHELL". It still surprises how little the undergraduate degree in computer science at Cambridge focuses on writing skills. References Louis Pouzin 2013 https://patrick.sirref.org/pouzin-shell-2013/ pouzin-shell-2013 /pouzin-shell-2013/ The Origin of the Shell Reference https://people.csail.mit.edu/saltzer/Multics/Multics-Documents/MDN/MDN-4.pdf Multics Documents Louis Pouzin 2013 Abstract How RUNCOM was created for CTSS and the shell was designed for Multics by Louis Pouzin. Context Patrick Ferris 2026 3 19 https://patrick.sirref.org/weekly-2026-w12/ weekly-2026-w12 /weekly-2026-w12/ A POSIX Shell in OCaml Long time, no weekly. Since the start of this year I have been building a POSIX shell in OCaml called msh (with the underlying library called Merry). Merry is available online now. Patrick Ferris 2026 3 19 A POSIX(ish) shell in OCaml Merry is a POSIX(ish) in OCaml. It uses Eio alongside Morbig (a static parser for POSIX shell). Patrick Ferris 2026 3 19 Why another (POSIX) shell? Shells have been around for a long time. In my research on the notion of metashell I wrote about Louis Pouzin originally coining the term: Patrick Ferris 2025 5 19 https://patrick.sirref.org/pouzin-shell/ pouzin-shell /pouzin-shell/ Metashells › Louis Pouzin's "SHELL" I spent some time reading part of the multics design documentation this week. Louis Pouzin coined the term "SHELL" in this document, and I was reminded yet again just how important it is to be a good writer even as a "computer science researcher". For example, this excerpt from the requirements section of the document The previous definitions imply that a command MUST be designed while keeping in mind the user, sitting at his console, wondering about what might be going on, mistyping or forgetting arguments, even if fully aware of the conventions, and possibly interfering with the command by hasty quits, carriage returns, and other temperamental reactions. And then later, when defining the "SHELL". We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under console control (presently called command level). This procedure acts as an interface between console messages and subroutine. The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure, inside of another program if it were called. Hereafter, for simplification, we shall refer to that procedure as the "SHELL". It still surprises how little the undergraduate degree in computer science at Cambridge focuses on writing skills. I built Shelter exploring the idea of a shell-like interface that allowed users to undo their shell actions (amongst other cool tricks). Unfortunately shell-like is not enough. Shelter cut many corners to masquerade as a shell (e.g. appending env to understand how a command may have altered the execution environment). I felt it was necessary to make Shelter a "SHELL"! To do that, I needed a solid foundation to build on. msh, the POSIX shell that comes with Merry, is by no means POSIX-complete in terms of features. But it is my daily driver at this point. It includes a pure OCaml rewrite of linenoise (a small, self-contained alternative to the venerable readline) called bruit. If you have docker installed on your machine, you can take it for a spin today: The patrickferris/msh docker image is just for trying it out. It is based on the OCaml 5.3 alpine image. Alternatively, you can build msh from source and have it available in your opam switch. There are many small paper cuts left to patch over, but most of it is porcelain (e.g. ctrl+left-arrow for moving in bruit). Unfortunately, these are the kinds of things that you will immediately stumble upon. Patrick Ferris 2026 3 19 What makes Merry different? Nothing. Merry is supposed to be a solid, POSIX-ish base to build on. Unfortunaltely, as it turns out, the subset of features from the POSIX specification that people actually use... is pretty much all of it. Every possible redirection, variable expansion, shell built-in and compound command make some appearance. Not to mention the non-POSIX bits of shell we all take for granted (e.g. &>-redirection). Merry and msh are useable. You will most likely find bugs if you use them. If, when using msh, you find something obscure happening you can enable debug mode either my setting the variable MSH_DEBUG or by invoking msh with -v -v. Patrick Ferris 2026 3 19 What's next? It is soon time to combine Shelter and Merry into the time-travelling, POSIX-ish shell that I have been trying to build since I first started working on Shelter. For this to be successful, I need Merry to be able to pass plenty of tests and right now that involves trying to install plenty of packages using tools like apk and apt. Patrick Ferris 2026 3 19 Shell MRDT What I am particularly interested in reasoning about, is the execution context in Merry. This value, alongside the file-system, constitutes a fairly deep understanding of the state that changes in each step of a shell's evaluation loop. This was, in terms of Shelter, the missing piece for truly building some kind of MRDT across shell sessions. Patrick Ferris 2026 3 19 TIFF in OCaml I picked up from the excellent Outreachy work of Tambe Salome in getting write-support in ocaml-tiff. We are getting closer to the kind of API I envisaged in this latest round of refinement and review. let / = Eio . Path . / let checkerboard ~ size = let v = Nx . zeros Nx . uint8 size ; size in for row = 0 to size - 1 do for col = 0 to size - 1 do if row + col mod 2 = 0 then Nx . set_item row ; col 254 v done done ; Nx . to_bigarray v let = Eio_posix . run @@ fun env -> Tiff_eio . with_open_out env # cwd / " example.tiff " @@ fun w -> let tif = Tiff . make checkerboard ~ size : 256 in Tiff . to_file tif w I have also been extremely pleased to see further external collaborators appearing: Nicolas helping out with metadata maintainence. Virgile adding support for reading multi-image TIFF files. Patrick Ferris 2025 5 19 https://patrick.sirref.org/weekly-2025-05-12/ weekly-2025-05-12 /weekly-2025-05-12/ Metashells This week, I feel I have been stuck fighting the OCaml ecosystem trying to keep my OxCaml work afloat. Aside from that, Ryan and I made some really nice progress with Shelter, culminating in Ryan describing it as a metashell. Patrick Ferris 2025 5 19 Shelter the metashell The main progress this week with Shelter was composing runc's terminal mode with entering raw terminal input mode on the Shelter side. This is inspired by Ryan's own work on capability interfaces. Shelter remains mostly intact, acting as an interactive shell. However, just before executing a command we switch to receiving and sending raw terminal inputs and outputs. This means tools like vim now work in Shelter! Not only that, but users can now activate an inner shell (e.g. zsh) and enjoy all the usual features of a fully-fledged shell (tab complete, fuzzy history search etc.) and upon exiting that shell, Shelter will snapshot the session. This lets you alter the granularity of snapshots from the command-line. Patrick Ferris 2025 5 19 https://patrick.sirref.org/pouzin-shell/ pouzin-shell /pouzin-shell/ Louis Pouzin's "SHELL" I spent some time reading part of the multics design documentation this week. Louis Pouzin coined the term "SHELL" in this document, and I was reminded yet again just how important it is to be a good writer even as a "computer science researcher". For example, this excerpt from the requirements section of the document The previous definitions imply that a command MUST be designed while keeping in mind the user, sitting at his console, wondering about what might be going on, mistyping or forgetting arguments, even if fully aware of the conventions, and possibly interfering with the command by hasty quits, carriage returns, and other temperamental reactions. And then later, when defining the "SHELL". We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under console control (presently called command level). This procedure acts as an interface between console messages and subroutine. The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure, inside of another program if it were called. Hereafter, for simplification, we shall refer to that procedure as the "SHELL". It still surprises how little the undergraduate degree in computer science at Cambridge focuses on writing skills. Patrick Ferris 2025 5 19 OxCaml Last week, I got a toplevel with OxCaml working. This required a serious amount of work to understand the changes Janestreet have made to obscure parts of the OCaml compiler and then working those into tools like js_of_ocaml. This week, Janestreet pushed their latest rounds of changes and of course everything broke! I spent some more time fixing it all back up. I'm not entirely sure how maintainable this is. The problem is that, whilst things compile, the programs do not work together! Only when someone uses the program do the bugs surface. Patrick Ferris 2025 5 19 Other OCaml Work I worked on some other parts of the ecosystem this week. Patrick Ferris 2025 5 19 Ppxlib I helped review some changes to enable Janestreet to have ppx rewriters via attributes (usually they are via extension points). It is a bit of a controversial change to ppxlib as we try to keep the API predictable for users: Extension points are rewritten: this means the part that is rewritten is nicely delimited by the extension points start and end. Attributes extend: attributes do not rewrite the code they are attached to but rather extend the code with new AST nodes. We will see what we decided to do (most likely provide the functionality behind some kind of "expert" interface). Patrick Ferris 2025 5 19 Tiff See Michael's notes. I spent some time trying to speedup the LZW decompression of TIFF files in the pure OCaml tiff library this week(end). The two big changes to help with this are pretty common when speeding up these parts OCaml programs: Allocate less Does less work In terms of allocating less, the original implementation was using a char list to represent LZW strings. Manipulating these becomes quite costly, particularly since the most common operation is appending a single character to the end of a list. Converting this to use OCaml's immutable string saved a ton of allocations. In terms of doing less work, I opted to bypass Cstructs sane (but slow) bounds checks in some of the "hotter" parts of the code. In particular, LZW ends up reading potentially huge arrays full of bytes one-by-one. So reading each byte needs to be quite snappy. This is a bit of a trade-off in terms of "safety" but we are in control of this code so I'm not too worried about that. Here are some results decompressing a fairly large array of some elevation data. Backlinks Related https://patrick.sirref.org/ucam/ ucam /ucam/ University of Cambridge institution https://www.cam.ac.uk/ Contributions