[HN Gopher] Show HN: A Lisp Interpreter for Shell Scripting
___________________________________________________________________
Show HN: A Lisp Interpreter for Shell Scripting
Redstart is a lightweight Lisp interpreter written in C++ with a
focus on shell scripting. It lets you combine the expressive power
of Lisp with the practicality of the Unix shell: you can run
commands, capture output, pipe between processes, and still use
Lisp syntax for logic and structure. Think of it as writing your
shell scripts in Lisp instead of Bash.
Author : quintussss
Score : 100 points
Date : 2025-10-08 20:58 UTC (4 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| esrh wrote:
| awesome! I have wanted something like this for a long time.
| Currently I use a janet fork <https://github.com/eshrh/matsurika>
| with some trivial additions, the most important of which is a `$`
| macro that does what the `sh` does here. I have two questions:
|
| - I see that `sh` does not take in strings but instead lisp
| forms. How do you distinguish between variables that need to be
| substituted and commands? In my fork, the way to do variable
| substitution involves quasiquoting/unquoting. - Almost all of the
| features that make your language good for shell scripting are
| essentially syntactic features that can easily be implemented as
| a macro library for say, scheme. Why'd you choose to write in
| C++? Surely performance is not an important factor here. (I'm
| interested because I am currently working on a scheme-based shell
| scripting language).
| em-bee wrote:
| can you give an example of how variable substitution in your
| language looks like?
|
| one of the things i think a lisp for shell should have, and i
| agree that this may not be easy, but unix commands should be
| first class functions, as in, you should not need a $ or sh
| macro to make them work. the other thing is that strings should
| not be quoted, and so you need something else to designate
| variables like $path or ($ path)
| esrh wrote:
| Yes, i agree that unix commands should be first class. I did
| this for the super common stuff like ls and cp. As for
| substitution, I did exactly $ for substitution. You'd do
| something like ($ rsync -avP $src $dst), but I don't think I
| ever got around to implementing $() to evaluate forms. If you
| really need to do that then you have to quasiquote the whole
| expression and unquote the form you need to evaluate. This
| has been relatively ok for me though. I never implemented
| anything like pipes or redirection, I instead just send
| everything like that to bash.
|
| This is not really relevant to your question, but I regret
| choosing janet for this, it's too opinionated and hacking on
| C is not as fun as lisp. I started writing my own version of
| schemesh in racket, but I never got far enough.
| antics9 wrote:
| This looks good! I've seen other tries of shell scripting with
| lisp dialects but Redstart syntax looks more intuitive (from a
| shell scripting standpoint) and easy to read.
| ctenb wrote:
| Very nice! I've often wondered how close you could get to a
| POSIX-like syntax with something like this while maintaining a
| LISP semantics as much as possible. Especially pipelines are much
| easier to read with the | and > operators. I guess you need some
| sort of LISP dialect that supports infix operators
| lycopodiopsida wrote:
| Would take threading macros over pipelines every other day of
| the week.
| sshine wrote:
| You can have regular shell infix pipes combined with
| Lisp/Scheme macros as control flow. I think the tradeoff that
| Schemesh is nice, even though it does sacrifice POSIX:
|
| The best of both worlds of shell and Lisp is quick ability to
| run and pipe processes, and full programming functionality
| without the shell scripting shenanigans like obscure semantics
| and lack of good data structures.
| cess11 wrote:
| Unless someone has already provided a library for it, write
| some wrappers around pipes and forks and use OCaml utop.
|
| It's not a Lisp but close enough, I'd say. If I didn't have the
| rather extensive background of using Picolisp and some other
| REPL-like tools as a form of shell I'd probably have settled
| for utop, at least until I reached my iex era.
| sakesun wrote:
| If you don't mind .NET, BraidLang is another interesting project.
| sshine wrote:
| Related: Schemesh -- A Unix shell and Lisp REPL, fused together
|
| https://github.com/cosmos72/schemesh
|
| https://news.ycombinator.com/item?id=43061183 (7 months ago, 177
| upvotes)
| shorden wrote:
| For a blend between Lisp and a more traditional POSIX shell, I
| enjoy Emacs'
| [eshell](https://www.masteringemacs.org/article/complete-guide-
| master...).
| vindarel wrote:
| > writing your shell scripts in Lisp instead of Bash.
|
| in _a_ Lisp ;)
|
| Related, for Common Lisp:
|
| - unix in lisp https://github.com/PuellaeMagicae/unix-in-
| lispMount Unix system into Common Lisp image.
|
| - kiln https://github.com/ruricolist/kiln - an infrastructure
| (managing a hidden multicall binary) to make Lisp scripting
| efficient and ergonomic.
|
| - CIEL https://github.com/ciel-lang/CIEL/ - CIEL Is an Extended
| Lisp is a collection of dozens of libraries useful for mundane
| tasks (HTTP, JSON, regexps...). It also comes as a binary that is
| able to run scripts from sources. Scripts that use the built-in
| libraries start fast without a compilation step. [project of
| mine]
|
| - discussed here: https://news.ycombinator.com/item?id=41401415
|
| - Lish https://github.com/nibbula/lish - maybe someday a Lisp
| shell
|
| - SHCL https://github.com/bradleyjensen/shcl - a POSIX shell in
| CL (stalling)
|
| - lserver https://notabug.org/quasus/lserver/ - live-coding
| remote function calls for the shell. Write a command in the REPL,
| and run it instantly in the shell.
|
| I use CIEL ;)
|
| And, built-in: use the --load flag or build a self-contained
| binary, compiled to machine code with SBCL. It can contain your
| web assets (html, js etc). A compressed binary weights +-30MB and
| starts _fast_. A stripped off binary with LispWork$ (no compiler,
| no debugger etc) is +-5MB. There 's ECL too.
| bitwize wrote:
| And don't forget scsh: https://scsh.net/
| drob518 wrote:
| The OG.
| chubot wrote:
| Many of these projects are on:
|
| _Alternative Shells_ - https://github.com/oils-for-
| unix/oils/wiki/Alternative-Shell...
|
| _Internal DSLs for Shell_ - https://github.com/oils-for-
| unix/oils/wiki/Internal-DSLs-for... - nearly every language:
| Python, many schemes and Lisps, Haskell, OCaml, JavaScript,
| etc.
|
| Feel free to add them if they're not there
| vindarel wrote:
| nice thanks, I'll check them out.
|
| They are also on https://github.com/CodyReichert/awesome-cl/
| em-bee wrote:
| this made me wonder why guile isn't designed for shell scripting
| too. i mean, wouldn't that make sense? if you want guile to be
| the designated extension language for gnu applications, why not
| also make it the designated language for shell scripts?
| rcarmo wrote:
| Added to http://taoofmac.com/space/dev/lisp
| tanelso2 wrote:
| Very nice! A similar tool is
| [babashka](https://github.com/babashka/babashka) for Clojure
| drob518 wrote:
| Babashka rocks!
| waynesonfire wrote:
| This misses the point of shell scripts.
|
| OUTPUT=$(some_command)
|
| is the killer app of sh scripts among other things, like being
| universally available. Any language, including this, can execute
| a command. It's the ergonomics that matter. Shell scripts reduce
| the impedence of interacting with the shell to control the OS. At
| first sight, this tool does'nt improve on that impedendance. It
| also invents it's own esoteric syntax, so what's the gain?
|
| On a separate point but equally important, I don't understand why
| sh scripts are exempt fom unit tests. Do these tools alleviate
| that?
| zem wrote:
| this has a `$` - you can do (defvar output ($
| some_command))
___________________________________________________________________
(page generated 2025-10-12 23:01 UTC)