https://skarnet.org/software/execline/
execline is a (non-interactive) scripting language, like sh ; but its syntax is quite different from a traditional shell syntax. The execlineb program is meant to be used as an interpreter for a text file; the other commands are essentially useful inside an execlineb script.
is there any benchmarks/performance comparisons?
cant even understand how to iterate in a loop over the arguments with this thing…
Laugh, I only sort of half get it at this point. The docs leave something to be desired at times (feels familiar, hehe). But I get a bit of a weird sense of sort of cleverness in it. I plan to dive into it during international travel in a week when I will be on a plane for over 10 hours (ugh). So, I will write some of what I learn and a bit about using it with Kakoune (if I puzzle out how to do that exactly).
You and @Delapouite have always interesting topics like that to come with. 
I’m stick with @SolitudeSF, waiting for your feedback.
I have found execline most helpful when writing service scripts for systemd (lol) or any other supervisor that doesn’t want you to fork. It is a real boon to be able to guarantee at the end of munging that your final process is just your java / go whatever service running and that there isn’t some weird parent shell waiting to surprise you. Using it for kakoune is an interesting idea, but I am not sure how much merit it has in the sense that it acts more like kakscript than shell, no inbuilt control flow or anything like that.
@bme I am crazy but it does have control flow? https://skarnet.org/software/execline/if.html | https://skarnet.org/software/execline/forx.html
I guess it depends how you define it. In execline land, these are all separate binaries and you pay an exec every time. If you do loads of control flow then it stacks up and honestly starts to get a bit unwieldy and the shell starts to look a bit better.
The worst use case of execline is when the shell is used as a programming language, and the script loops over complex internal constructs that execline is unable to replicate without forking. In that case, execline will waste a lot of time in fork/exec system calls that the shell does not have to perform, and be noticeably slower. execline has been designed as a scripting language, not as a programming language: it is efficient at being the glue that ties together programs doing a job, not at implementing a program’s logic.
from here
Yeah, my thinking was there are certain sort of light 1-10 line shell things that possibly could be done by execline at lower cost … most of my sort of personal stuff falls in this list, where the majority of time is like spinning up sh.
But you use case is a great example of where it makes sense, so thanks for that. I didn’t realize many (any?) people were already rocking execline for like startup stuff.
That makes tons of sense. I guess I have found atm I am mostly shelling out to make decisions rather than just munge + exec (in kak). I’ll be interested to hear a field report once you’ve messed with it a bit. execline’s stance on substitution certainly might help with the pattern of generating more shell code inside a shell expansion for eval.
How did you happen to find execline?
via interest in s6 generally. He has a lot of cool ideas and libs. Initially for supervision in containers and then I was trying to make a spin of void linux that used s6 over runit (I never found the time to tie it all together sadly…)