Wow, that was a long read. Let me first say that I'm a little bit insulted at having my post compared to a typical Windows user :P.
With that out of the way, it really wasn't a very clear message. I knew that the two lines /var/lib/init.d/depcache: line 6: B: command not found /sbin/rc: line 6: B: command not found must be referring to some other commonly referenced file, but had no idea where to start looking. If the scripts had pointed out the actual file where the error had occurred, then it would have been a simple resolution. Everything is a learning experience I suppose. I'm sure next time I have a similar "command not found" error, I'll know where to look, but I don't see how "command not found" would intuitively lead me to the /etc/conf.d and /etc/init.d directories. Of course the meaning of "command not found" is clear, but the location of the command in question was the problem. Dave On (2005-03-29 12:36), Holly Bostick wrote: > Dave V wrote: > > You got me looking in the right places at least. Turned out that the > offending file was in /etc/conf.d. I somehow managed to insert a random > B character on line 6 of /etc/conf.d/hdparm. Thanks for the help all. > > > > On (2005-03-28 12:54), A. Khattri wrote: > >>On Mon, 28 Mar 2005, Dave V wrote: > >> > >>>Every time I emerge I get this message: > >>> > >>> * Caching service dependencies... > >>>/var/lib/init.d/depcache: line 6: B: command not found > >>> > >>>I also get this when booting in the middle of the normal service > startup messages: > >>> > >>>/sbin/rc: line 6: B: command not found > >>> > >>>This problem has been hanging around for a while and so far hasn't > caused any noticable trouble, but the locations are a bit worrisome. Any > idea how I can fix this or what might be causing it? > >>What does "grep B /etc/init.d/*" say? > >> > >> > > OK, now that the problem has been solved, I'd like to ask a question > about why this was a problem in the first place. Not getting on you, > Dave, I'm just curious about a "user psychology issue". > > The error message is quite clear-- it gives a location and a standard > (meaning, well-understood) error: "command not found". > > So, from the error, we already know that there is a "B" command being > called, which does not exist (as we also know just from common sense; I > certainly don't know every binary name available to Linux, but "B" just > doesn't seem likely to be one of them). We also know (hopefully), even > from limited experience, that a "Command not found" error is often > caused by a typo; the alternative being the program not being installed > in the first place if spelled correctly, but in this case, where the > command not found is something like "B", which one can easily guess is > not a real command, we can pretty much say "typo". > > So we know we've got a typo somewhere, and the error message tells us > the beginning of the trail to locate it, /var/lib/init.d/depcache. > > depcache is openable via less (and possibly other text editors), so that > would be the first thing to check for this typo. Of course, I don't have > this error, but looking at depcache, it's pretty easy to see that the > "B" is likely not there-- and I wouldn't have expected it in depcache > anyway, since I have a general idea that depcache (given that it has the > word "cache" in its name) is something that calls other scripts. > Besides, I have never edited depcache (so I could not have inserted a > random "B" into it). "Even I" know this, because 1) files in /var/ are > not something normally edited or even looked at by a user, and 2) I > would have noticed something like depcache showing up in etc-update for > that reason (it would be so unusual), although I would not have edited > it had it come up, but accepted changes. Which means that 3) if the typo > really was in depcache, it was a developer typo which is not so likely > for a random "B", and even if it was a developer typo, 4) it's a bug > that's going to be fixed by the developers, probably quite soon. So the > typo being in depcache itself is still possible, but the greatest > possiblility is that I the user made the typo, which means it's not in > depcache itself (though, since I'm opening depcache anyway, I'll scan > for it). What looking at depcaches does tell me is what scripts/files > are likely candidates for the typo, because they're being called by it. > > What I see in depcache is a bunch of calls to services located in > /etc/init.d and then calls to configs in /etc/conf.d. (to the config for > the listed service for that section, net, and then /etc/rc). > > Hopefully, I have some sense which one of these I may have recently > edited, but even if not, I can look in the file list of these two > folders (and /etc/rc) and attempt to track down recently edited files, > or grep the /etc/ folder for "B\ " (I can use escape characters in grep, > can't I?) > > In any case, Dave still had to search for the typo one way or another > even with the advice; this was unavoidable. But the error message > already contained the information on where to start the search (and in > fact what was wrong, by indicating that there was a typo somewhere). So > what I am wondering (again, nothing about you personally, Dave, you > simply seem to have a fairly typical user issue), is why users have > difficulty understanding these messages, and using them effectively. > > Are they perhaps so used to Windows that they don't expect error > messages to be of any use, thus don't look at them? Does the fact that > the error message is displayed in some semi-obtuse "term-speak" alarm > people so much that they're convinced that they don't understand it > before they even try? Or am I just weird that I can look at a message > like that, know that I don't "understand" it (I know nothing whatsoever > about depcache, neither what it says in the script, nor what it is > "for", never mind how it does whatever it does), yet still see that > there are two pieces of useful information in the message, and follow on > from those clues, in faith (for lack of a better word) that it will all > eventually resolve to something I *can* understand (which is why I love > Gentoo-- 98% of the time, this is what ultimately happens, unlike, say, > SuSE, where such a trail likely becomes increasingly obfuscated until I > can't follow it any more). Or could that be the issue-- new users > beginning with such distros as SuSE and RH (Mandrake excepted; they > really seem to actively try not to obfuscate as much as SuSE or RH, > which is why I like Mandrake), where you're actively discouraged from > trailing through your system, so that by the time they reach something > like Slack or Gentoo, they believe that resolving an error themselves > based on the information in the error message is impossible for a > "normal person" untrained in "programming" (which many people seem to > believe is the same as "any text in a terminal") or the intricacies of > "system administration" (which many people seem to believe is something > only done by enterprise server admins with degrees in IT)? > > I feel that there's some fundamental issue at work when I see so many > posts (not only here, on all kinds of Linux lists/forums), where the > answer, or a major clue to the answer, is in the original error message, > yet users are completely overlooking those messages. I can't really > believe that the errors are obtuse (or at least I can't imagine how they > could be made clearer), so is this an educational issue? And is there > any way to help users see that they more than likely already have the > capacity to solve their own problems, whatever their level of "technical > knowledge", often much faster than waiting for someone to reply on a > forum or (other, slower) list? > > Holly > -- > gentoo-user@gentoo.org mailing list > -- The last person that quit or was fired will be held responsible for everything that goes wrong -- until the next person quits or is fired.
pgpKZZ4FjAtxR.pgp
Description: PGP signature
