bin/index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
{{ define "wat" }}
<!doctype html>
<html>
<head>
<style>
body {color: #ffffff; background-color: #222222; font-family: monospace;}
a {color: #ffffff;}
pre {color: #ffffff;}
sub {color: #4e4e4e;}
h1,h2,h4,h4,h5 {color: #ffffff96;}
</style>
<!-- a j3s.sh production, again, lmao -->
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>use POSIX shell</title>
</head>
<body>
<small>#!/bin/sh -eu</small>
<br>
<small>#</small>
<br>
<small># a website dedicated to promoting</small>
<br>
<small># POSIX shell scripting, plus a few</small>
<br>
<small># useful utilities</small>
<br>
<br>
<small>cat <<EOF</small>
<h4># what is POSIX shell?</h4>
<p>POSIX shell is any shell script that adheres to the POSIX standard. <a href="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html">See this horrible document for excruciating details</a>. basically, if you write a shell script and follow the POSIX standard, you can mostly guarantee that it'll work _almost everywhere_.</p>
<p>compare this to writing a bash/zsh/etc script. it is likely that a given bash script will only ever work with a bash interpreter - and potentially only on the version of bash that you happen to have installed.</p>
<p>if you had just written a POSIX shell script instead, it would work forever and everywhere.</p>
<p>imho there are two types of shell scripts in the world:</p>
<ul>- small, portable, eternal, maintainable POSIX shell scripts</ul>
<ul>- incomprehensible horrifying spaghetti nightmare</ul>
<h4># (please) use POSIX shell</h4>
<p>POSIX shell is portable, easy to maintain, and works for 99% of scripting use-cases. this site provides a few helpful references. they are intended for consumption by command line utilities (so please, use curl!)</p>
<p>this site serves as a motivator as well as a desparate plea (USE POSIX SHELL PLS, I AM SO SICK OF ARCANE BASH SCRIPTS) and also a quick reference for POSIX compatability.</p>
<h4># tools</h4>
<p>all of these endpoints are easily consumable via curl (or wget or elinks or whatever) for ease of access.</p>
<hr>
<p>get api help: <a href="https://useposix.sh/help">https://useposix.sh/help</a></p>
<hr>
<p>see POSIX reference for ls: <a href="https://useposix.sh/ls">https://useposix.sh/ls</a></p>
<hr>
<!-- lmao escape -->
<h4># tips</h4>
<h4># if it starts feeling confusing as fuck, stop using shell</h4>
<p>getting stuck in shell hell</p>
<p>when you write only POSIX shell, it becomes very obvious when you should be using a real programming language instead. your script will begin seeming impossible to reason about. while shell is very powerful, it's also incredibly loose. it is fast and very productive, but becomes impenetrable VERY fast. if you cannot hold the entire script in your head, use a real language. for example, do you:</p>
<ul>- need arrays? stop using shell</ul>
<ul>- need strong types? stop using shell</ul>
<ul>- need a lot of dependencies? stop using shell</ul>
<ul>- need compile/runtime safety? stop using shell</ul>
<ul>- lose your sanity when you open your script? stop using shell</ul>
<p>see how easy it is? simple, maintainable shell. or none at all.</p>
<h4>start your script with #!/bin/sh</h4>
<p>your shell script should start like this:</p>
<p>#!/bin/sh</p>
<p>do _not_ use</p>
<p>#!/usr/bin/env sh</p>
<p>people will argue that the /usr/bin/env method is superior because sh may be in a non-standard location. i would suggest that it is more likely that env is misplaced than sh - POSIX defines /bin/sh, it does not define /usr/bin/env. so use #!/bin/sh every single time and get on with your life.</p>
<br>
<br>
<br>
<br>
<small>EOF</small>
</body>
</html>
{{ end }}