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.
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
They are also on https://github.com/CodyReichert/awesome-cl/
- 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).
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)
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.
https://github.com/cosmos72/schemesh
https://news.ycombinator.com/item?id=43061183 (7 months ago, 177 upvotes)
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.
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.
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?
Likely because:
- it's an older culture than unit testing
- people write shell scripts for one shot tasks, or to automate tasks which are system setup/configuration specific
- if a shell script becomes useful enough, it gets rewritten in a more apt language
(defvar output ($ some_command))