Note: This article is marked deprecated. It means that it might contain old and/or outdated information that is no longer accurate or even relevant.

Tidy-html5-logo

About using libtidy-balthisar.dylib

A significant new feature of Balthisar Tidy (starting at version 2.2.0) is the ability to use it with a different version of libtidy than the one that it ships with. libtidy, of course, is the engine that Balthisar Tidy uses to actually perform tidying, and is part of the Unix standard HTML Tidy tool (so much of a standard that it comes pre-installed on Mac OS X, by the way).

This feature can be useful when libtidy is updated before Balthisar Tidy, which is a not infrequent occurrence. HTML Tidy (and thus libtidy) is receiving regular updates and bug fixes since HTACG has gotten involved, and it's very easy to build HTML Tidy compared to releasing Balthisar Tidy in three versions and awaiting Mac App Store approval for minor bumps.

If you're adventuresome and want to try this for yourself you'll have to install a newer version of libtidy and create a symbolic link pointing to libtidy.dynlib at /usr/local/lib/libtidy-balthisar.dylib. As long as this symlink (or binary, if you prefer) is here, then Balthisar Tidy will automatically use it instead of its own version. Simply delete the symlink if you want to return to Balthisar Tidy's built in library. Instructions for this are included in Balthisar Tidy's Help file, but you're on your own to figure out how to install HTML Tidy.

To an experienced Mac user creating a symbolic link is no big deal, but users uncomfortable in the shell and people who don't even know what a symlink is are bound to be confused as to why this is necessary. One might ask…

Why can't Balthisar Tidy just let me choose a library with a file open dialog box? The issue here is libtidy is a dynamic library (its full filename is libtidy.dylib where the extension meaning should be obvious now), and an application in Mac OS X has to know the name of a dynamic library at the time the application is built. This is because Mac OS X uses something called a "dynamic linker" to search for eligible libraries (specified by a known name), and then connects the application (Balthisar Tidy) to the library (libtidy) at runtime. Without knowing the name of a library, the dynamic linker won't work.

Then why can't I specify an arbitrary folder to have libtidy there? In addition to knowing the name of the dynamic library to performing linking, the dynamic linker also has to have a list of possible search paths, i.e., locations on your PC where the library could possibly exist, and this list can only be provided at the time the application is built.

Okay, why not build Balthisar Tidy so that the dynamic linker can look into my ~/ (user) directory, or in ~/Application Support? I don't need to sudo to put libraries there! This would actually be a good, even preferable strategy, and it's within the abilities of Mac OS X's dynamic linker except for one detail: sandboxing. Sandboxing is Apple's approach to ensuring that applications (such as Balthisar Tidy) can't do naughty things to your operating system. Sandboxed applications simply don't have permission to read outside of their own little, allotted space, with the exception of the special /usr/local/ directory structure. Because this is a root-owned directory (you have to sudo to install anything here), it's currently explicitly trusted by the operating system. The Mac dynamic linker will happily load libraries from this location (and, of course, lib/ within this directory is a de facto Unix standard for non-OEM versions of libraries).

Okay, then why libtidy-balthisar instead of just libtidy? libtidy is the name of the library installed by HTML Tidy. The dynamic linker is pretty flexible, but it's very difficult to control once an application is built. In the case of Balthisar Tidy it will try to find the library in /usr/local/lib/, and if it's there, then end of story; it's the library that will be linked and there is no way for Balthisar Tidy to override it. This would then force you to remove HTML Tidy from your system in the event you wanted Balthisar Tidy to use its own, built-in library instead. With our approach, all you have to do is remove a symlink. This also substantially answers the next question…

Why not use a preference for this? As above, Balthisar Tidy has no control over the dynamic linker. It's up to you to control by choosing to use or not use a symlink in the right spot with the right name pointing to the right place!

comments powered by Disqus