Are there any man pages for any of the system error messages?
in [General Linux]
|
Prev: Live CD to scan windows pc for a virus
Next: where is CentOS storing my hostname that it resets it on each reboot?
From: despen on 5 Apr 2010 21:46 markhobley(a)hotpop.donottypethisbit.com (Mark Hobley) writes: > In comp.os.linux.misc despen(a)verizon.net wrote: >> markhobley(a)hotpop.donottypethisbit.com (Mark Hobley) writes: >> >>> Does anyone know of any repositories containing man pages for system error >>> messages? I am looking for pages that document error messages and resolution. >> >> Man pages aren't organized that way, nor should they be. > > Why don't you think that man pages should be organized this way? Because they are organized a completely different way. >> Look instead at the documentation for the APIs. > > So are you saying that whenever a user gets an error message on the screen, > she should start looking at the various APIs? Yes and no. libc doesn't produce errors on the screen, at least not in 99% of the cases I can think of. It produces return codes and errnos. Those are for an application developer to look up and deal with, not a user. >> Each of the APIs in libc has a man page. > > I will look at these of course. > >> Again, wrong way to go about it. > > Ok. How do you think this should be done? > >> How about working with an existing documentation project: >> http://tldp.org/authors/ > > I specifically need documentation for error messages. Whenever an error > message occurs on the screen, I need to be able to pull up the documentation > for it (I don't really want to start looking through API documentation here.) You're not from a mainframe background are you? IBM mainframes have manuals that are organized by message number. Unix systems, thankfully, don't take that approach. > I am always looking to work with other authors who have similar mission > objectives in mind, of course. Who do you suggest? I don't think anyone is on your particular mission, but there are documentation projects, you could see what they think. Take a look at your average UNIX message: home> ls -l nonsuchfile /bin/ls: cannot access nonsuchfile: No such file or directory Do you really think a message number would help? If I thought this was a good idea, I'd add a type to the man page coding standard. Now we have SYNOPSIS, DESCRIPTION, AUTHOR, etc. I'd add a section "MESSAGES". Then each man page that had error messages could list them and some tool would allow access by message text or maybe even number. That would keep each commands documenation in one place. But I'm not crazy about the idea. I don't have a problem with messages the way they are.
From: John Hasler on 5 Apr 2010 22:06 despen writes: > You're not from a mainframe background are you? IBM mainframes have > manuals that are organized by message number. Because in the old days anything more would have taken up far too much storage. You got a number and were expected to look it up (or have long since committed it to memory). Thankfully, those days are long gone. We can now afford to store the entire message on disk. > home> ls -l nonsuchfile > /bin/ls: cannot access nonsuchfile: No such file or directory > Do you really think a message number would help? > If I thought this was a good idea, I'd add a type to the man page > coding standard. Now we have SYNOPSIS, DESCRIPTION, AUTHOR, etc. I'd > add a section "MESSAGES". Then each man page that had error messages > could list them and some tool would allow access by message text or > maybe even number. The right-hand portion of the message you quote came from perror(), not from ls. -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: despen on 5 Apr 2010 22:45 John Hasler <jhasler(a)newsguy.com> writes: > despen writes: >> You're not from a mainframe background are you? IBM mainframes have >> manuals that are organized by message number. > > Because in the old days anything more would have taken up far too much > storage. You got a number and were expected to look it up (or have long > since committed it to memory). Thankfully, those days are long gone. > We can now afford to store the entire message on disk. There was no time I can remember when mainframes didn't print text along with the number. But the messages were short and there were no man pages, >> home> ls -l nonsuchfile >> /bin/ls: cannot access nonsuchfile: No such file or directory > >> Do you really think a message number would help? > >> If I thought this was a good idea, I'd add a type to the man page >> coding standard. Now we have SYNOPSIS, DESCRIPTION, AUTHOR, etc. I'd >> add a section "MESSAGES". Then each man page that had error messages >> could list them and some tool would allow access by message text or >> maybe even number. > > The right-hand portion of the message you quote came from perror(), not > from ls. Yep and it's documented in "man errno". But ls choose to print that message embedded inside it's own message. It didn't have to.
From: Mark Hobley on 6 Apr 2010 17:30 In comp.os.linux.misc despen(a)verizon.net wrote: > home> ls -l nonsuchfile > /bin/ls: cannot access nonsuchfile: No such file or directory > > Do you really think a message number would help? It might help a user who has that error pop up on the screen during operation, because they can reference the message number against the documentation. If on the other hand, they google for the message as output above, the only documentation that they get, is a single hit to your post. Lets, look at another example. A user opens up their internet browser, starts browsing the web, and the following error message appears: (gecko:nnnn): Pango-WARNING **: Error loading GPOS table 5503 Who the hell knows what means? An end user may have a real hard time trying to resolve that error, if they cannot relate the message to appropriate reference documentation. Numbering the messages so that this can be related to reference documentation is just a good idea IMHO. Mark. -- Mark Hobley Linux User: #370818 http://markhobley.yi.org/
From: unruh on 6 Apr 2010 18:31
On 2010-04-06, Mark Hobley <markhobley(a)hotpop.donottypethisbit.com> wrote: > In comp.os.linux.misc despen(a)verizon.net wrote: >> home> ls -l nonsuchfile >> /bin/ls: cannot access nonsuchfile: No such file or directory >> >> Do you really think a message number would help? > > It might help a user who has that error pop up on the screen during operation, > because they can reference the message number against the documentation. > > If on the other hand, they google for the message as output above, the only > documentation that they get, is a single hit to your post. > > Lets, look at another example. A user opens up their internet browser, starts > browsing the web, and the following error message appears: > > (gecko:nnnn): Pango-WARNING **: Error loading GPOS table 5503 > > Who the hell knows what means? An end user may have a real hard time trying > to resolve that error, if they cannot relate the message to appropriate > reference documentation. Numbering the messages so that this can be related > to reference documentation is just a good idea IMHO. AGain, that error message is two parts-- one part comes from ls, and one part comes from perror, the error messages from the kernel /libc routines. There is simply too many of them and as you can see combinations of them. Ie, the project exponentially explodes. How in the world is this "numbering" supposed to work? Are you going to force all writers of programs to apply to you for a number for each of their error messages? Simply no way Jose. Or are you going to assign a number after the fact, running through each new program ( or revision of an old one) and assign numbers-- what purpose would those numbers then serve, since noone but you would know what that number was. I agree that the above error message from Pango is useless for any user. I have no idea what a GPOS table is, and that number 5503 I am sure changes each time. It is an idication of incompetent programmers. But if you think you will get rid of incompetence, you are again dreaming. > > Mark. > |