Those operations don't look like set-operations at all, except on close inspection. Is the Unix methodology failing us here?
It's not obvious which, among all the moving parts, is responsible for any of the outcomes, just by looking at the commands themselves in isolation.
If someone did a similar thing in Brainfuck it wouldn't be entirely surprising that such a thing is possible, but the practicality of being able to getting it right every time, extemporaneously, is low.
It's interesting to know that this is possible, in case of emergency, but just because it's possible doesn't make it desirable.
If someone wrote an article about how to do the same in MS DOS batch files, circa 1996, it'd be an interesting proof of robustness, but an undesirable standard operating procedure.
for x in $(seq 100); do
{ (( x % 5 == 0 )) && (( x % 3 == 0 )) && echo "$x fizzbuzz"; } ||
{ (( x % 5 == 0 )) && echo "$x buzz"; } ||
{ (( x % 3 == 0 )) && echo "$x fizz"; } ||
echo "$x"
done
I plan to add set expressions to my new shell: http://www.oilshell.org/blog/
credit: https://github.com/Aricg/FizzBuzz---Bash/blob/master/FizzBuz...
* "seq" is usually an external process. You may want to do it in bash's arithmetic for, use a while loop with `$(( ... ))", or write a `seq` function (you still need to spawn a subshell for command expansion though.)
* "(( ... ))" is not in POSIX shell, but "$(( ... ))" is. You should be able to get around with some [ "$(( blah ))" -eq 0 ] tests.
But it doesn't really detract from the point -- if shell has arithmetic and bitwise operators built in, it's not a stretch for it to have set operations built in.
We built a SQL tool to run at the shell prompt, Crab. It's free for personal use, and designed to make this easier.