contorts the shell into working in a certain manner, and in practice,
/bin/sh usually means /bin/bash.
+Long story short, use your /bin/sh interpreter for POSIX compliance.
+This isn't intended to fill that role.
+
Subcommands
------------
echo hello $ ho
echo world
-xsh: echo {echo hello {echo world} ho}
+> hello world ho
+
+ysh: echo {echo hello {echo world} ho}
echo {echo hello $ ho}
echo world
echo $
echo hello world ho
-This behavior has a few importan6 things to note about it.
+> hello world ho
+
+This behavior has a few important things to note about it.
+
1) Subcommands inherit the environment of the shell, not
a "parent" subcommand.
- 2) Subcommands do not spawn another shell.
+
+ 2) Subcommands do not spawn another shell, or if they are
+ builtin, they do not even spawn another process.
+
+ 3) Due to points 1 and 2 above, subcommand environment must be
+ carefully handled since unless you have created a subcommand
+ like {ysh -c "command"} it will NOT explicitly spawn another
+ process.
+
+ 4) Output from subcommands are stripped of the last trailing '\n'
+ to prevent odd formatting.
Variables
----------
+* NOTE: Subject to change, since this feature is not fully implemented
+ yet.
+
Variables (starting with the $ character) are resolved after subcommands
and double-quoted strings.
Consider the following:
= NAME 42
echo "${echo NAME}"
-So first, echo NAME is evaluated. The contents of the double-quoted string
-are then evaluated, leaving a string named "$NAME". This is then interpreted to
-be a variable, resulting in the output 42.
+So first, echo NAME is evaluated. The contents of the double-quoted
+string are then evaluated, leaving a string named "$NAME". This is then
+scanned for variables, resulting in the replacement of $NAME -> 42, and
+thus the output is 42.
--- /dev/null
+ysh
+-----
+
+Yeah, it's a shell.
+
+While this is a toy project that's been going on for less than a week, I plan to continue it due to the interesting technical challenges[1] a shell provides in implementation.
+
+Goals of this shell include:
+
+ * Keeping code simple when possible[2]
+
+ * When the above is impossible, documenting well what the heck is going on
+
+ * Allowing to express input in the most compact way possible[3]
+
+ * Being light on memory and not requiring odd libc "features"[4]
+
+The last goal (compactness) is at odds with POSIX-sh-compliance, so this shell makes no attempt to be usable as /bin/sh.
+
+-----------
+
+[1] Subprocess spawning (such as bash's "$(...)" and "`...`" constructs) is one hell of a thing. You'd be surprised at how much something simple like evaluation of strings increases complexity of a parser; or rather, it forces parsing and execution into the same phase.
+
+[2] Litmus test for simple: if you look at the relevant code a week later, do you know what it's doing? If the answer isn't a resounding "YES", it needs comments and potentially documentation. If the code looks like garbage, it needs a refactor. Simple doesn't mean stupid. It means not adding uneeded complexity.
+
+[3] Yes, this is contrary to the goals within the source code of the shell. Shell scripts and commands may end up looking like a clusterfuck, but shorter than POSIX sh equivalents. This is intentional.
+
+[4] Namely, avoidance of glibc-isms. GNU extensions are barred from usage. This shell is tested against musl and glibc but hopefully random embedded libc X will work as well.
projects / misc / ysh.git / commitdiff