I’ve noticed that the software running the SDMB fails to understand a number of common (and some not-so-common) but standard URL schemes. In particular, it seems that any URL which does not contain the string “://” is not parsed properly; the software appends “http://” to the beginning of the URL and tends to truncate parts of the rest. Some examples of correctly and incorrectly interpreted links:
[ul]
[li]ftp://foo.example.com/ (link to an FTP site, e.g., to download software)[/li][li]mailto:foo@example.com (link to an e-mail address)[/li][li]news:foo@example.com (link to a Usenet message)[/li][li]news:foo.bar.baz (link to a Usenet newsgroup)[/li][li]nntp://foo.example.com/foo.bar.baz/ (link to a Usenet newsgroup on a particular server)[/li][li]tel:+1-800-555-5555 (link to a telephone number; if you have a modem and the right software your computer will automatically dial it for you)[/li][li]telnet:foo.example.com (link to a telnet service, such as MUDs, BBSes, and library catalogues)[/li][li][file://foo.example.com/bar](file://foo.example.com/bar) (link to a file on a particular server)[/li][li][data:,A%20hello%20world](data:,A%20hello%20world) (link to an embeded file)[/li][/ul]
The biggest problem for the SDMB is that this makes it impossible to link to Usenet threads in a standard way. (Yes, one can always link to Google Groups, but for all we know the SDMB could outlive Google Groups, and in any case most people would prefer to read news in their preferred news client instead of being forced to use one in particular.)
Anyway, if there’s some option you can switch to fix this, it would be great. Otherwise, if it’s a bug, I suggest we tell the vBulletin developers that one of the biggest and greatest message boards on the Internet wants its software to support Internet standards!
I dunno what they’re thinking over in vBland, but I would bet that since one of the options for the board is to accept html coding, they don’t think it necessary to translate; if you wisah to use html, the board operator can turn it on.
However, we have had to turn off html due to abuse of the function; some people just do not play appropriately with tools when we make them available.
Barring a change on vB’s part (like in an upgrade, we’re several behind here and might upgrade at some point, though I see nothing scheduled but that might change at any time), I’m afraid you’re just going to have to put up with it. Sorry about that.
It’s useful for referring people to files on their own machines (and most home computers won’t have HTTP or FTP servers running). For example, if you are running a Unix-like system, and I wanted to explain to you what a /tmp directory is, I could make an actual link to your own computer’s [/tmp](file:///tmp/) directory. (file: isn’t Unix-specific, though; it will also work for MS-DOS, MS-Windows, MacOS, etc.)
Actually, URL syntax doesn’t have anything to do with HTML. They’re two separate standards. For all I know vBulletin might try to “fix” URLs even posters could use HTML <a href="…">…</a> syntax. But anyway, I guess there’s nothing that can be done about it in the moment. Maybe the bug has already been fixed and the problem will go away the next time the SDMB’s software is upgraded.
Then your browser must be very forgiving, because that URL is invalid. Backslashes aren’t allowed anywhere in URLs, and colons aren’t allowed after the “file:” scheme.
Hmm. I dunno then. For what it’s worth, these also work:
file:///c: emp
file:///c:/temp
These three differently formatted URLs all fire up Windows Explorer and direct me to c: emp. They work in my browser, e-mails, various Microsoft Office documents, embedded URLs in AutoCAD .dwgs, embedded URLs in Microstation .dgn’s, etc.
[A documentation HTML file (OS X)](file:///Library/Documentation/Libraries/libiconv/iconv.1.html)
[“Download” your OS X Console.log to your specified downloads area](file:///Library/Logs/Console/501/console.log)
Oddly enough, these seem to work when I “open the link in a new window” but not as a direct left-click.
Could be your browser’s sense of security. My Mozilla won’t open any file: URL on a remote web page, regardless if it’s a left-click, middle-click (open in new tab), or right-click + open in new window. I think it should at least fire up a warning or error message so the user knows why the link doesn’t work.