Non-interactive vs. interactive

[prev] [thread] [next] [lurker] [Date index for 2005/11/16]

From: Luke Kanies
Subject: Non-interactive vs. interactive
Date: 20:08 on 16 Nov 2005
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.

-- 
Sometimes I think we're alone. Sometimes I think we're not. In
either case, the thought is staggering.   --R. Buckminster Fuller
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

Generated at 13:00 on 18 Nov 2005 by mariachi 0.52