4 ms·

> (the documentation is very poor: "dialog dyn-amically with a running fcron daemon" didn't really invite me to think that it had a job scheduling UI) I... uh.

> (the documentation is very poor: "dialog dyn-amically with a running fcron daemon" didn't really invite me to think that it had a job scheduling UI) I... uh.... read the documentation -rather than the second headings- and immediately understood that it had a job scheduling UI. :) I understand that we're all busy, but it does pay to take fifteen minutes or an hour every couple of weeks to sharpen the axe. > it's not sufficiently built out that I will be able to trade my current toolset for it. I never was claiming that you should. I was addressing your initial claim, mentioned a little bit later in this comment. > For example, it seems that it lacks any process isolation. Linux does that. > Email-only reporting is not acceptable. Consuming email is trivial. There are something like 349024823904 libraries and like a handful of good ones to do so in every popular language. :) > I agree that Fcron is a better Cron. But I also think that it's a very poor Systemd. Your initial assertion was that the only way to get a good cron was to implement systemd. I demonstrate that that's not true, and you counter with "Well, that cron's not systemd!"! sigh. > I'd much rather have a C program segfault on bad input right away... You and I both know that it's trivial to write a C program that does exactly the same thing that your hypothetical poorly-written bash program does. :) Bash didn't invent Heisenbugs. > It's one of the languages you mentioned. Ruby, Python, Erlang, Go, Nim, etc. all improve on the historical sloppiness of Unix. /s/Unix/Bash or sh/ and I agree with your statement. I also note that Perl (shudder) is conspicuously absent from your list. :) > There's much more to it than that, I believe. For example, preserving quoted arguments is a nightmare. Thanks for the examples! I'll go over them over the next couple of days and see what I can learn from them. :D > But I would bet that most developers don't even know that bash has first-class array support. (If you know a better solution, Did you accidentally a sentence or two? Also, the recurring theme that I've been spotting here has been "Programmers who don't know their language often write bad or broken programs in that language.". Is this not one of the larger themes of your statements? :) > Controlling SSH from scripts has always been painful and brittle for me. Sorry, this is something that I've not yet had call to do. What exactly do you mean by "controlling SSH from shell scripts"? Something like ssh user@host "someRemoteCommand $AND_A_SCRIPT_VAR_TOO" embedded in your script? (Or the equivalent here-document?) > As for "entire OS built on shell scripts", every Unix distro out there is built on tons of shell scripts. That hardly means that the entire OS is built on shell scripts. I argue that the vast majority of the shell scripts out there are to handle process startup. While this is quite important, it's important to remember that the stuff that actually gets work done in the OS is very rarely written in Bash. > Erlang's duck typing means it's susceptible to sloppy inputs just like any other duck-typed language. I see what you're saying (and agree with your final sentence), but one could just as justifiably say "C and C++'s ability to permit the programmer to override the specified type of a given variable means that such programs are susceptible to errors of sloppy logic. We should really be using Haskell to write our system management programming." ;) Anyway. Thanks for the ongoing conversation. This has been quite informative.

lobster_johnson 11y ago
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. No, I really did mean "historical sloppiness of Unix." It's a fine foundation, circa 1985, but it's time to make some progress. For example (just a minor example), the fact that Cron'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 "do one thing well" 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. As for shell scripting, my original point was precisely that the shell language family is very hard to get right, and so it's a poor foundation to build complicated, resilient moving parts on top of, emphasis on "moving". The situation is much worse than C; the class 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. 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.

lobster_johnson 11y ago

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. No, I really did mean "historical sloppiness of Unix." It's a fine foundation, circa 1985, but it's time to make some progress. For example (just a minor example), the fact that Cron'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 "do one thing well" 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. As for shell scripting, my original point was precisely that the shell language family is very hard to get right, and so it's a poor foundation to build complicated, resilient moving parts on top of, emphasis on "moving". The situation is much worse than C; the class 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. 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.