commit db825e5bec5c409b82c4b15644094c62713e4126
parent ec76223181b2fd989476efc0b162e8c2af864d9b
Author: Cem Keylan <cem@ckyln.com>
Date: Wed, 13 Oct 2021 00:07:15 +0200
update
Diffstat:
11 files changed, 375 insertions(+), 2 deletions(-)
diff --git a/docs/blog.html b/docs/blog.html
@@ -44,6 +44,7 @@
<h2>Blog Index</h2>
<ul>
+<li>Oct 12 2021 - <a href="/blog/20211012-execline.html">My thoughts on execline</a></li>
<li>Oct 02 2020 - <a href="/blog/20201002-reimplementing-sysmgr-in-c.html">Reimplementing <code>sysmgr</code> in C</a></li>
<li>Sep 08 2020 - <a href="/blog/20200908-trust-in-distributed-environments.html">Trust in Distributed Environments</a></li>
<li>Aug 28 2020 - <a href="/blog/20200828-wpa-add-script.html">wpa_add script</a></li>
diff --git a/docs/blog.txt b/docs/blog.txt
@@ -1,6 +1,7 @@
Blog Index
--------------------------------------------------------------------------------
+* Oct 12 2021 - [My thoughts on execline](/blog/20211012-execline.html)
* Oct 02 2020 - [Reimplementing `sysmgr` in C](/blog/20201002-reimplementing-sysmgr-in-c.html)
* Sep 08 2020 - [Trust in Distributed Environments](/blog/20200908-trust-in-distributed-environments.html)
* Aug 28 2020 - [wpa_add script](/blog/20200828-wpa-add-script.html)
diff --git a/docs/blog/20211012-execline.html b/docs/blog/20211012-execline.html
@@ -0,0 +1,82 @@
+<!DOCTYPE HTML>
+<html lan=en>
+ <head>
+ <title>My thoughts on execline | Cem's Website</title>
+ <meta charset="utf-8">
+ <meta name="Description" content="Cem Keylan's Website">
+ <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
+ <style>
+ html {font-family:monospace;font-size:16px;color:#282a36;}
+ body {
+ width: 90%;
+ max-width: 1050px;
+ margin-left: auto;
+ margin-right: auto;
+ margin-top: 20px;
+ overflow: none;
+ overflow-y: scroll;
+ padding-right: 10px;
+ padding-left: 10px;
+ }
+ a{text-decoration:none;font-weight:bold;color:#282a36;}
+ a:hover{text-decoration:underline;}
+ @media (prefers-color-scheme: dark) {
+ html {color: white;background:#282a36;}
+ a{color:white;}
+ }
+ </style>
+ <link rel="stylesheet" href="/static/syntax.css">
+ <script src="/static/highlight.pack.js"></script>
+ <script>hljs.initHighlightingOnLoad();</script>
+ </head>
+ <body>
+ <div class="header">
+ <nav>
+ <a href='/'>index</a> |
+ <a href="/software.html">software</a> |
+ <a href="/blog.html">blog</a> |
+ <a href="/contact.html">contact</a> |
+ <a href="/sysmgr">sysmgr</a> |
+ </nav>
+ </div>
+ <hr>
+ <p>
+<h1>My thoughts on execline</h1>
+
+<p>With the gaining popularity of the <a href="https://www.skarnet.org/software/s6-rc/">s6-rc</a>, I have recently decided to check out
+<a href="https://www.skarnet.org/software/execline/">execline</a>. It is a shell-like scripting language that is built around chaining
+commands together. There is no interpreter, there is no ‘built-in’ functionality
+even though the docs might make you think there are. Execline is best described
+as a suite of tools that imitate the functionality of a shell.</p>
+
+<p>There are a ton of information on the execline’s page, especially discussing
+why skarnet prefers execline instead of <code>/bin/sh</code>. Those points are mostly
+valid, shells are a nightmare, and they suck at being compliant to the POSIX
+specification. What I don’t agree with the <a href="http://www.skarnet.org/software/execline/dieshdiedie.html">why not sh</a> page, however, is the
+part on performance. Even though execline does not have an interactive shell
+implementation of its own, it is still much slower than other shells simply by
+its design. Since the design of execline is built on process chaining, it
+requires spawning new processes for things as basic as variable declaration.
+Variable manipulation is the cheapest operation you would expect from a shell,
+but in execline, every operation costs the same regardless of how simple it is.</p>
+
+<p>Throughout my weeks of toying around with execline, I have came to the
+conclusion that execline is much better in simple scripts only. Execline is
+as usable as any shell out there, but even with its advantages over <code>sh</code>,
+execline is only better if it’s simple. Execline is really good for certain
+specific situations such as service scripts (as used in s6-rc), or where you
+were already meant to chain a couple of commands together. After all, skarnet
+already presents these limitations on the website of execline.</p>
+
+<p>Execline can be leveraged as how s6-rc compiles service databases with other
+utilities, but I don’t think it can be used as a shell replacement itself. It’s
+not the next shiny thing to jump on to replace all your shell scripts with
+(unless you have really basic shell scripts). It does not have the flexibility
+nor the performance of the shell for scripts that can be considered a little
+over than the “basic”.</p>
+ </p>
+ <a href="/blog/20211012-execline.txt">This page in plain-text</a>
+ <hr>
+ <p class=footer>Copyright © 2019-2020 Cem Keylan</p>
+ </body>
+</html>
diff --git a/docs/blog/20211012-execline.txt b/docs/blog/20211012-execline.txt
@@ -0,0 +1,39 @@
+My thoughts on execline
+================================================================================
+
+With the gaining popularity of the [s6-rc], I have recently decided to check out
+[execline]. It is a shell-like scripting language that is built around chaining
+commands together. There is no interpreter, there is no 'built-in' functionality
+even though the docs might make you think there are. Execline is best described
+as a suite of tools that imitate the functionality of a shell.
+
+There are a ton of information on the execline's page, especially discussing
+why skarnet prefers execline instead of `/bin/sh`. Those points are mostly
+valid, shells are a nightmare, and they suck at being compliant to the POSIX
+specification. What I don't agree with the [why not sh] page, however, is the
+part on performance. Even though execline does not have an interactive shell
+implementation of its own, it is still much slower than other shells simply by
+its design. Since the design of execline is built on process chaining, it
+requires spawning new processes for things as basic as variable declaration.
+Variable manipulation is the cheapest operation you would expect from a shell,
+but in execline, every operation costs the same regardless of how simple it is.
+
+Throughout my weeks of toying around with execline, I have came to the
+conclusion that execline is much better in simple scripts only. Execline is
+as usable as any shell out there, but even with its advantages over `sh`,
+execline is only better if it's simple. Execline is really good for certain
+specific situations such as service scripts (as used in s6-rc), or where you
+were already meant to chain a couple of commands together. After all, skarnet
+already presents these limitations on the website of execline.
+
+Execline can be leveraged as how s6-rc compiles service databases with other
+utilities, but I don't think it can be used as a shell replacement itself. It's
+not the next shiny thing to jump on to replace all your shell scripts with
+(unless you have really basic shell scripts). It does not have the flexibility
+nor the performance of the shell for scripts that can be considered a little
+over than the "basic".
+
+
+[s6-rc]: https://www.skarnet.org/software/s6-rc/
+[execline]: https://www.skarnet.org/software/execline/
+[why not sh]: http://www.skarnet.org/software/execline/dieshdiedie.html
diff --git a/docs/index.html b/docs/index.html
@@ -61,6 +61,46 @@ able to view this site in your favourite pager! In your terminal simply type:</p
<hr />
+<h1>My thoughts on execline</h1>
+
+<p><a href="/blog/20211012-execline.html">Permalink</a></p>
+
+<p>Date: Oct 12 2021</p>
+
+<p>With the gaining popularity of the <a href="https://www.skarnet.org/software/s6-rc/">s6-rc</a>, I have recently decided to check out
+<a href="https://www.skarnet.org/software/execline/">execline</a>. It is a shell-like scripting language that is built around chaining
+commands together. There is no interpreter, there is no ‘built-in’ functionality
+even though the docs might make you think there are. Execline is best described
+as a suite of tools that imitate the functionality of a shell.</p>
+
+<p>There are a ton of information on the execline’s page, especially discussing
+why skarnet prefers execline instead of <code>/bin/sh</code>. Those points are mostly
+valid, shells are a nightmare, and they suck at being compliant to the POSIX
+specification. What I don’t agree with the <a href="http://www.skarnet.org/software/execline/dieshdiedie.html">why not sh</a> page, however, is the
+part on performance. Even though execline does not have an interactive shell
+implementation of its own, it is still much slower than other shells simply by
+its design. Since the design of execline is built on process chaining, it
+requires spawning new processes for things as basic as variable declaration.
+Variable manipulation is the cheapest operation you would expect from a shell,
+but in execline, every operation costs the same regardless of how simple it is.</p>
+
+<p>Throughout my weeks of toying around with execline, I have came to the
+conclusion that execline is much better in simple scripts only. Execline is
+as usable as any shell out there, but even with its advantages over <code>sh</code>,
+execline is only better if it’s simple. Execline is really good for certain
+specific situations such as service scripts (as used in s6-rc), or where you
+were already meant to chain a couple of commands together. After all, skarnet
+already presents these limitations on the website of execline.</p>
+
+<p>Execline can be leveraged as how s6-rc compiles service databases with other
+utilities, but I don’t think it can be used as a shell replacement itself. It’s
+not the next shiny thing to jump on to replace all your shell scripts with
+(unless you have really basic shell scripts). It does not have the flexibility
+nor the performance of the shell for scripts that can be considered a little
+over than the “basic”.</p>
+
+<hr />
+
<h1>Reimplementing <code>sysmgr</code> in C</h1>
<p><a href="/blog/20201002-reimplementing-sysmgr-in-c.html">Permalink</a></p>
diff --git a/docs/index.txt b/docs/index.txt
@@ -22,6 +22,52 @@ able to view this site in your favourite pager! In your terminal simply type:
********************************************************************************
+My thoughts on execline
+================================================================================
+[Permalink](/blog/20211012-execline.html)
+
+Date: Oct 12 2021
+
+
+With the gaining popularity of the [s6-rc], I have recently decided to check out
+[execline]. It is a shell-like scripting language that is built around chaining
+commands together. There is no interpreter, there is no 'built-in' functionality
+even though the docs might make you think there are. Execline is best described
+as a suite of tools that imitate the functionality of a shell.
+
+There are a ton of information on the execline's page, especially discussing
+why skarnet prefers execline instead of `/bin/sh`. Those points are mostly
+valid, shells are a nightmare, and they suck at being compliant to the POSIX
+specification. What I don't agree with the [why not sh] page, however, is the
+part on performance. Even though execline does not have an interactive shell
+implementation of its own, it is still much slower than other shells simply by
+its design. Since the design of execline is built on process chaining, it
+requires spawning new processes for things as basic as variable declaration.
+Variable manipulation is the cheapest operation you would expect from a shell,
+but in execline, every operation costs the same regardless of how simple it is.
+
+Throughout my weeks of toying around with execline, I have came to the
+conclusion that execline is much better in simple scripts only. Execline is
+as usable as any shell out there, but even with its advantages over `sh`,
+execline is only better if it's simple. Execline is really good for certain
+specific situations such as service scripts (as used in s6-rc), or where you
+were already meant to chain a couple of commands together. After all, skarnet
+already presents these limitations on the website of execline.
+
+Execline can be leveraged as how s6-rc compiles service databases with other
+utilities, but I don't think it can be used as a shell replacement itself. It's
+not the next shiny thing to jump on to replace all your shell scripts with
+(unless you have really basic shell scripts). It does not have the flexibility
+nor the performance of the shell for scripts that can be considered a little
+over than the "basic".
+
+
+[s6-rc]: https://www.skarnet.org/software/s6-rc/
+[execline]: https://www.skarnet.org/software/execline/
+[why not sh]: http://www.skarnet.org/software/execline/dieshdiedie.html
+
+********************************************************************************
+
Reimplementing `sysmgr` in C
================================================================================
[Permalink](/blog/20201002-reimplementing-sysmgr-in-c.html)
diff --git a/docs/rss.xml b/docs/rss.xml
@@ -9,7 +9,46 @@
<description>Personal blog/website on Linux/tech/nerdy stuff</description>
<link>https://cemkeylan.com</link>
<atom:link href="https://cemkeylan.com/rss.xml" rel="self" type="application/rss+xml" />
- <lastBuildDate>Sat Oct 10 2020 10:00</lastBuildDate>
+ <lastBuildDate>Tue Oct 12 2021 22:00</lastBuildDate>
+<item>
+<title>My thoughts on execline</title>
+<pubDate>Tue, 12 Oct 2021</pubDate>
+<dc:creator>Cem Keylan</dc:creator>
+<link>https://cemkeylan.com/blog/20211012-execline.html</link>
+<description><h1>My thoughts on execline</h1>
+
+<p>With the gaining popularity of the <a href="https://www.skarnet.org/software/s6-rc/">s6-rc</a>, I have recently decided to check out
+<a href="https://www.skarnet.org/software/execline/">execline</a>. It is a shell-like scripting language that is built around chaining
+commands together. There is no interpreter, there is no &lsquo;built-in&rsquo; functionality
+even though the docs might make you think there are. Execline is best described
+as a suite of tools that imitate the functionality of a shell.</p>
+
+<p>There are a ton of information on the execline&rsquo;s page, especially discussing
+why skarnet prefers execline instead of <code>/bin/sh</code>. Those points are mostly
+valid, shells are a nightmare, and they suck at being compliant to the POSIX
+specification. What I don&rsquo;t agree with the <a href="http://www.skarnet.org/software/execline/dieshdiedie.html">why not sh</a> page, however, is the
+part on performance. Even though execline does not have an interactive shell
+implementation of its own, it is still much slower than other shells simply by
+its design. Since the design of execline is built on process chaining, it
+requires spawning new processes for things as basic as variable declaration.
+Variable manipulation is the cheapest operation you would expect from a shell,
+but in execline, every operation costs the same regardless of how simple it is.</p>
+
+<p>Throughout my weeks of toying around with execline, I have came to the
+conclusion that execline is much better in simple scripts only. Execline is
+as usable as any shell out there, but even with its advantages over <code>sh</code>,
+execline is only better if it&rsquo;s simple. Execline is really good for certain
+specific situations such as service scripts (as used in s6-rc), or where you
+were already meant to chain a couple of commands together. After all, skarnet
+already presents these limitations on the website of execline.</p>
+
+<p>Execline can be leveraged as how s6-rc compiles service databases with other
+utilities, but I don&rsquo;t think it can be used as a shell replacement itself. It&rsquo;s
+not the next shiny thing to jump on to replace all your shell scripts with
+(unless you have really basic shell scripts). It does not have the flexibility
+nor the performance of the shell for scripts that can be considered a little
+over than the &ldquo;basic&rdquo;.</p></description>
+</item>
<item>
<title>Reimplementing `sysmgr` in C</title>
<pubDate>Fri, 02 Oct 2020</pubDate>
diff --git a/src/blog.md b/src/blog.md
@@ -1,6 +1,7 @@
Blog Index
--------------------------------------------------------------------------------
+* Oct 12 2021 - [My thoughts on execline](/blog/20211012-execline.html)
* Oct 02 2020 - [Reimplementing `sysmgr` in C](/blog/20201002-reimplementing-sysmgr-in-c.html)
* Sep 08 2020 - [Trust in Distributed Environments](/blog/20200908-trust-in-distributed-environments.html)
* Aug 28 2020 - [wpa_add script](/blog/20200828-wpa-add-script.html)
diff --git a/src/blog/20211012-execline.md b/src/blog/20211012-execline.md
@@ -0,0 +1,39 @@
+My thoughts on execline
+================================================================================
+
+With the gaining popularity of the [s6-rc], I have recently decided to check out
+[execline]. It is a shell-like scripting language that is built around chaining
+commands together. There is no interpreter, there is no 'built-in' functionality
+even though the docs might make you think there are. Execline is best described
+as a suite of tools that imitate the functionality of a shell.
+
+There are a ton of information on the execline's page, especially discussing
+why skarnet prefers execline instead of `/bin/sh`. Those points are mostly
+valid, shells are a nightmare, and they suck at being compliant to the POSIX
+specification. What I don't agree with the [why not sh] page, however, is the
+part on performance. Even though execline does not have an interactive shell
+implementation of its own, it is still much slower than other shells simply by
+its design. Since the design of execline is built on process chaining, it
+requires spawning new processes for things as basic as variable declaration.
+Variable manipulation is the cheapest operation you would expect from a shell,
+but in execline, every operation costs the same regardless of how simple it is.
+
+Throughout my weeks of toying around with execline, I have came to the
+conclusion that execline is much better in simple scripts only. Execline is
+as usable as any shell out there, but even with its advantages over `sh`,
+execline is only better if it's simple. Execline is really good for certain
+specific situations such as service scripts (as used in s6-rc), or where you
+were already meant to chain a couple of commands together. After all, skarnet
+already presents these limitations on the website of execline.
+
+Execline can be leveraged as how s6-rc compiles service databases with other
+utilities, but I don't think it can be used as a shell replacement itself. It's
+not the next shiny thing to jump on to replace all your shell scripts with
+(unless you have really basic shell scripts). It does not have the flexibility
+nor the performance of the shell for scripts that can be considered a little
+over than the "basic".
+
+
+[s6-rc]: https://www.skarnet.org/software/s6-rc/
+[execline]: https://www.skarnet.org/software/execline/
+[why not sh]: http://www.skarnet.org/software/execline/dieshdiedie.html
diff --git a/src/index.md b/src/index.md
@@ -22,6 +22,52 @@ able to view this site in your favourite pager! In your terminal simply type:
********************************************************************************
+My thoughts on execline
+================================================================================
+[Permalink](/blog/20211012-execline.html)
+
+Date: Oct 12 2021
+
+
+With the gaining popularity of the [s6-rc], I have recently decided to check out
+[execline]. It is a shell-like scripting language that is built around chaining
+commands together. There is no interpreter, there is no 'built-in' functionality
+even though the docs might make you think there are. Execline is best described
+as a suite of tools that imitate the functionality of a shell.
+
+There are a ton of information on the execline's page, especially discussing
+why skarnet prefers execline instead of `/bin/sh`. Those points are mostly
+valid, shells are a nightmare, and they suck at being compliant to the POSIX
+specification. What I don't agree with the [why not sh] page, however, is the
+part on performance. Even though execline does not have an interactive shell
+implementation of its own, it is still much slower than other shells simply by
+its design. Since the design of execline is built on process chaining, it
+requires spawning new processes for things as basic as variable declaration.
+Variable manipulation is the cheapest operation you would expect from a shell,
+but in execline, every operation costs the same regardless of how simple it is.
+
+Throughout my weeks of toying around with execline, I have came to the
+conclusion that execline is much better in simple scripts only. Execline is
+as usable as any shell out there, but even with its advantages over `sh`,
+execline is only better if it's simple. Execline is really good for certain
+specific situations such as service scripts (as used in s6-rc), or where you
+were already meant to chain a couple of commands together. After all, skarnet
+already presents these limitations on the website of execline.
+
+Execline can be leveraged as how s6-rc compiles service databases with other
+utilities, but I don't think it can be used as a shell replacement itself. It's
+not the next shiny thing to jump on to replace all your shell scripts with
+(unless you have really basic shell scripts). It does not have the flexibility
+nor the performance of the shell for scripts that can be considered a little
+over than the "basic".
+
+
+[s6-rc]: https://www.skarnet.org/software/s6-rc/
+[execline]: https://www.skarnet.org/software/execline/
+[why not sh]: http://www.skarnet.org/software/execline/dieshdiedie.html
+
+********************************************************************************
+
Reimplementing `sysmgr` in C
================================================================================
[Permalink](/blog/20201002-reimplementing-sysmgr-in-c.html)
diff --git a/src/rss.xml b/src/rss.xml
@@ -9,7 +9,46 @@
<description>Personal blog/website on Linux/tech/nerdy stuff</description>
<link>https://cemkeylan.com</link>
<atom:link href="https://cemkeylan.com/rss.xml" rel="self" type="application/rss+xml" />
- <lastBuildDate>Sat Oct 10 2020 10:00</lastBuildDate>
+ <lastBuildDate>Tue Oct 12 2021 22:00</lastBuildDate>
+<item>
+<title>My thoughts on execline</title>
+<pubDate>Tue, 12 Oct 2021</pubDate>
+<dc:creator>Cem Keylan</dc:creator>
+<link>https://cemkeylan.com/blog/20211012-execline.html</link>
+<description><h1>My thoughts on execline</h1>
+
+<p>With the gaining popularity of the <a href="https://www.skarnet.org/software/s6-rc/">s6-rc</a>, I have recently decided to check out
+<a href="https://www.skarnet.org/software/execline/">execline</a>. It is a shell-like scripting language that is built around chaining
+commands together. There is no interpreter, there is no &lsquo;built-in&rsquo; functionality
+even though the docs might make you think there are. Execline is best described
+as a suite of tools that imitate the functionality of a shell.</p>
+
+<p>There are a ton of information on the execline&rsquo;s page, especially discussing
+why skarnet prefers execline instead of <code>/bin/sh</code>. Those points are mostly
+valid, shells are a nightmare, and they suck at being compliant to the POSIX
+specification. What I don&rsquo;t agree with the <a href="http://www.skarnet.org/software/execline/dieshdiedie.html">why not sh</a> page, however, is the
+part on performance. Even though execline does not have an interactive shell
+implementation of its own, it is still much slower than other shells simply by
+its design. Since the design of execline is built on process chaining, it
+requires spawning new processes for things as basic as variable declaration.
+Variable manipulation is the cheapest operation you would expect from a shell,
+but in execline, every operation costs the same regardless of how simple it is.</p>
+
+<p>Throughout my weeks of toying around with execline, I have came to the
+conclusion that execline is much better in simple scripts only. Execline is
+as usable as any shell out there, but even with its advantages over <code>sh</code>,
+execline is only better if it&rsquo;s simple. Execline is really good for certain
+specific situations such as service scripts (as used in s6-rc), or where you
+were already meant to chain a couple of commands together. After all, skarnet
+already presents these limitations on the website of execline.</p>
+
+<p>Execline can be leveraged as how s6-rc compiles service databases with other
+utilities, but I don&rsquo;t think it can be used as a shell replacement itself. It&rsquo;s
+not the next shiny thing to jump on to replace all your shell scripts with
+(unless you have really basic shell scripts). It does not have the flexibility
+nor the performance of the shell for scripts that can be considered a little
+over than the &ldquo;basic&rdquo;.</p></description>
+</item>
<item>
<title>Reimplementing `sysmgr` in C</title>
<pubDate>Fri, 02 Oct 2020</pubDate>
