Cool! Aside from satisfying the preference for a non-Schemey syntax, what is the advantage of Fleck over the Scheme shell (who's manual page contains this classic gem of a rant: https://scsh.net/docu/html/man.html) or the newer Racket Shell (unfortunately named Rash)?
Fleck does not require a compiled executable to be installed.
As long as you have bash Fleck will work.
For scsh you have to have to install platform specific executable. If it is available in a particular distro, perhaps it is not that bad.
I write, these days, a lot of Ansible installation tools
For Multiple versions of (and almost bare) linux, freebsd, openbsd (and hopefully at some point for DragonFlyBSD).
Today, I have to write shell-specific scripts to do application-centric process management, application-centric backup preparation steps, health monitors, smoke tests and so on.
To minimize my work, I instruct Ansible to preinstall bash everywhere... and then I run the bash scripts.
But writing bash scripts is, well,... unsettling (hard to get used to primitive return values, lack of normal enumerated parameter passing and so on)
With Fleck (at least this is my reading), I will be able to install Fleck via Ansible and then write all the scripts in Scheme (which I much prefer compared to bash, zsh or anything else).
I guess, if, in the future, Fleck will help me to avoid worrying about Powershell, kornshell and so on -- I would be delighted.
> I instruct Ansible to preinstall bash everywhere... and then I run the bash scripts
Wait a minute. I may be mistaken, but I thought Ansible needed Python on the managed machines, to run some of the modules. Afaik it uploads some Python code via ssh before doing the work proper.
Portability of Scheme code between implementations is still difficult (I'm working on it), but the portability of Scheme implementations is usually good, and the Scheme48 interpreter on which scsh runs will go anywhere Posixy without problems. There's a Windows port, but of course scsh won't work on top of it.
We are at very early stages, figuring out if we can use Hammer2 file system as content addressable storage system.
Our needs are such, that writes are relatively rare, and go into one cluster, while reads of our blobs, need to go to geographically distributed nodes, whose disk topology is different (less capable) than that of a muster, plus they have somewhat-unreliable connectivity to the master.
So Hammer's network-problems-tolerant streaming replication and offline de-duplication is attractive, at least conceptually.
I don't know Olin Shivers but I've read enough of his writing to know that this acknowledgements section was written with tongue in cheek, and in fact it's a funny enough piece of writing that I've shared it a number of times like the grandparent comment did.
Afaik Mal makes interpreters, not transpiled Lisps like Clojure.
Notably, depending on the platform, transpiling on-the-fly may be feasible for scripting. Fennel, on Lua, does its thing pretty damn fast even on my horribly underpowered machine.
It explicitly says that it does not support clojure code, yet all examples use the clojure file name extension. Weird. But still very cool nonetheless.
i was hoping for a lisp-like syntax for bash commands, but this seems to do something else.
to run a bash command i need to do:
(sh* "echo >&2 hello")
what i expected is: (echo >&2 hello)
or possibly (sh* echo >&2 hello)
if i have to quote the whole bash command, then this becomes impractical because it adds an additional quoting layer, and doesn't make bash quoting any easier.
> Now you can use a humble LISP to do Bash things. Bash as a scripting language has many edges, but it is everywhere...
Just in time ...
> Starting with macOS Catalina, your Mac uses zsh as the default login shell and interactive shell. You can make zsh the default in earlier versions of macOS as well.
Well, the big problem with bash on macOS is it is stuck on bash 3.x. FSF changed license of bash, starting with 4.0, from GPLv2 to GPLv3, and Apple's corporate policy says no GPLv3 allowed, so macOS stuck on bash 3.x. You write a script on Linux using bash 4.x features, take it to run on macOS with bash 3.x and it doesn't work. (You can still install bash 4.x on macOS, but if you have to install bash 4.x that gets rid of the argument "bash is everywhere and we don't have to install it so that's why we use it instead of something else".)
Apple is trying to move macOS users to zsh because they like the license (it is MIT-like) and hence will be keeping up to date with new versions of it, instead of being stuck in the past like they are with bash.
