*sigh* I guess I just have to get over the fact that such a simple oversight has marked me a typical windows user, but seeing as how no one wants to leave my name out of this, I might as well try to respond constructively.
As has been said, some people, like myself, are just a little newer to gentoo
than others or by sheer dumb luck didn't make all the same mistakes as everyone
else.
For the record the error was in /etc/conf.d/hdparm (not where a place anyone
suggested). Now I dare ask... is there any reason that commands are being
executed in in a configuration directory? Yes, yes, I suppose there could be
uses for every line in the config files to be treated like regular bash code,
but logically command not found error should not occur in a configuration file
unless that config file is not really a config file. I did run several grep's
on several files, but finding the offending "B" in like looking for a needle in
a haystack, especially since I didn't know which haystack to search.
How do we make it better? We could point out the exact offending file. Or say
that an error was found while parsing config files or init scripts. There are
plenty of things that could be done, but I'm not sure it's worth the effort in
this case as it was just a simple typo that spawned this whole discussion.
Dave
On (2005-03-30 14:49), Holly Bostick wrote:
> Nicolas Bailey wrote:
> >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
> --
> gentoo-user@gentoo.org mailing list
>
--
Finster's Law:
A closed mouth gathers no feet.
pgpDMw0iS5XFg.pgp
Description: PGP signature
