The default shell on Solaris boxes seems to be Korn and the version that I have encountered doesn’t appear to allow obvious access to the command history. In the bash shell, the up and down cursor keys scroll through your command history for you but Korn doesn’t seem to allow this. Thankfully, there is another way: you can set up the editor vi as the default method for gaining access to the command history by adding the following line to the .profile file in your home directory:
set -o vi
Then, you can use the Vi (it’s pronounced vee-eye, apparently) commands ESC+h and ESC+j to move up and down the list of previous commands. That, or, assuming that you have access to it, just use the bash shell anyway…
UNIX (and Linux) does a wonderful trick with its file and folder shortcuts; it effectively treats them as file and folder transporters that transfer associate a file or folder that exists in one folder hierarchy with another and it is treated as if it exists in that hierarchy too. For example, the images folder under /www/htdocs/blog can have a link under /www/htdocs/ that makes it appear that its contents exist in both places without any file duplication. For instance, the pwd command cannot tell a folder from a folder shortcut. To achieve this, I use what are called symbolic links and the following command achieves the outcome in the example:
ln -s /www/htdocs/blog/images /www/htdocs/images
The first file path is the destination for the link while the second one is that for the link itself. I had a problem with Google Reader not showing up images in its feed displays so symbolic links rode to the rescue as they did for resolve a similar conundrum that I was encountering when editing posts in my hillwalking blog.
Having had a UNIX shell script attempt to copy a non-existent file, I decided to take another look for ways to test the existence of a file. For directory existence checking, I was testing for the return code from the cd command and I suppose that the ls command might help for files. However, I did find a better way:
if [ -f $filename ]
echo "This filename [$filename] exists"
elif [ -d $dirname ]
echo "This dirname [$dirname] exists"
echo "Neither [$dirname] or [$filename] exist"
The -d and -f flags within the evaluation expressions test for existence of directories and files, respectively. One gotcha is that those spaces within the brackets are important too but it is a very way of doing what I wanted.
I have just discovered that if you have a number with a leading zero, such as 08, it is assumed to be an octal number, that is, one of base 8. The upshot of this is that you get errors when you have numbers like 08 and 09 in your arithmetical expressions; they are illegal in octal: 08 should be 10 and 09 should be 11. Og course, as luck would have it, you get exactly these expressions when date/time processing. Luckily you can forced things to be base 10 by having something like 10#08 or, when extracting the minute from a date-time value, 10#$(date +%M). Strange as it might appear, this behaviour is all by design. It is dictated in the POSIX standard that governs UNIX. That said, I’d rather it if 08 was interpreted as an 8 and 09 as a 9 rather than triggering the errors that we see but that could have been seen as muddying the simplicity of the standard.
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 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 taking 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 amazing 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.