Fleck: A Lisp that runs wherever Bash is(github.com)
github.com
Fleck: A Lisp that runs wherever Bash is
https://github.com/chr15m/flk/
21 comments
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)?
Speculating here... but in my reading:
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.
Sort of like shell-vm on top of base shells :-)
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.
Sort of like shell-vm on top of base shells :-)
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.
offtopic
>hopefully at some point for DragonFlyBSD
What advantage of DragonFlyBSD you see today over other OSs?
>hopefully at some point for DragonFlyBSD
What advantage of DragonFlyBSD you see today over other OSs?
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.
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.
Thanks - it was hard to understand the need for Fleck on the fleck website. But your post succinctly explains it.
> 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.
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.
I'm pretty sure Ansible doesn't _require_ python on the target machine as I've run Ansible before with servers that didn't have python on them.
Ah, yes, the ‘raw’ and ‘script’ modules can work without Python, so I guess this makes 75dvtwin's workflow possible.
(https://docs.ansible.com/ansible/latest/installation_guide/i...)
(https://docs.ansible.com/ansible/latest/installation_guide/i...)
I found that “rant” a bit scary.
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.
It was moderately funny until the murder fantasies started.
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.
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.
This could be accomplished with a fairly simple macro. Patches welcome!
> 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.
https://support.apple.com/en-us/HT208050
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.
https://support.apple.com/en-us/HT208050
What is your intent? The program need to go zsh?
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.
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.