Hi Klemens, Klemens Nanni wrote on Sun, Jun 30, 2019 at 01:04:17PM +0200: > On Sat, Jun 22, 2019 at 11:20:10AM -0600, Theo de Raadt wrote:
>> The problem is when I'm on screens that don't have scroll-back, those 9 >> lines have scrolled other information off the top, and then I've had to >> repeat the operations, or if not possible, been more frustrated. > Should we change those programs and refer to manual page or show a > synopsis one-liner instead? Yes, i think programs emitting excessive amounts of text (when called with a typo, and even more so when doing that always on startup, like gdb(1)) should be fixed to shut the hell up. This is Unix. > I get the scroll-back argument, but I dare say it's a weak one given > that this is something users can fix most of the time, e.g. by using > tmux. I find it offensive being told to use tmux(1) merely because some programs like to chew my ears off. I get it that many developers find tmux(1) useful for many purposes, but the availability of add-on tools allowing workarounds is no excuse for programs being annoying in my face. Also, with tmux(1), i might get scrollback. But having the immediate command history remain on screen is still much better than being able to scroll around and having to look for the relevant lines buried among long, irrelevant output. Yes, long usage is mostly irrelvant: a typo doesn't mean i need to re-read a long list of commands provided. > I'd really like to have a valuable usage in ldomctl and haven't > come up with a better and still consistent way of doing so. There is consensus two parts of documentation are useful: * A short usage message shown after typos, typically one or two lines. * The manual page, containing complete and concise reference documentation. Personally, i wouldn't object to exceptionally complicated programs (like openrsync(1) or ldomctl(1)) providing command summaries (typically one line per command) *when the user explicitly asks for it* with an option like -h or --help. But i do see Theo's argument that likely we don't really need three different levels of detail, adding additional maintenance effort and danger of getting outdated. > ssh-keygen is another good example of long usage that is most probably > not going to change back to a simpler one; I just stumbled over it due > to wrong usage and was therefore reminded of this mail thread. > > What do other (ldomctl) users say? This isn't really a question for ldomctl users at this point. Usage should be very short as a matter consistency of the operating system; in that sense, i do consider ssh-keygen(1) an offender. *If* we decide that it would be valuable for selected programs to provide an intermediate -h or --help, only then would it become a question for ldomctl users whether ldomctl(8) is one of them. But so far, i don't see consensus that we want to allow adding such -h or --help options to base programs. I'm mildly in favour if in favour at all, and i have heard strong opposition, with the reasonable argument that it adds maintenance effort for little gain because it's not really that hard to find the information quickly in a real manual page. Yours, Ingo
