SJS wrote:
begin quoting Lan Barnes as of Fri, Mar 28, 2008 at 10:19:07AM -0700:
On Fri, March 28, 2008 9:56 am, David Brown wrote:
On Fri, Mar 28, 2008 at 09:49:42AM -0700, Lan Barnes wrote:
But to remind everyone, cdparanoia was the original subject in this
thread, and cdparanoia is CLI ... a CLI program that defaults to putting
out smiley faces to stderr on success.
As do an increasing number of CLI programs. The studies and human factors
that cause people to need progress have nothing to do with CLI vs GUI,
it's because the users are human.
I have to admire you. I personally would not have the temerity to argue
that my personal preferences are superior to the thought-through defaults
of the founders of Unix.
I've told Ken Arnold that his pet project was wrongheaded, mostly on
the basis of my personal preferences. And I consider him to be a huge
brain, worthy of respect. So what? That just means I'll disrespect him
*politely*.
Appeals to authority, especially absent authority, just don't sit well.
If they're an authority, they can argue with me, and if there's a good
reason they're an authority, they'll probably convince me.
You're in the minority, even among CLI users, for wanting slience.
Absolutely. If I wanted to be in the majority, I'd use Windoze.
This is where appeals to the majority or to popularity break down. We've
already rejected that argument, yes?
But, cdparanoia does exactly what we're saying it should, it has a --quiet
option for scripting, but prints out progress in the default case.
Default behavior is exactly what we're talking about.
Y'know, I'm thinking about what I do, and my programs and scripts are
all over the place on this one. It really depends on the envisioned
use.
But I don't think I've ever reserved stderr for just errors. If the
program dumps its output to stdout, then EVERYTHING else goes to stderr:
errors, warnings, status, progress updates... everything. As it should
be, really.
And do I worry about a program being "too chatty"? Not really.
Generally, it starts quiet, and as I get bothered, or feel the need
for a warm fuzzy, I start adding status messages, "you got here"
notices, progress-dots, etc.
Let the needs of the user drive the behavior.
Now, checking to see if a file descriptor is a terminal...that's just
evil and wrong.
I don't know what programming or scripting language we're talking about
here. Let's just say that I am almost completely unfamiliar with what
scripting or programming language is needed for stdin, stdout, and
stderr. I think someone said stdin is 0, stdout is 1, stderr is 2, and
more numbers are available, but with no standard names. Stewart
suggested possibly petitioning POSIX for a label of stdstatus, let's
assume they agree and make that 3.
Could someone please show me, as simply as possible, an example script
or program that uses each of these? I don't know enough about it to
envision it.
And just for grins, let's say the author wants more output channels for
whatever reason. Would he likely choose higher numbers than the next
available numbers (just in case POSIX later decides to add more
stdxxx)? Or would he likely use the next numbers available since stdin,
stdout, and stderr have been the only ones for many many many years?
Let's say that a user invokes that program. What will he see?
Let's say that a user invokes that program with simple redirection to a
file. What will he see?
I've had limited experience with this when I did "du -a > ~/du-a" and
got what I assume is stdout in the file but what I assume is stderr
still on the screen. It seems like, without redirection, both stdout
and stderr outputs went to screen, but redirection split them. Is this
observation correct?
I've seen fancy ~"> 2&"~ or whatnot (couldn't quote it accurately from
memory since I never really understood it). Is there some resource that
could explain such things, preferably simple explanations designed for
total NOOBS?
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
