Monday, October 6, 2008

Where do find help for commands?

Today an discussion rised up in #debian-devel on the OFTC IRC Network. It started because someone noted the bug report #501318 which is, to summarize it, just a user mistake, because someone obviously read the man page (time(1)) for the /usr/bin/time command, while time is also a shell builtin (which does not accept the same arguments as the time command. Certainly this bug reports appears to be funny at the first sight, but on the other hand, there is a suboptimal situation that leads to this.

  1. There are some builtin commands that also have binary equivalents (like time, printf, echo). Its quiet easy to tell weither the one or the other is used, by using the which command, but thats not really a realistic workflow, so its better to know this. The difference between these commands is often causing problems, which we have to cope with. For example bashs builtin echo behaves different as /bin/echo and people who use the bash as their default shell tend to use what bash provides, which in turn causes problems if other people who use a different default shell try to work with these scripts. But this is another problem, because...
  2. ... every program, utility and function in Debian has to provide a manpage, as said by our policy: "Each program, utility, and function should have an associated manual page included in the same package." I guess that the rationale behind that is that 'man' is a very common tool in the Un*x world, which is wide-spread and which usage is much recommended to find out how specific tools behave. It is always referred to in Documentation, weither it is Debian specific or not, e.g. in books.

    The time package, which is of priority Standard and which includes /usr/bin/time, does conform to that policy by providing a manpage for the time command. The various shells don't do that, because they usually don't have a man page for each and every command (usually they have a more generic manpage which includes the builtins or in some seldom cases a special manpage for such and similar things (as for zsh, which has zshmisc(1)) and because its not that easy, because the man command cannot (AFAIK) distinguish between the user joey_average calling 'man time' in a bash, while the user schoenfeld calls the command 'man time' in a zsh, or if joey_foobar calls 'man read' in a shell which does not have a builtin time command and uses /usr/bin/time instead.
So whats wrong about this situation? Would you say that users that expect 'man time' (or similar examples) to do the right thing are making wrong assumptions? I disagree. Its what they've always been told to do. And if it does not show anything eventually run info, or look at HTML documentation or what else. But they haven't been prepared for the case where the manpages does show something, something wrong. The good thing is that the manpage for time includes a sentence:

"Users of the bash shell need to use an explicit path in order to run the external time command and not the shell builtin variant."

The bad thing about it is, that it is at approx. 70-80% of the manpage.

Clint, the maintainer of zsh, mentioned run-help which seems to be a part of the zsh, but not of any other shell, and does more or less the right thing (at least for the builtins) but not for external commands and not even for itself (it opens the code of the function instead of something user-readable like a manpage). I guess "one tool for a specific need" is a good maxime, but is it really a good maxime for finding documentation?

But how could the situation be bettered? I could think of a wrapper for man, similar to run-help but as a more generic solution. Any ideas for it? Is it the right way at all to better the users experience? Any other ideas? Other opinions?

6 comments:

Des said...

I have to say, thinking about it for a while... I see the solution being a shell builtin. how? a man shell builtin that displays the help thing if the command is a builtin or otherwise runs man as usual.

Of course the man man would be kind of a special thing ;-p

Probably this can easily be done with a bash function and using the type builtin...

Matthew W. S. Bell said...

I came across this issue when I was new to Linux. The two problems I came across when trying to resolve this issue:

1. I was unable to ascertain whether a specific command was a built-in or not.

2. If the command was built-in, finding the documentation for it was harder than it should be. I believe this also applies in the case of a built-in with no corresponding external command.

Jan Hudec said...

Maybe configuring man with some special sections for shell builtins would be enough.

Man allows defining arbitrary sections for man pages. So one could create man pages for bash builtins in bash section and for zsh builtins in zsh sections. Than it would just require setting the section search order depending on the shell using environment variable set from system login script.

I am not sure the search order can be set from environment, but I suppose it would be relatively simple change if it can't.

foobar said...

help built-in command provides help on it, and doesn't man $SHELL give some details too?

djadala said...

see bug #256197 :)

Ken B said...

Jan: the $MANSECT environment variable determines what sections are searched and in what order. (Though some patch allowing one to override the order without accidentally excluding sections would be useful.)