@mwichary Here's what it looks like with the shell of a hobby OS I'm sometimes working on. ("ffmpeg" is red because I don't have it on my path.) Quoted strings get highlighted, but backslash-escaped strings aren't for some reason. But it's probably somewhat close to what you imagine. Likely achievable in more mainstream shells too :)
I liked https://www.linusakesson.net/programming/tty/index.php for a writeup of what the Terminal does, and what the shell does.
There's a big selection of alternative shells (nushell and whatnot), in case that's a rabbit whole you'd like to pursue for a bit :)
@saagar It feels off, doesn't it!
Maybe it's that there are many artisanal hand-made bugs, but the ones that are hit often are noticed and fixed, and the low-frequency ones happen less frequently than ones caused by hardware errors?
But I also wouldn't be surprised if that analysis has some flaw.
You're doubting my humanity, but you're missing some key points. Here are some of the things I've seen:
The bottom line: All those moments will be lost — like tears in rain.
Deterministic builds can lower continuous integration costs and give you more confidence in your build and test process. This post outlines what it means for a build to be deterministic, the advantages of deterministic builds, and how to achieve them using LLVM tools.
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@evmar All build system that small projects need is `echo $FILES | xargs -n 1 -P $N $CLANG -c @cflags.rsp && $CLANG *.o` 😅 [1] Small projects have fewer TUs than you have cores, and you'll only build if something has changed, so no need for fancy scheduling or change tracking. Your build takes the time of the slowest-to-compile TU always, instead of sometimes being faster (when the slowest TU doesn't need rebuilding), but having an incentive to make very-slow-to-compile files compile faster is a good incentive.
(This is of course all firmly tongue-in-cheek, and with C-style compilation model colored glasses.)
I find the general topic of "small-scale parallelism" super interesting. I have a half-finished draft on this sitting on my disk that was kind of inspired by https://github.com/SerenityOS/serenity/commit/7cd3e6e928ac58 – actually, here it is: https://gist.github.com/nico/71498bfe2909b245b17af3eeb8a65079
At least with my requirements (macOS), I feel shells kind of let us down here. "Do something to N files in parallel; handle output, failure, progress, etc in a good enough way" should be easy enough to do that it's type-in-able in an interactive session. Sadly, that's not the case.
The unfinished bits of the draft are supposed to describe what I do in that commit mentioned above (it relies on echo being atomic in practice; normally you'd have the worker write to a pipe and do all stdout on the main process), then what it looks like in GNU parallel (nice enough, but not pre-installed on mac, and I don't remember the output situation), and what it looks like if you a) write a python script to do the build or b) make the script outside ninja manifest fragments and shell out to ninja.
Zig also does the "just write a normal program that does the build" thing that you're doing. IMHO this being such an attractive option is a sign that something went wrong somewhere 😅
1: E.g .in the attachment here https://issues.chromium.org/issues/40268826#comment11
Lynnesbian 
Michael Stapelberg 🐧🐹😺