2010-04-24

On linking

The Unix filesystem concept of ``links`` is quite wonderful. I remember a couple conversations with my father which touched on the question "is anything possible". For some reason my example to prove that, in fact, not all things are possible, was to state that I can't be both here, downstairs, and upstairs at the same time. It seemed irrefutable that a thing can only be in one place at one time.

That may or may not be true, but filesystem links offer cool magic.

However, the quality of explanans offered by Unix could be improved, and
the Python equivilent is flat out confusing.

$ man ln
...
SYNOPSIS
ln [OPTION]... [-T] TARGET LINK_NAME (1st form)
ln [OPTION]... TARGET (2nd form)
ln [OPTION]... TARGET... DIRECTORY (3rd form)
ln [OPTION]... -t DIRECTORY TARGET... (4th form)
...

Target and link_name are reasonable names, although a bit of a mixed metaphor, target implies an arrow or bullet, not link name. I also don't like the order, I approach the link and arrive at the target, why put the target first?

Python is much worse:

>>> help (os.symlink)

symlink(...) symlink(src, dst)

Create a symbolic link pointing to src named dst.

Huh? the destination points to the source? Just Plain Nuts, Don't Make Sense, Oh Puh Leaze.

***********************************************************

I've been for some time futzing with code to wrap link management, eventually want a buildout recipe which describes link wrangling, particularly the ``gather`` idiom, which moves a file to a managed location, replacing it with a link. Useful for versioning configuration.

I like the following spelling to describe links and files:

['ln1', 'thefile'] or ['ln3', 'ln2', 'ln1', 'thefile'] which could also look like: "ln3 -> ln2 -> ln1 -> thefile"

I think it would make me happy to specify links this way, both in arguments and and reports.