While I like the dhelp script idea, I think man is a pure UX issue - man should generally DWIM because if I type "man foo", I don't want to jump through hoops. There times (looking at libraries and system calls and the like) that knowing the system helps. However, with >20 (IDR how many - a bunch) this gets annoying. I think the easiest fix would be for debian to have a per shell alternatives search (/etc/alternatives/man/<shell>) that the shell's global rc can prepend to $MANPATH (of course, I compile zsh from git, so no help for me, but w/e). This way we can include builtins for shells and they are no longer there when we switch shells.
On Sun, Nov 2, 2014 at 12:17 PM, Carl Fink <c...@finknetwork.com> wrote: > However, doesn't the Debian policy manual require a man page for every > program? These aren't programs (though, man [ DWIM - guess it's both a program AND a builtin - ugh) these are a part of your shell - a program, but it's like arguing that each program function gets a manpage - not happening. > Wouldn't that lead users to try the man system to get help on every > command, since a new or non-technical user would have no way to know that > umask or read or fg is not a "program" but a personality of Bash? So why > _not_ have a man page for them? And I agree with this (again because the man system should try to DWIM). Just not as a part of a global man system (because that would fail to DWIM which has already been pointed out for the which command). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAH_OBicFXPCU=psJ_UHLYDqsSFFeuGQjG-13P=fwflgrejt...@mail.gmail.com
