I think you are being a little unfair in your judgement. Thinking to look in /etc/init.d, etc. relies on at least some knowledge that not every Gentoo user will have (esp. the newer variety). The same is true in the case above. Either you didn't know or didn't immediately think of the consequences of the CONFIG_PROTECT settings.
I'd tend to lend your arguments more merit if the error in question said something to the effect of:
/etc/init.d/hdparm: line 6: B: command not found
Then a quick "head /etc/init.d/hdparm" would reveal the answer in a much less obfuscated manner.
As it stands, I think you are wanting to require the user happen to know some semi-trivial Gentoo knowledge that they won't necessarily.
I'm not requiring anything; i'm *asking*.
For all I know, your example
> /etc/init.d/hdparm: line 6: B: command not found
is no more understandable to a "typical user" than the actual error was, and that's what I'm wondering about.
After all, the only difference is that your example is more *direct*, not necessarily more *clear*, as Dave indicated in his response.
If the user can read and comprehend that your example indicates that one should look in the specific file /etc/init.d/hdparm for a random "B" (which is probably a typo, but it even requires some technical knowledge or experience to recognize that, doesn't it?), then they can reasonably be presumed to be able to comprehend that in the original error they should look in the specific file /var/lib/init.d/depcache; the only difference between the real error and your example is that they will actually *find* the "B" in hdparm, but they will only find calls to files in /etc/ in depcache, where they would then have to manually search (or, preferably, grep, which is admittedly an advanced skill imo) for the file likely to contain the typo. So with the original error, the sequence of actions is unchanged (look in the file specified by the error output, for the string indicated in the error output), just longer-- if you understand the stderr output in the first place.
But would said user be able to succeed if the error message was direct, or is the message already too obtuse to be understood, direct or indirect? If so, why?
Is the issue that users need to be trained in understanding error message syntax because neither the indirect or direct messages are understandable if you don't know it, and where should such training or basic documentation be presented?
Or is the error message comprehensible, but people don't read it at all?
That's a social engineering issue-- but which one of the several that A. Khattri indicated? "Laziness" (users can't be bothered/don't have time to read)? Trained lack of confidence (long-term Windows use trains you very heavily in the belief that you are incompetent to touch system/application files, no matter whether you actually are or not)? Trained despair (if people are very used to Windows' incomprehensible error messages, they may not even look at stderr output, certain that it is similarly useless)? Or is it simply that "average computer users" (whoever they are) have no interest in self-reliance and prefer to "ask the expert", whether or not that is in fact necessary?
If one or more of these is in fact the problem, how can it be moderated, minimized or eliminated?
We can't make Linux "better" and "ready for the desktop"-- which does
*not* mean we have to do everything via a GUI, dagnabit; people can certainly use the command-line comfortably *if they know how*-- unless we identify where people are falling over it and how to remove the
obstacles to their understanding and ease-of-use. Difficulties using error output effectively looks like an obstacle to ease-of-use to me.
Heaven knows I won't know what to do about it if I do find an "answer" (or the beginnings of one), unless that answer is "add to the docs", but we all contribute what we can, and asking the question in the first place is what I can :-) .
Holly -- [email protected] mailing list
