Actually, you pointed me to Fcron, to which I countered that for Fcron to be an satisfactory scheduler (that is, satisfactory to me) it would have to become Systemd. I think I was pretty clear on that, actually.<p>No, I really did mean &quot;historical sloppiness of <i>Unix</i>.&quot; It&#x27;s a fine foundation, circa 1985, but it&#x27;s time to make some progress. For example (just a minor example), the fact that Cron&#x27;s error reporting is email is ridiculous. This means that the only way to collect reports is to either use a mail client, or to set up a special rule (in Postfix or whatever) that pipes incoming mail to a special directory or a process. Both options are insane, not to mention horribly brittle. Surely Cron violates the Unix principle (the &quot;do one thing well&quot; one) here; the right thing would be to not support email at all, but to mandate that every error report is piped through a per-job command. So PIPETO rather than MAILTO. If you really want email, according to the Unix principle, you just pipe to sendmail, after all. But a whole lot of the traditional Unix toolset is weirdly crufty this way.<p>As for shell scripting, my original point was precisely that the shell language family is very hard to get right, and so it&#x27;s a poor foundation to build complicated, resilient moving parts on top of, emphasis on &quot;moving&quot;. The situation is much worse than C; the <i>class</i> of possible bugs is completely different, and much more damaging. Things like process management should not be done using shell scripting. Lots of things suffer from bad scripting; autoconf, for example.<p>By controlling SSH: Yes, I mean interacting with SSH commands. You have to cover a bunch of pitfalls: disabling tty, disabling the control master multiplexing (has never been stable), always using heredocs, etc.