5 ms·
As I discovered in practice, it seems to be a trend with authors of such small-size software to also forgo any kind of documentation: what options are supported
by aasasd 5y ago
As I discovered in practice, it seems to be a trend with authors of such small-size software to also forgo any kind of documentation: what options are supported by specific commands, what behaviours they exhibit (which sometimes differs between GNU and BSD). The ‘usage’ messages are also terse and cryptic to the max. Doubly baffling when the audience of the software is supposedly corporations building their userspace. Do the authors sell the docs on the side, or what?
Anyway, for users trying to do stuff with these utils, the available paths seem to be either finding StackOverflow answers from others who already messed with their own systems and survived, or being the first to do the trial-and-error.
- jml7c5 5y agoIt appears that each command is documented at the top of its respective source file. Though I may be misunderstanding and you mean that that documentation is insufficient. Regardless, I agree that there should be a proper man page with more detail.
- deleted 5y ago[deleted]
- 1vuio0pswjnm7 5y agoIts been said that the best documentation is source code. For UNIX I have always found this is solid advice. Whats nice about small programs, such as this one, is that its more feasible to use the source code as documentation. "Anyway, for users ..." Ah, thats me. I am a user. I personally love terse and cryptic, i.e., minimising the number of keys I have to press. IME, multicall binaries like the OP presume some pre-existing knowledge of how to use the utilities they contain. It seems nonsensical to complain about missing documentation given the purpose of a multicall binary is to conserve space. With BSD, the utilities in crunched binaries are generally the same ones, i.e., use the same source code, as in one in the userland. With GNU busybox, they are not, and one needs to read the source code to understand the differences. Even if I can figure out how to use a program from reading documentation I still look at the source code before using it for the first time.
- maydup-nem 5y ago> Its been said that the best documentation is source code fuck you. it's a myth perpetrated by lazy programmers, who can't be bothered to spend an hour or two writing a comprehensible usage manual, while otherwise EVERY USER IS GUARANTEED to spend MORE just figuring out how to BEGIN using his crap. It's only forgivable for the simplest of self-explanatory /API/ calls, but /nothing/ in userspace.
- croon 5y agoEdit out the expletive and replace the caps with ~ before and after and I'll agree with everything else in the comment.
- matthewh806 5y agowhat a tiresome bore you sound
- dang 5y agoPlease don't cross into personal attack or name-calling, regardless of how bad another comment is or you feel it is. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- forty 5y agoI think your comment can be improved by removing your first two words, which brings nothing to this conversation.
- maydup-nem 5y agoIt's too often that developers adopt this attitude that I have to resort to vulgarity. They are practically forcing my hand there.
- craftinator 5y ago
- Already__Taken 5y agothis is what I think powershell has contributed. you literally can't make a utility that doesn't have documentation because it's generated from the code.