Massive formatting and added figcaption

1 files changed, 74 insertions, 84 deletions

diff --git a/content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md b/content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md
index 17fdaf6..1abfd1e 100644
--- a/content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md
+++ b/content/posts/2023-05-31-re-inventing-task-runner-that-i-actually-used-daily.md
@@ -5,55 +5,49 @@ date: 2023-05-31T12:21:10+02:00
 draft: false
 ---
 
-Couple of months ago I had this brilliant idea of re-inventing the wheel
-by making an alternative for make. And so I went. Boldly into the
-battle. And to my big surprise my attempt resulted in not a completely
-useless piece of software.
-
-My initial requirements were quite simple but soon grow into something
-more ambitious. And looking back I should have stuck to the simple
-version. My laziness was on my side this time though. Because I haven’t
-implemented some of the features I now realise I really didn’t need them
-and they would bog the whole program and make it be something it was
-never meant to be.
+Couple of months ago I had this brilliant idea of re-inventing the wheel by
+making an alternative for make. And so I went. Boldly into the battle. And to my
+big surprise my attempt resulted in not a completely useless piece of software.
+
+My initial requirements were quite simple but soon grow into something more
+ambitious. And looking back I should have stuck to the simple version. My
+laziness was on my side this time though. Because I haven’t implemented some of
+the features I now realise I really didn’t need them and they would bog the
+whole program and make it be something it was never meant to be.
 
 My basic requirements were following:
 
 - Syntax should be a tiny bit inspired by Rake and Rakefiles.
 - Should borrow the overall feel of a unit test experience.
 - Using something like Python would be a bit of an overkill.
-- The program must be statically compiled, so it can run on same
-  architecture without libc, musl dependencies or things like that.
-- Install ruby for rake is a bit overkill and can not be done
-  with certain really lightweight distributions like Alpine
-  Linux. This tool would be usable on such lightweight systems
-  for remote debugging.
-- I want to use it for more than just compiling things. I want to
-  use it as an entry-point into a project, and I want this to
-  help me indirectly document the project as well.
-- It should be an abstraction over bash shell or the default
-  system shell.
+- The program must be statically compiled, so it can run on same architecture
+  without libc, musl dependencies or things like that.
+- Install ruby for rake is a bit overkill and can not be done with certain
+  really lightweight distributions like Alpine Linux. This tool would be usable
+  on such lightweight systems for remote debugging.
+- I want to use it for more than just compiling things. I want to use it as an
+  entry-point into a project, and I want this to help me indirectly document the
+  project as well.
+- It should be an abstraction over bash shell or the default system shell.
     - Each task essentially becomes its own shell instance.
 - Must work on Linux and macOS systems.
-- By default, running `erd` list all the available tasks (when
-  I use make, I usually put a disclaimer that you should check
-  Makefile to see all available target).
+- By default, running `erd` list all the available tasks (when I use make, I
+  usually put a disclaimer that you should check Makefile to see all available
+  target).
 - Should support passing arguments when you run it from a shell.
-- Normal variable as the same as environmental variables. There
-  is no distinction. Every variable is also essentially an
-  environment variable and can be used by other programs.
-- State between tasks is not shared, and this makes this “pure”
-  shell instances.
-- Should be single-threaded for the start and later expanded
-  with `@spawn` command.
+- Normal variable as the same as environmental variables. There is no
+  distinction. Every variable is also essentially an environment variable and
+  can be used by other programs.
+- State between tasks is not shared, and this makes this “pure” shell instances.
+- Should be single-threaded for the start and later expanded with `@spawn`
+  command.
 - Variables behave like macros and are preprocessed before evaluation.
-- Should support something like `assure` that would check if
-  programs like C compiler or Python (whatever the project
-  requires) are installed on a machine.
+- Should support something like `assure` that would check if programs like C
+  compiler or Python (whatever the project requires) are installed on a machine.
 
 Quite a reasonable list of requirements. I do this things already in my
-Makefiles or/and Bash scripts. But I would like to avoid repeating
-myself every time I start working on something new.
+Makefiles or/and Bash scripts. But I would like to avoid repeating myself every
+time I start working on something new.
 
 So I started with the following syntax.
 
@@ -111,13 +105,12 @@ end
 end
 ```
 
-One thing that I really like about Errand. Yes, this is what it is
-called. And it is available at
-https://git.mitjafelicijan.com/errand.git/about/. Moving on. One thing
-that I really like is that a task is a persistent shell. By that I mean,
-that the whole task, even if it contains multiple command in one shell.
-In make each line in a target is that and you need to combine lines or
-add `\` at the end of the line.
+One thing that I really like about Errand. Yes, this is what it is called. And
+it is available at https://git.mitjafelicijan.com/errand.git/about/. Moving
+on. One thing that I really like is that a task is a persistent shell. By that I
+mean, that the whole task, even if it contains multiple command in one shell.
+In make each line in a target is that and you need to combine lines or add `\`
+at the end of the line.
 
 ```bash
 # How you do this things in make.
@@ -126,43 +119,40 @@ target:
         python script.py
 ```
 
-This solves this problem. Consider each task and what is being executed
-in that task a shell that will only close when all the tasks are
-completed.
-
-By self-documenting I mean that if you are in a directory with
-`Errandfile` in, if you only type `erd` and press enter it should by
-default display all the possible targets. In make i was doing this by
-having a first target be something like `default` that echos the message
-“Check Makefile for all available target.” Because all of the tasks in
-Errand require a message I use that to display let’s call it table of
-contents.
-
-Because I don’t use any external dependencies this whole thing can be
-statically compiled. So that also checked one of the boxes.
-
-It works on Linux and on a Mac so that’s also a bonus. I don’t believe
-this would work on Windows machines because of the way that I use shell
-instances. By you could use something like Windows Subsystem for Linux
-and run it in there. That is a valid option.
-
-To finish this essay off, how was it to use it in “real life”. I have to
-be honest. Some of the missing features still bother me. `@dotenv`
-directive is still missing and I need to implement this ASAP.
-
-Another thing that needs to happen is support for streaming output.
-Currently commands like `docker-compose` that runs in foreground mode is
-not compatible with Errand. So commands that stream output are an issue.
-I need to revisit how I initiate shell and how I read stdout and stderr.
-But that shouldn’t be a problem.
-
-I have been very satisfied with this thing. I am pleasantly surprised by
-how useful it is. I really wanted to test this in the wild before I
-commit to it. I have more abandoned project than Google and it’s
-bringing a massive shame to my family at this point. So I wanted to be
-sure that this is even useful. And it actually is. Quite surprised at
-myself.
-
-I really need to package this now and write proper docs. And maybe
-rewrite tokeniser. Its atrocious right now. Site to behold! But that is
-an issue for another time.
+This solves this problem. Consider each task and what is being executed in that
+task a shell that will only close when all the tasks are completed.
+
+By self-documenting I mean that if you are in a directory with `Errandfile` in,
+if you only type `erd` and press enter it should by default display all the
+possible targets. In make i was doing this by having a first target be something
+like `default` that echos the message “Check Makefile for all available target.”
+Because all of the tasks in Errand require a message I use that to display let’s
+call it table of contents.
+
+Because I don’t use any external dependencies this whole thing can be statically
+compiled. So that also checked one of the boxes.
+
+It works on Linux and on a Mac so that’s also a bonus. I don’t believe this
+would work on Windows machines because of the way that I use shell instances. By
+you could use something like Windows Subsystem for Linux and run it in
+there. That is a valid option.
+
+To finish this essay off, how was it to use it in “real life”. I have to be
+honest. Some of the missing features still bother me. `@dotenv` directive is
+still missing and I need to implement this ASAP.
+
+Another thing that needs to happen is support for streaming output. Currently
+commands like `docker-compose` that runs in foreground mode is not compatible
+with Errand. So commands that stream output are an issue.  I need to revisit how
+I initiate shell and how I read stdout and stderr.  But that shouldn’t be a
+problem.
+
+I have been very satisfied with this thing. I am pleasantly surprised by how
+useful it is. I really wanted to test this in the wild before I commit to it. I
+have more abandoned project than Google and it’s bringing a massive shame to my
+family at this point. So I wanted to be sure that this is even useful. And it
+actually is. Quite surprised at myself.
+
+I really need to package this now and write proper docs. And maybe rewrite
+tokeniser. Its atrocious right now. Site to behold! But that is an issue for
+another time.