| > The problem with outdated shells looks pretty clear: they were made with one kind of tasks in mind but are used for other, bigger and more complex tasks. Such scripts usually look as a fight against the language and working around it much more than using it to solve the problem. Mind you, > Create a shell (in that language) that is up to date with today's tasks - cloud, remote execution on a group of hosts. I'd rather create another DSL/tool to solve it. > Two languages actually. > Current-shells-like but simplified (called "commands"), $(...) syntax > Scripting language, "normal" programming language (called "code"), {...} syntax Good luck. > The scripts that I've seen (and written in Python and Ruby) look too verbose and show unnecessary effort. Such scripts do not look an optimal solution (at the very least). Did you check scsh? (I don't use it.)
http://scsh.net/docu/html/man-Z-H-3.html |
In fact, you could run a program on a local machine referencing a file on a second machine, pipe the output to a program on a third machine and have that redirect the output to a file on a fourth machine, all from the command line. I don't recall the exact syntax, but it was something like:
(Individual hosts were numbered on a QNX ethernet based network, but the default permmissions were Unix like). All of this was a consequence of the message-based QNX operating system (whether messages were delivered locally or remotely was invisible to programs) but I don't see why something like can't be done today.