commit 8f3b764f9479431bc865a780a8dd9c561955b1dd
parent f74be64b960259507d2a87bd312da40a17b807b9
Author: Charlie Stanton <charlie@shtanton.xyz>
Date: Tue, 7 Sep 2021 18:07:04 +0100
Plan the piping post and start the improvements
Diffstat:
1 file changed, 24 insertions(+), 0 deletions(-)
diff --git a/posts/better_than_stdio.gmi b/posts/better_than_stdio.gmi
@@ -0,0 +1,24 @@
+I recently wrote a blog post about DSLs and also was getting frustrated by the restrictiveness of linux pipes.
+
+For quite a while I've been bothered by how restrictive using stdio with pipes is for doing complex jobs in the shell. Suppose I have an irc client which takes input and sends it as irc messages, and any received irc messages it sends as output. At first glance this seems like a good fit for stdin and stdout. Suppose that I have some irc bot that takes messages as input and outputs responses to those messages, already we can no longer use the pipes as the system of processes is cyclical, but perhaps we also want our script to forward its input to the irc client so the user can still send messages while they are running the bot? This also can't be done with pipes.
+
+Data flow can reach this desired level of flexibility if we introduce fifos and tee, fifos allow 2 processes to combine their outputs and
+
+What the shell does well.
+
+I thought these could be combined in a new exciting way with a DSL for connecting executables together in a more versatile way than stdio would allow.
+tee is good
+
+Goals:
+- Make non-linear pipelines simple and easy
+- Support message passing, don't worry about semaphores and shared memory
+- Do as little else as possible
+
+Elaborate on these 3 ideas, why not use fifos?
+
+POSIX IPC!!!! Based on System V IPC
+
+2 examples demonstrating non-linear and message passing superiority to stdio
+
+Potential problems:
+- Debugging (keep stderr?)
