Getting the message from the kernel
Getting the message from the kernel
Posted Jun 22, 2007 18:17 UTC (Fri) by giraffedata (guest, #1954)In reply to: Getting the message from the kernel by adi
Parent article: Getting the message from the kernel
Except rare cases the message itself can't give you all this information and we certainly don't want novels to be issued as messages curing this inherent deficiency.
The right length of a message is somewhere between the traditional length and a novel. And it's the same length as developers would write in the "documentation" comment or database or whatever under the message ID proposals. The message manual will not have a novel -- it will contain a few sentences. And they will be fairly inaccurate.
The article talks about the long history of message IDs, but fails to put it in its historical context. Those first message manuals went with systems where storage (including disk space) was so precious you couldn't afford to put a text description of an error in it. The actual error messages had less than 12 characters of text, so they also had a message ID, which was an address in cheap tertiary storage: the paper manual.
Technology has progressed to where it is now a waste of resources to have a person look up a message. It's more efficient to have the computer just tell you what's wrong. But we've stuck with the tradition of terse error messages. They're usually one sentence or less, and in the Unix world, 3-4 words is considered ideal. Only part of this can be explained by programmer laziness; the rest must be just custom.
Other benefits of message IDs have been given here: enabling translation and searching problem databases. But enabling error messages to remain coy and withhold the majority of the information from you isn't one.
Posted Jun 22, 2007 21:24 UTC (Fri)
by jzbiciak (guest, #5246)
[Link] (1 responses)
Compare "permission denied" to "Your currently active user id, 'im14u2c', does not have write permission on the file '/tmp/xyzpdq'. This file is owned by 'im14u2c', but the user write permission bit on the file is not set. Please consult the 'chmod' man page."
The latter is very friendly to a new user. Just awesome. But, it would get real old real quick. And, depending on the context, the advice implied by the error message (in this case, chmod +w is implied) might be wrong advice. (For example, what if the file in question is an RCS controlled file that isn't checked out?) Perhaps a settable "user expert level" needs to be specified to indicate how chatty the system should be?
Posted Jun 23, 2007 2:16 UTC (Sat)
by giraffedata (guest, #1954)
[Link]
I don't think it gets old like you think it would. To know, you'd have to try it for a while. I use a lot of software that prints out 5 line error messages on a terminal (because I wrote the code) and it really doesn't bother me. And consider that a lot of programs respond to the most casual error of them all -- fat-fingering -- by not issuing an error message at all but just dumping the full command syntax on the terminal. This seems to be quite popular.
Incidentally, I've found it's rarely a good idea to give advice on how to fix it in the message; the best you can do is to describe the problem. Same is true for a message manual -- the complete set of advice would be a textbook.
And I've tried the expert/novice thing (as a user), and that doesn't work. You're never expert enough that you know all the errors. But maybe something that avoids issuing the same verbose message frequently.
But really, that's all beside the point because we're talking about kernel messages. The kernel isn't interactive -- these things go primarily in a log thousands of lines long.
Hmmm... there's a tradeoff. Verbose error messages are very useful for the beginner, or for obscure error messages that happen very rarely. Terse error messages are more efficient, especially for errors that occur often.Getting the message from the kernel
Getting the message from the kernel