Dune: A Shell by the Beach
github.com
github.com
No, programmers have tried and died.
[wheels, plans].forEach(x => x.push(x))Powered by CheerpX: A WebAssembly virtual machine for X86 executables.
Please note that is a sneak preview of our tech, we plan to release it soon to the public. Stay tuned.
It lets you run bioinformatics tutorials in a shell on your own machine via JavaScript (xterm.js)/WebAssembly
If it gets a significant userbase, it's much less clearly "alternative" anymore.
However, fish is not radically different from bash/ POSIX shell the way, lets say babashka [0] is.
I write lots of small scripts and utilities for myself, perhaps on average one per week. Random stuff, like: slicing json data, renecoding home videos with ffmpeg, querying APIs with requests module, loops, dictionary comprehensions, etc...
If some script needs to be deployed to production, it's fairly easy to rewrite it in plain Python.
I've resisted installing it on our production systems, but I'm thinking more and more of using XXH for this instead.
(
trap 'kill 0' SIGINT
worker A &
worker B &
wait
)
One would think such a useful workflow ought to have a better built-in support but apparently not: people reinvent it all the time with $! and manual PID files and those things are very unreliable.
As for PIDs files, I have no love for them either. But in fairness, their role isn’t to manage a persistent shell but rather to manage a persistent service being queried from a non-persistent shell session. In a way, they’re like a RESTful API before REST was a thing. So they are not designed to fit the role you’re describing of a persistent shell session managing two long running but not persistent processes.
Upload two large files to two different machines in parallel, starting at roughly the same time to compare the throughput. Or "run in parallel and measure the difference" scenario. Or parallelizing any, esp. network/distributed, work a-la make/xargs. Heck, init used to do exactly this: run a getty for each tty in parallel, indefinitely restarting them.
Sure, you can do that from two/three/four/... different xterms, as well as stopping them manually and that's what I usually do but... that's tedious and trivial stuff, perfect for automating if you can automate it, that is.
As for services/demons I agree completely; in fact my other gripe about the UNIX process management is how easy it is to break out of a process group. Thankfully, docker gives you confidence that when you stop your service, no runaway (great-great-...-grand-)child process will survive. In olden days, however, lots of things insisted on daemonizing themselves and fighting against any ways to control or even observe them: breaking from the process groups, de-attaching from the terminal sessions, double- and triple-forking, closing all file descriptors to defeat the self-pipe trick, etc. Ugh. If you really need some child process to outlive you (do you really? please consider again), then the only way to do that ought to be "service start" or "at now" or some other kind of "ask someone above you in the process hierarchy to launch that process".
I wrote my own. Originally motivated by the fact that bash doesn't handle `$VARWITHSPACES` correctly (if I want expansion, I can write `$@VARWITHSPACES`), but I get a surprising amount of mileage out of random features shoved into corners of the substitution syntax like:
$ factor $@m/[0-9]+/$[(1<<15)-((2*$0)-1)]/q'1 2 3'
32767: 7 31 151
32765: 5 6553
32763: 3 67 163
Math. It evaluates math expressions. (I already had the logic handy since `${...}ARRAY` needs it to pick out a element of `$@ARRAY`.)
Why do I use it? Because Bash (et al) syntax sucked for solving common modern day problems (like iterating through anything that isn't just a list of words, like the way variables are expanded in a dumb way (resulting in problems like spaces in file names breaking scripts), like how working with tables, json or other structured data requires inlining another language (aws, sed, jq, Perl, etc). and so on and so forth)
So I created my own shell to fix these problems
And while I was at it, I took influences from IDE to build out a better interactive terminal too.
(I should probably write a blog post about some of the design decisions behind my shell)
Other than that, this is a really interesting and creative project. I'm curious what it will be like to use it in a "real" session, I might have to download it and try it.
Though, I just use screen now.
I could quite possibly replace tmux with dvtm but I'd been doing screen then screen+dtach then tmux+dtach before that so tmux+abduco was an incremental improvement that kept most of my workflow intact.
edit: fixed typo