From: Luke Kanies Date: 20:08 on 16 Nov 2005 Subject: Non-interactive vs. interactive I don't know whether to blame Ruby, Unix, or everyone who could have fixed this but didn't, but... There seems to be this stupid assumption in Unix that all external commands are used in an interactive way. "No," you say, "that's what system() and `` are for." No, if that's what those commands were for, then those commands would make it easy to capture stderr. You see, when I have to non-interactively use external commands, I literally never want stderr to go to the console, and I pretty much always want to capture it so I can log it, and the whole Unix system seems predicated on me not being able to do so. Yes yes, I know, I can tack '2>&1' onto my command, and that will send stdout and stderr to the same place. Sure, except now I can't log the error messages at a different level, and nearly everything behaves quite differently when any shell metacharacters are present. In this case, I'm encountering either a stupid Ruby bug or a stupid Ruby design decision -- Ruby uses EUID to evaluate commands directly but UID to evaluate them in a subshell -- but it's Unix's fault for stupidly assuming that there will always be a human at the helm watching the console. It might not have been a stupid assumption in 1982 or whatever, but it sure is now. So, just wanting stderr causes literally every single program to behave differently, using subshells instead of executing directly. "Oh," you say, "but you can just redirect them manually." Yeah, I sure can manually create new files for stderr, and then read those back in after every command, because everyone knows that temporary files are hallmarks of both high performance and good programming. If I do that, my code to handle capturing stderr will be longer than my code to do what I'm actually doing, which is just stupid. And I can't really afford to use temporary files in this case (not for performance reasons but because I don't want to have to deal with deciding where to put them and how to clean them up). The real answer is, there are plenty of ways around this insane design decision, and Ruby seems to have a nasty bug here, but it is still a stupid design decision and it needs to be rethought. Oh, what's that, you're complaining because you'll have to change system calls that haven't changed since K&R? Suck it. There is never a good time for crappy designs outliving their welcome. Oh, and yeah, I know Ruby has a 'popen3', but for some retarded reason that command throws away the exit code which (guess what?) I also need. Stupid stupid stupid.
Generated at 10:26 on 16 Apr 2008 by mariachi