Posted: 20 Jan 2019 04:30 AM PST
After Hieronymus Bosch, the artist who has developed the theme of devils more than any other was the visionary William Blake, who was influenced by Henry Fuseli.
Blake’s Satan Exulting over Eve from about 1795 has its roots in the story of the Fall of Man in Genesis, and in Milton’s Paradise Lost, in which Eve has a dream of Satan giving her the fateful apple, sweeping her up into the cloud before she sinks down and falls asleep.
Blake is unusual for separating Satan, a fallen angel flying low over Eve, from the serpent which has already coiled itself around Eve’s legs and body.
A similar fallen angel appears in Blake’s Good and Evil Angels from 1795–1805. Here Satan is shackled at the left ankle, although that shackle doesn’t appear to be attached to anything. Like Fuseli, Blake believed in Lavater’s ideas of physiognomy, and constructs the two angels in accordance with its principles.
Blake’s images inspired by the book of Revelation present some of his most extraordinary visions of devils, although you need to be very careful over who is who. The Great Red Dragon and the Woman Clothed with the Sun from about 1803 shows the start of Revelation chapter 12, which refers to “a great red dragon, having seven heads and ten horns, and seven crowns upon his heads.” This unique chimeral beast with body parts drawn from human, dragon, and caprine sources may thus be a devil, but isn’t Satan.
Satan appears again in Blake’s The Angel Michael Binding Satan from about 1805, which refers to the start of Revelation chapter 20: “And I saw an angel come down from heaven, having the key of the bottomless pit and a great chain in his hand. And he laid hold on the dragon, that old serpent, which is the Devil, and Satan, and bound him a thousand years, and cast him into the bottomless pit”.
This is the same scene which had been painted earlier by Bonifazio Veronese and Tintoretto, and Blake opts for a fusion of serpent, dragon, and fallen angel.
Blake’s fallen angel reappears in his late glue tempera painting of Satan Smiting Job with Sore Boils from about 1826, a development from an image which he had engraved for his illustrations to the Book of Job the previous year.
In 1854, Ary Scheffer followed a similar model in his Temptation of Christ, where the fallen angel is trying to get Christ to jump from a pinnacle so that he could rely on angels to break his fall.
Among the narrative works which Paul Cézanne painted early in his career is this account of The Temptation of Saint Anthony from about 1875. It shows the devil in stereotypical form, wearing red robes and with an animal head and horns, behind the figure of Saint Anthony.
John Roddam Spencer Stanhope’s Pre-Raphaelite Temptation of Eve from about 1877 appears to have been influenced by Bosch’s serpent from Tha Haywain, with its human head on a serpent’s coils.
This period also saw satirical and thoroughly irreverent depictions of The Temptation of Saint Anthony such as that painted by Félicien Rops in 1878. Behind its cross the horned devil wears scarlet robes and pulls faces, and is accompanied by two daemonic putti.
In 1885, Gustave Moreau fused Bosch’s human-headed serpent with the wings of a fallen angel for the devil in his painting of Eve.
Eve and the serpent grew into something of an obsession with the femme fatale for Franz von Stuck. Here is his Sin from about 1893, in which the serpent’s body passes between Eve’s legs and its head rests on her shoulder, the tongue flickering out in menace.
This last painting of the devil brings this pair of articles back to its starting point, with Goethe’s Faust. One of many depictions of its two principal characters, Mephistopheles conforms to traditional physiognomic rules and looks very human and every bit a devil. He’s the antithesis of the devils of the Renaissance, and far more dangerous.
Posted: 20 Jan 2019 12:00 AM PST
The more you look at them, the more links become the most complex and confusing of simple concepts in computing. I started the last couple of weeks with a simple summary learned progressively over the last thirty years: symlinks for the command line and shell scripts, Aliases for the GUI, and hard links only when you really must and know how to use them.
Then as I researched for and wrote up my series of articles here, several of you came back with excellent (and greatly valued) comments which made me question whether those rules of thumb were right. I went back and looked again, and again, and their simplicity was lost. As symlinks work fine in the Finder too, why not use them more, instead of Aliases?
After more experimentation and examination of their practical use, I came back to my original rules of thumb, elaborating them into tables which I published here just over a week ago. I thought the topic was done.
Then came more comments, particularly those from David Charlap, which brought me what seemed a sudden insight: of course, with a symlink you get to specify the path used for the link. So you have a choice between using relative and absolute paths, in many cases at least. Like an alchemist who had just created their first small lump of gold-coloured goo, I wondered why I hadn’t read more about this choice before.
I went back and re-read the man page for the
Classical examples of where symlinks work well, and are widely used, include:
In each case, there isn’t any real option as to the type of path used. It’s either determined by the purpose of the link, or architectural.
I was then distracted by Thomas Tempelmann’s suggestion for a utility to refresh Aliases and identify those that are broken. This brought with it a more worrying insight: most of the Aliases on my boot volume, even those inside /Library, are broken. Apple’s ingenious composite of symbolic and hard link, crafted to make it more robust when it’s moved or paths change, and served in the friendly GUI, hasn’t solved the problems of links after all.
The underlying problem is that Aliases don’t update themselves quietly when you’re not looking. Most, perhaps all, of those broken Aliases have been migrated across from older Macs. But in that migration, they don’t seem to have become refreshed, nor checked to see whether they are broken.
Unlike good friends, Finder Aliases don’t keep well when left alone. Let’s say that you create an Alias to a working folder buried deep somewhere in your ~/Documents folder. Over time, things get moved around and renamed. When that Alias lies unused and (most significantly) unresolved, it will still work so long as its fallback resolution mechanisms work too. In the meantime, it remains half broken, as its symlink part, the absolute path, no longer exists.
When that unused and unrefreshed Alias is copied over to another volume, perhaps when you migrate to your next Mac or clone that volume to another, the second half of the resolution mechanism in that Alias breaks too: on a different volume, the unique inode and file numbers for the item to which it points are also now broken. Try to resolve it, and macOS cannot find its original item.
I can’t find any current documentation which details those operations which cause a Finder Alias to update its internal information. As they changed substantially in macOS 10.12, when Apple ceased maintaining most of its systematic guides, it’s now a matter of trial and error. As far as I can tell from inspecting the opaque and undocumented information stored within an Alias, simply accessing it using
To look at what the Alias is currently pointing to, you have to open it, which could of course cause it to resolve and try to update its internal data. Even selecting an Alias in an Open File dialog can be sufficient to cause it to resolve and update its contents.
There is a need for a utility to refresh Aliases and check them for broken links. Alifix is a step on the way, and I hope will address this need and more. But it also demonstrates how right I was when I opened the first article in that series with the words:
And I’m still not sure that I’m any the wiser.
|You are subscribed to email updates from The Eclectic Light Company. |
To stop receiving these emails, you may unsubscribe now.
|Email delivery powered by Google|
|Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States|