Question: Error messages, Short help messages, and copyright #818
Comments
|
I kind of feel the same, but am much less worried about error messages than the page long help texts. |
|
We should probably rewrite everything, just in case. The long help texts should be the first priority though. |
|
I'll find some time this month to skim long helps for copy-pastes and replace instances. This may take me a long time as some of the utilities have many features that must be documented. If I encounter an error scenario when writing tests, I will check to see if the implementation has a unique error message, and if not will provide one in the test (and if applicable, replace that in the implementation) |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
In an effort to avoid any copyright violations of GNU's intellectual property re. GNU coreutils (and from that liability for this project), should we avoid using the same error messages as them? Some utilities already do this (e.g. base64) other utilities are identical here (e.g. basename)
I think it's a given that for things like long help, we should document the behavior from scratch.
But for things like short help and error messages, should we play it safe and treat any text that is the same, or looks paraphrased from, or otherwise looks derived from, GNU coreutils as a stand-in to be removed ASAP? And then, given the situation that message was being fired in, come up with a message reflective of the situation?
My view on this is to err on the side of caution (even though I can see it being a bit jarring for people used to GNU coreutils' documentation). What are yours?
The text was updated successfully, but these errors were encountered: