Re: Suggestion for new shortcut-tags: [man://] and [mskb://]

[moritz]

I quite like the idea of the [man://...] and [man://program (1)] shortcuts.

I'm not sure about [man1://] - it's quite intuitive, but it goes against the current design of having one pseudo-protocol per link type. So I'd rather go with [man://program (1)] instead (but don't really mind either way).

As for the mskb links: I've never posted a link to one of them (but then again I don't use Windows either), and haven't seen particularly many here in posts or in the Chatterbox. But I don't think they would do any harm either, so I'm not against it either.

[JavaFan]

Well, as long as they are formatted as URLs, why not

   [man://env]             # Any 'env' manual page.
   [man://env/1]           # Any 'env' manual page from section 1
   [man://env/1/Solaris]   # Solaris 'env' manual page from section 1
   [man://env//Solaris]    # Solaris 'env' manual page - any section

[mr_mischief]

I really like this version best out of the ones so far proposed. I have a couple of suggestions that might improve it even more.

I really don't like anything made to look like a URL to have a double solidus (what W3 likes to use for "forward slash") in it. Yes, I know the format used for a shortcut wouldn't have to be directly related to the actual URL to which it refers. That would be very unlikely anyway unless someone at PM controlled the sites referenced. It's just a strong habit to eschew syntax in a URL-alike that wouldn't actually be valid for a URL. Perhaps one of these would be nicer for every section of a particular OS:

[man://env/*/Solaris] # I like the "any" mnemonic
[man://ksh/?/Linux] # looks like a query string
[man://bash/any/OpenServer] # kidding about OpenServer
[man://ncftp/all/AIX]
[man://lynx/-/OSX/10.5.2]

The question mark works for two reasons: it makes what comes after it just look like a query string, and it's a one character wildcard in many contexts (with most manual sections being represented by a single character). The asterisk is pretty plain: anything goes here. The "any" and "all" are pretty self-explanatory. The ASCII minus sign (doing double duty and standing in for dash here, as it often does) is just a common URL member character that happens to be a valid directory name (even if it's not straightforward to 'cd' to Bash) and valid URL segment.

Also, a simple one in your scheme since people have mentioned specific versions of the OS:

[man://env/1/Solaris/5.10]

That's still an issue for Linux, since different distributions have different numbering schemes and such. Perhaps:

[man://env/1/Linux/RHEL/5]
[man://env/1/Linux/OpenSuse/9]

Or perhaps a few of the most popular Linux distros are considered their own OSes:

[man://env/1/RHEL/4]
[man://bash/*/Ubuntu/8.10]
[man://for/any/Puppy/4.1] # What? It's very popular in my office. ;-)

All of this leads to the inevitable maintenance questions, though. Who chooses which OSes are included? Who chooses which site to use for the man page links? What happens when that site goes down or changes its URL structure? Who's going to do the work on the PM end, and what Perl-related or PM-related resource would have had more attention if not for this? The MS Knowledge Base shortcut seems reasonable from the maintenance standpoint, as it's a single number reference to a single fairly stable site.

[ambrus]

Better, but I think it would be more intuitive if the format for giving the section would be like [man://1 env] or [man://env(1)]: the first one is similar the the syntax of the command-line man utility which you invoke as man env or man 1 env, the second is like the header on the formatted manpages.