Technology Tales

Ghostscript: **** Unable to open the initial device, quitting.

The above error message has been greeting me when creating PDF's with Ghostscript on a Solaris box and does need some translation. If you are directing output to a real printer, I suppose that it is sensible enough: nothing will happen unless you can connect to it. It gets a little less obvious when associated with PDF creation and seems to mean that the pdfwrite virtual device is unable to create the specified output file. A first port of call would be to check that you can write to the directory where you are putting the new PDF file. In my case, there appears to be another cause, so I'll have to keep looking for a solution.

Update: I have since discovered the cause of this: a now defunct TEMP assignment in the .profile file for my user account. Removing that piece of code resolved the problem.

Quickly surveying free disk space on UNIX and Linux

Keeping an eye on disk space on a Solaris server is important for me at work, while keeping the same top level overview is good for my use of Linux at home too. Luckily, there's a simple command that delivers the goods:

df -h 2>/dev/null

The df -h piece is what delivers the statistics while the 2> /dev/null rids the terminal of any error messages; ones stating that access has been denied are common and can cloud the picture.

Numeric for loops in Korn shell scripting: from ksh88 to ksh93

The time-honoured syntax for a for loop in a UNIX script is what you see below, and that is what works with the default shell in Sun's Solaris UNIX operating system, ksh88.

for i in 1 2 3 4 5 6 7 8 9 10
do
    if [[ -d dir$i ]]
    then
        :
    else
        mkdir dir$i
    fi
done

However, there is a much nicer syntax supported since the advent of ksh93. It follows C language conventions found in all sorts of places like Java, Perl, PHP and so on. Here is an example:

for (( i=1; i<11; i++ ))
do
    if [[ -d dir$i ]]
    then
        :
    else
        mkdir dir$i
    fi
done

Got OpenSolaris back

Having done a reinstallation, I have now got OpenSolaris going again in VMware and cloned the VM in case I go on a wrecking spree once more. I am going to leave VMware tools uninstalled for now so that I don't encounter the display problems I previously experienced. Speaking of how it looks, I uploaded a screenshot here; the difference between how it looks and the appearance of its ancestor is enormous. Having sorted the VMware/ZoneAlarm clash, networking not works as it should, and I can access the web through Firefox. Now that everything is all set, the real explorations can begin.

Trying out OpenSolaris

Having been programming (mostly in SAS as it happens) on Sun's venerable Solaris operating system platform at work since the start of this year, the chance to try OpenSolaris x86 edition in a VMware virtual machine seemed a good opportunity for advancing my skills.

Before this, my exposure to Solaris was when I was at university and things have moved on a bit since then, not least on the technology side but also in terms of my own skills. In those days, my mindset was fixed by exposure to macOS and Windows with their point-and-click functionality; the fact that the terminals that we were using were ancient didn't make for a positive impression. You can see below what I mean. And the concept of tackling a command line, even one as powerful as that in UNIX, armed with a good book was somehow foreign to me.

Mind you, in those pre-Safari days, getting your hands on books not in the university library was an expensive outing for the student finances. Armed with years of programming and web development experience, the UNIX command line now looks like a powerful tool to be used to the greatest advantage. Years of exposure to Perl and Linux have made the tool a less daunting one for me. Also, the availability of shell scripting makes the Windows batch file language look positively archaic. The default ksh shell (I believe that it is ksh88) in Solaris is not as friendly as it could be, but bash is available on demand, so life isn't that uncomfortable on the command line.

To date, my experience of OpenSolaris has been brief because I wrecked the installation while trying to sort out an annoying graphics issue that appeared after installing VMware Tools (drivers for various pseudo-devices) on OpenSolaris; I have yet to put things back. The installation procedure is pretty painless for what is a technical operating system. The Community: Tools section of the OpenSolaris website has articles on installation and installation under VMware is discussed on Developer's Quarterdeck Log.

As regards a desktop environment, you have a choice between the ubiquitous Gnome and Sun's own CDE, of which I have seen plenty at work. As it happened, I installed the developer edition, but there are the usual Linux mainstays on the desktop: StarOffice (in place of OpenOffice), GIMP, Mozilla Firefox, etc. One thing that I wasn't able to sort out was the internet connection, and that may be because ZoneAlarm was blacklisting VMware at the time of installation. All in all, it looked like a far friendlier environment for users than that which I encountered during my early years on UNIX. I must get it back in action and take things on from here…

VMware and ZoneAlarm

Contrary to appearances given by this blog, I am not exclusively a Windows user. In fact, I have sampled Linux on a number of occasions in the past and I use VMware to host a number of different distributions – my Ubuntu installation is updating itself as I write this – as I like to keep tabs on what is out there. I also retain a Windows 2000 installation for testing, and have had a virtual machine hosting a test release of Vista not so long ago. I also have my finger in the UNIX world with an instance of OpenSolaris, though it is currently off my system thanks to my wrecking its graphics set up. However, ZoneAlarm has been known to get ahead of itself and start blocking VMware. If you go having a look on the web, there is no solution to this beyond a complete system refresh (format the boot drive and reinstall everything again) and I must admit that this sounds like throwing out bath, baby and bathwater together. I did find another approach, though: removing ZoneAlarm and reinstalling it. This wipes all its remembered settings, including the nefarious one that conflicted with VMware in the first place. It's remarkable that no one else has considered this, but it has worked for me, and having to have the security software relearn everything again is much less painless than rebuilding your system.