I agree, IMHO the existing functionality should be better documented. Perhaps the logic of what [man://foo] does could be addressed.
| [reply] [d/l] |
As someone who stands ready and willing to make the suggested corrections, I have to tell you both that I have not been able to glean what is wanted, from this thread. Please, one of you, write up a very concise statement of the fix(es) wanted.
I am not inclined to go reading all of the references you've given, even the other thread(s?) here on PerlMonks, in order to make sense of what you're talking about.
And taint, I strongly encourage you to finish your research and thoughts before posting. Writing things like "just a sec, I'll check...better, I'll list them..never mind" doesn't help anyone, including you. Remember that these posts will be here for years. If your post is barely comprehensible now, it will be entirely incomprehensible in 5 years. Thanks.
I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies .
| [reply] |
This was indeed a struggle. taint discovered that using [man://cmdname] did not do the same thing as typing man cmdname on their freeBSD box, which surprised them. They had not noticed that the [man://] links generate a url with &manpath=SuSE+Linux/i386+11.3, specifying the OS/distro man pages to display results for. In What shortcuts can I use for linking to other information? it states "Unix man pages:".
For the sake of reducing any ambiguity I think that the text associated with this section should state that the lookup will check for a particular OS/distro, and name it explicitly. A more complicated change would be to alter how [man://] links work so that users could specify which OS/distro was linked to, however since this could be achieved using the current method for linking e.g. [http://foo.com?bar=baz|man baz], this is overkill IMHO.
| [reply] [d/l] [select] |