I don't like bash. The only time I use it is for fixed lists of
commands with almost no logic. Here's a vague draft of what I'd do different, subject to change of course
People rm -rf stuff they would rather not, all the time. I don't
do this, because I rarely rm anything. GUI file managers are a lot less likely to
result in a screwup when tired.
Destructive commands should know whether they are being run in a script.
They should prompt you if run interactively. If run in a script, they should
have their normal behavior, but you should have the option to enable prompts.
It's common to run into issues with word splitting. Shell should support
command(foo, bar) syntax. In fact, parens should be reserved as named tuples objects.
Want to do ls? Fine, simple enough.
Want to do dd? Sorry, you gotta do dd(input=“src”, output=“dest”), because DD should *only*
accept named tuples.
Within these, unquoted strings should not be a thing. This should be a sign that you are doing
something resembling “real programming”, not “a quick hacky script” and now your code needs to act like it.
In fact, anything in them should work just like a typical scripting langauge.
(1+1, 4) should evaluate to (2, 4).
Commands should be markable as object aware, or not. Object aware commands should take frames of
messagepack on their stdio.
Byte streams are far too freeform and invite tons of incompatible unusual formats.
I am not interested in spawning 100000 processes to do something with a file. Instead, we should be able to pass objects to servers.
Want to convert one jpg?
loadfile petunias.jpg | convert webp | savefile out.webp
Want to convert 5000?
server convert webp cnv
for i in listfiles{
loadfile i | req cnv | savefile(i+“.webp”)
}
What happens? The shell passes the file object to convert. Convert
handles things in FIFO order. All servers must do so. Commands must also generate a done
frame after processing one “request”. This done frame is not displayed directly.
When that happens, the shell treats whatever came before the “done” as the response,
which is piped to savefile.
Loadfile knows to generate a done frame, like a grocery conveyor belt separator, when it
has sent all the chunks of the file. Req knows to buffer everything and wait for that done
frame before sending it all as one “request”
Want to make a new server? Just write a command that can accept multiple input frames before EOF.
To make things easier, any command that has not already sent a done frame, should auto-send one
when it exits so the programmer doesn't have to think about it.
There should be two kinds of “Get input” command, and one should wait for the done frame.
And servers should auto restart if they exit normally, so that any command can be used as one.
Just wait for a done frame, do stuff, return your data, and exit.
If your command is not object aware, it can be assumed to be a legacy byte streaming application. We can just send it any bytes frames we get, discard any others, and convert
done to EOF, since it likely can't handle multiple files.