Two years ago, I wrote a blog entry with hints for setting up X11 for the astronomer. The problem is that while the hints in that writeup are still valid, they don’t work if you are using Xquartz because the preferences are stored in a different location for XQuartz versus the built-in X11. As such, I am reproducing those X11 hints here, but with the edits necessary for use with XQuartz.

Once you have installed XQuartz, the X11.app should automatically launch when a program that needs X11 is executed (If you are an old hand at X11, you probably discovered since moving to Leopard that you should NOT set the DISPLAY variable to :0 to display an Xwindow on your primary display, just leave DISPLAY undefined.):

1. There are many hidden preferences in XQuartz just like in many Mac Applications. You can see a list of the hidden (and not hidden) preferences using the command line tool defaults. To see the available XQuartz preferences, type:defaults read org.X.x11NOTE: If you are still using Apple’s built-in X11 implementation (or if you are using MacOS 10.4), just replace ‘org.x.X11’ with ‘com.apple.x11’ in all the following hints.
2. In addition to “reading” the preferences, you can write to them. From the command line you can type:
   • defaults write org.X.x11 no_quit_alert true
     This allows X11 to quit without an alert box. Useful if you find it irritating like I do that X11 will prevent me from logging out or the computer from restarting due to that dialog box. However, this does mean you can accidentally quit X11.app pretty easily if you hit cmd-Q at the wrong time.
   • defaults write org.X.x11 wm_ffm true
     Allows which X11 window is selected to follow the mouse, which is the way X11 behaves under most *nix systems by default.
   • defaults write org.X.x11 wm_click_through -bool true
     This activates click_thorough events in the Quartz window manager, which allows clicks to pinned windows, another behavior common to *nix X11 installations.
3. You can control which window manager is launched (if you prefer something other than the quartz-wm used by default). If you don’t have a ~/.xinitrc file, copy the default one:
   

   cp /private/etc/X11/xinit/xinitrc ~/.xinitc

   
   and then manipulate it with any text editor.
4. BIG LAPTOP USER HINT: Because XQuartz on the Macintosh uses authentication to prevent connections from unauthorized sources to the X11 client, something interesting happens when you change IP address, you will discover you can’t use X11.app from the MacOS X Terminal until you quite and relaunch X11.app. This happens to me all the time on my laptop when I travel and the IP address changes. I recommend either using the Xterm as your terminal or just get used to restarting X11 if you have problems connecting to the terminal.
5. You can run X11 remotely on your Mac, if you can ssh into your Mac, then just use
   

   ssh -Y youraccount@yourcomputer.com

   
   , the -Y flag should allow you to run X11 remotely as long as X11.app is running on your machine before the connection is made. If your ssh on the remote machine doesn’t support X11 connections and you have admin access, you can edit the file /etc/sshd_config on the remote machine and make sure X11 Forwarding is turned on by looking for the following lines and making sure they are uncommented and that all “no”’s are set to “yes”:
   

   X11Forwarding yes
   X11DisplayOffset 10
   X11UseLocalhost yes

And that is it for the hints for now.

Interestingly, the XQuartz wiki notes that

[MacOS] 10.5.7 updates the X11 server to match what shipped with 2.3.2. Most of the userland, however, only saw security updates. The version reported by X11 in 10.5.7 is 2.1.6 to distinguish it from the 2.3.x series which contains a much newer userland.

I have the feeling that the update to MacOS 10.5.7 will be released very soon now.

[UPDATE: In fact, it took almost two weeks, but MacOS 10.5.7 was released on Tuesday, May 12, 2009.]

Well, I’m way late to the game on this, but our long national nightmare is over – Xquartz for Leopard support full screen!

The Xquartz folks latest edition of Xquartz (version 2.3.2.1) includes full-screen support. Now, personally, I like the way X11 integrates with Aqua, but for those who prefer to use only one windowing system at a time, you can now do it on MacOS X Leopard. You can download it here.

The first one I noticed was the updating of Xquartz to version 2.3.0. Xquartz is the updated version of X11 for the Mac OS (even ahead of Apple’s own installed versions) that I prefer to use, largely because bug-fixes get rolled in here before they appear in Mac OS. This version requires Mac OS 10.5.4 and has a couple of caveats attached to it for programmers, notably:

The software supporting the deprecated imake build system is not provided in this package. If you need imake and xmkmf, please install the X11 package that came with your Leopard DVD before installing this version. Alternatively, you can compile these packages on your own or get them from a third party such as Fink or MacPorts. The darwin configuration files used by the imake build system are outdated and not supported. Developers using this build system are advised to migrate to autoconf.

[Added July 24, 2008: Apparently, this version of Xquartz changed the X11.app Icon so it now X11 looks like this

when it is on the Dock. Interesting, but it threw me for a second. The only documentation I found of this change is in a Ticket filed with XQuartz's bug reporting system. Still, I think this is a good idea, as it gives a visual cue that you are using XQuartz as opposed to the default X11 installation.]

Along with a bunch of library changes, the key update appears to be having the Xserver updated to the 1.4 branch of Xorg. There is also “support for adding new $DISPLAY sockets after the server is running” (which I think means using the DISPLAY variable will not break things) and “/usr/X11/bin/Xquartz is just a stub that will ‘do the right thing’,” whatever that means. I have upgraded to it and as a reminder, if you upgrade MacOS after installing Xquartz, you will need to reinstall Xquartz to get it back.

The other interesting software release for Mac-based astronomers I noticed today was SAOImage DS9 which has released version 5.3beta, which appears to be, based on the statement on their homepage that “MacOSX 10.5 users with firewall enabled, please use version 5.3 beta”, geared toward addressing the issue I noticed this April with version 5.2 where launching SAOimage DS9 with a certain firewall setting on the Mac could result in the the application becoming irreparably damaged at launch.

• Upgraded the freetype library to version 2.3.6, which fixes “A bunch of potential security problems have been found [and fixed in this release”
• Upgraded to pixman library to version 0.11.4.
• Xquartz fixes from xorg-server-1.3.0-apple21, the key fix being support for monitor hotplugging, although several security fixes also occurred.

Again, if you upgrade MacOS (say to version 10.5.4, which is supposed to be released soon in order to support iPhone G3 and MobileMe), you will likely need to reinstall Xquartz (unless Apple has upgraded their X11 installation to match Xquartz).

• All packages updated to versions intended to ship as part of X11R7.4 (as of 2008.04.21).
• Fixed multiple crash-causing bugs in the server.
• Fixed cmd-tab to properly move all windows forward when entering X11.app.
• Cleaned up multi-monitor support (still not completely bulletproof) [I have 2 monitors, so this is a big one for me].

As I have noted before, Apple includes some of the work done in this project in OSX updates, so it is suggested that you install the latest XQuartz release after updating to 10.5.2 (and any future 10.5.x or security updates).

[HOLD OFF ON THIS UPDATE! I have discovered that at least on one of my systems, this version of ds9 is refusing to run properly. It launched once, but when I attempted to check the “About SAOImage DS9”, it triggered the following error:

 “An internal error has been detected local header mismatch couldn't open “zvfsmntpt/doc/sun.gif”: no such file.

(this occurred in both Aqua and X11 versions). Furthermore, all future attempts to launch ds9 (again, either Aqua or X11) fail with the following error:

Error in startup script: couldn't read file “./zvfsmntpt/src/ds9.tcl”: no such file or directory  

Even removing the preferences file at ~/.ds9.prf didn’t help.]

Apparently, my problems with SAOImage DS9 in Leopard are a known issue. If you configure the built-in Firewall to “Set access for specific services and applications” so that you can approve “holes” in your firewall on an Application by Application basis, your first launch of SAOImage DS9 will irreparably damage the application!  Unfortunately, Apple implements the application firewall in part by modifying the Application package of the Application you are running by digitally signing it if it was not digitally signed by the developer (adding a file called CodeResources to the Application package). According the Apple’s documentation on this:

If you run an unsigned application not in the Application Firewall list, you will be presented with a dialog with options to Allow or Deny connections for the application. If you choose Allow, Mac OS X 10.5 will sign the application and automatically add it to the Application Firewall list. If you choose Deny, Mac OS X 10.5 will sign the application, automatically add it to the Application Firewall list and deny the connection.

So basically,Apple doesn’t warn you in the dialog box that comes up that it has whatever decision you make, it will modify the application by digitally signing it and it doesn’t give you a way to avoid this. This is, in my opinion, is an incredibly boneheaded move on Apple’s programmer’s part. They readily admit that

  Some applications check their own integrity when they are run without using code signing.

They suggest the application firewall will try to automatically detect these and avoid modifying them, but they should give you, the user, the option instead of making the decision via some internal algorithm.  MacOS X shouldn’t assume its OK to change an application. In the case of SAOImage DS9, they are irreparably damaging the application without leaving you a way to avoid the damage once you trigger the application firewall. Shame on you Apple. The only way to fix it is to reinstall the application!

So when I figured this out (a tip of the hat to this post on IRAF.net). I reinstalled the SAOImage DS9 executables (both Aqua and X11 versions) and before launching them, I set the Firewall (via the Security Pane of the System Preferences) to “Allow all incoming connections” (this is the default mode, so it is as secure as MacOS Tiger was). Everything now appears to work just fine.

Personally, I believe an application that fails its checksum should present a message indicating that is the problem instead of just crapping out, but in this case, the fault lies mostly with Apple. Apple is damaging applications by making this critical decision in the background, without user intervention!

The folks in Cambridge have kept busy. They have released SAOImage DS9 version 5.2. The versions for MacOS X include the following:

• Aqua 10.4 Tiger (Universal)
• Aqua 10.5 Leopard (Universal)
• X11 10.4 Tiger (Universal)
• X11 10.5 Leopard (Universal)

The rather extensive changes are detailed in the release notes here, but the notable ones to me include:

• ANALYSIS: for MacOSX tiger, wrap cmds with shell and PATH.
• GUI: change default directory for standard dialog to $HOME.
• ANALYSIS: add /sw/bin to default path for MacOSX. While unstated in the release notes, this is clearly an attempt to support Fink, which places its installation in the /sw directory.
• GUI: ds9 will now start in the users home directory for MacOSX Aqua users when invoked from a double click and the default dialog box is Motif or Windows.
• MACOSX: fixed a problem with printing non standard colors.
• MACOSX: restore postscript printing.
• REGIONS: apply WCS to fits regions if present.
• GUI: add support for user configured button bar.
• CATALOGS: add support for simbad.
• IMEXAMINE: added support for key stroke events.
• Although unstated in their release notes, they are now apparently providing universal binaries instead of PPC and Intel binaries for MacOS X.

I have previously posted notes for integrating upgrades of DS9 into the Scisoft OS X installation and they still work just fine.

The Xquartz folks have updated Xquartz to version 2.2.0.1. Xquartz is an effort to provide a better X11 server for Leopard than Apple provides, being proactive in providing fixes Apple will likely include later. The release notes are long and cover a bunch of updates to various items, including:

• Added informational output when falling through to failsafe startup in X11.app
• Unsetenv(DISPLAY) when falling through to failsafe startup in X11.app
• Exposé now works as expected
• X11 works better with spaces

I suspect the discussion of ‘failsafe’ startups is to provide a more informational failure than what was happening before for people like myself who transitioned from previous MacOS X installations and had been manually forcing the DISPLAY variable to point to :0.0, which is somewhat standard in the Unix world.

I’d recommend grabbing this Xquartz update and applying it if you use Leopard and astronomical software. Its a double-click install. Apple does watch this project (one of the developers is Apple’s X11 developer), and as noted on the Xquartz site:

Apple included some of the work done in this project in their 10.5.2 update and will likely include further changes in possible future updates of 10.5.x. It is suggested that you install the latest XQuartz release after updating to 10.5.2 (and any future 10.5.x or security updates).

In other words, while some of these fixes will likely end up in the official MacOS released by Apple, if you want them now, use Xquartz. Furthermore, since Xquartz does over-write Apple’s default X11 install, this means that if Apple upgrades X11 in a future patch, you could end up with a broken install if you used Xquartz. Personally, I haven’t had a problem, but I suggest you keep the Xquartz package around, and re-install it after any future MacOS X updates.

• Check Hardware Compatibility: My Sonnet Tempo SATA X4P card (which I use to provide an external SATA [eSATA] interface for my RAID of data drives) was incompatible with Leopard and would cause the installer to hang. I finally discovered a firmware upgrade was available that fixed this. This was a stupid rookie mistake. Rule of Thumb: Always check the non-Apple hardware for updates before making a major OS X upgrade.
• Watch out for /home: I had been using a symbolic link from /home to /Users because in my old Unix days, I hardcoded a lot of my software to look for my home directory in /home. Leopard expects /home to be available as mount point for the automount service, so getting with the modern era and not relying on /home to point to /User is required if you adopt Leopard.
• Rebuild Web Server Configuration: One problem I was prepared for is that the web server was updated to Apache2. This in itself was not bad, but the configuration files for Apache (version 1) were stored in /etc/httpd and the new configuration files for Apache2 are in /etc/apache2 and they were NOT migrated. I don’t fault Apple for not migrating the files, but I kicked this around on my laptop quite a bit in order to tweak the configuration files back to something I liked. One thing I immediately did was that this MacOS comes with PHP 5.2.4 preinstalled, but not enabled in Apache2. I enabled it by editting the /etc/apache2/httpd.conf file (which you might have to create) and uncommenting the line with # LoadModule php5_module (by removing the ‘#’ symbol from the beginning of the line). Once that was done, I restarted the Apache2 server and all my PHP code (including this blog) was running again.
• Tweak MySQL for Leopard: The PHP 5.2.4 included with MacOS X is compiled with support for MySQL. This is nice in that you can just download the MySQL package installer and quickly get a LAMP server running. However, it was set up with the MacOS X Server version of MySQL in mind, which means it expects the socket to be in a different location than the vanilla MySQL. This can be solved by either tweaking the MySQL configuration (as outlined in the MySQL section of the blog post at http://remysharp.com/2007/10/27/lamp-in-leopard-osx-105-php5-and-apache-22/ ) or by tweaking the PHP configuration by editing the /etc/php.ini file (if it doesn’t exist, first copy /etc/php.ini.default to /etc/php.ini) and search for the line containing mysqli.default_socket = to read
  

  mysqli.default_socket = /private/tmp/mysql.sock
  

  This solution seemed more straight forward, so I did this.
• Reinstall MacPorts: Since I am aficionado of MacPorts, I reinstalled it and rebuilt all the ports. Some of the issues I had before with MacPorts on Leopard on my MacBook Pro cropped up again on my PowerMac G5, notably
• • gv still needs to be patched as I noted here.
  • sqlite3 still does know about its dependence on nawk.
  • xterm doesn’t install unless you update your X11 installation using the latest version of Xquartz (currently at version 2.1.4).
• Update to latest version of Xquartz: Since I don’t like X11 headaches, I updated to the latest version of Xquartz (currently at version 2.1.4).

So the adventure continues. Back to research, I have invested about 5 hours of my spring break into this upgrade, that is enough for now.

• If you want the Aqua (MacOS X native version, download the appropriate one of the following files. If you want to use the Aqua-native version from IRAF, you will need to access the command-line binary within the SAOImage DS9.app application bundle as “SAOImage\ DS9.app/Contents/MacOS/ds9“.
  • MacOSX 10.4 Tiger Aqua Interface, Universal (PPC and Intel)
  • MacOSX 10.5 Leopard Aqua Interface, Universal (PPC and Intel)
• If you want the X11-based command line driven version
  • Darwin PPC 10.4 Tiger version
  • Darwin Intel 10.4 Tiger version
  • Darwin PPC 10.5 Leopard version
  • Darwin Intel 10.5 Leopard version

More detailed release notes are available here. See my previous post on SAOImage DS9 5.0 to see how it is possible to upgrade the binaries included with SciSoft OSX.

defaults write org.x.X11 app_to_run /usr/bin/true

And you have xterm-free X11 again. Furthermore, this updates xterm as well, so even though I don’t want xterm to launch automatically with X11, I am happy to have it updated.

• I discovered that teTeX failed to build. This appears to be due to an undeclared dependancy on openmotif. So after the failed install, I just did ansudo port clean --work teTeX; sudo port install openmotif teTeXand teTeX installed just fine.
• In attempting to build subversion I discovered that one of the packages subversion needs, sqlite3, fails to install on Leopard. This appears to be due to an undeclared dependancy on nawk (MacPorts Report Ticket #13500). So again, all I had to do was:sudo port clean --work sqlite3; sudo port install nawk subversionand it worked. I should note that a fairly recent version of subversion now comes with Leopard, version 1.4.4 (as opposed to 1.4.5 with MacPorts).
• gv fails to install unless you patch it. This was reported to MacPorts (Bug Report Ticket #13095). [If you check that bug ticket, you will find a new patch-setenv.c file is available there. If you download that file and replace /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c with it, gv will compile and install just fine.]
• osxutils fails almost immediately with a series of errors about conflicting types. Since osxutils did a lot of meta-data manipulation, I am not completely surprised it is broken under Leopard. I have submitted a bug report to MacPorts.
• xterm fails to build. This is irritating because I haven’t had time to confirm is the old xterm Tektronix emulation bug present in the Tiger version of xterm is still present. [This appears to have been cleared up with MacPorts 1.6 if you install Xquartz over the Apple installed X11 server. Doing this is a good idea anyway.]
• wine fails to build (already reported elsewhere). This has already been reported in MacPorts Bug Report Ticket #13488. I wonder if this is related to the possibility being mentioned of Leopard having unreported support for Windows binary execution. [Wine version 0.9.51 DOES compile under Leopard just fine.]
• I can’t build g95 because odcctools fails to compile. This has been reported in MacPorts Bug Report Ticket #13148. [This appears to have been fixed as of January 24, 2008.]
• xephem fails to build because lesstif builds but fails to install. Actually lesstif installed fine once I moved /usr/share/aclocal/ac_find_motif.m4 out of the way. I don’t know if that file was there from my previous install of lesstif. Once lesstif was out of the way, xephem failed to build. Interestingly, MacPorts has version 3.7, I downloaded the source for xephem 3.7.2 from the Clear Sky Institute website, compiled it following the installation instructions without a hitch. I submitted a bug report as MacPorts Bug Report Ticket #13524 (turned out my bug report was a duplicate of MacPorts Bug Report Ticket #13498). This has been fixed, see this post. [This appears to have been fixed as of March 3, 2008.]

• If you really hate the new way X11 uses a custom DISPLAY environmental variable to trigger launchd to launch X11.app, the FAQ contains information on how to disable the launchd trigger and then revert to the Tigerish behavior of manually launching X11.app (HINT: Don’t use /Applications/Utilities/X11.app, use /usr/X11/X11.app instead.
• Information on installing Tiger’s X11 on Leopard. Apparently, it can be done without clobbering Leopard’s X11 install.

Really, very useful, even if you don’t mind the new X11, since it illuminates a bit about how this X11 has bee changed. Oh, and it looks like future X11 updates will be made available at a new MacForge website. I hope a nicer set of packages for X11 is available soon, the only big irritation has been my X11 windows slipping under the menubar!

• I uninstalled Unsanity’s Application Enhancer.
• I removed X11.app from my automatic launch items in the Accounts Preferences Pane Login Items. X11 is extensively refreshed under MacOS 10.5, so you don’t want to autolaunch X11.app any more.
• I upgraded Cisco’s VPN software to the latest version distributed by my campus (you want Cisco VPN Client 4.9.01 (0090)).
• I did a quick search of the various applications I run and looked for “Leopard” upgrades via MacUpdate.
• Finally, I researched the incompatibility of Adobe Acrobat with MacOS X 10.5. I discovered that while the AdobePDF printer driver broken under the new OS, you can use Apple’s built in PDF capability (specifically “Save as PDF-X”) capability to create the PDF, which can then import and edit just fine in Acrobat.

Having done all that, I decided to bite the bullet and install the upgrade. First thing I did was back up the entire internal drive to an external drive (which I had formatted with Disk Utility to make sure it was capable of booting an Intel Mac) using Carbon Copy Cloner. Once the drive was cloned, I ignored the overhyped warnings from MacFixIt.com (who I won’t link to, because they were bought out, they definitely sold out as a source of accurate help) and instead followed the Apple recommended procedure of just doing an upgrade to my previous Tiger installation. I figured if worst came to worse, I would recover from the backup drive (in my mind, the backup is the critical step, not how you choose to upgrade). So approximately 80 minutes later my laptop finished its upgrade and rebooted. Some notes on my initial issues with the new OS.

• The new dock doesn’t bug me as much as some (John Siracusa does the best analysis of the problems with the new Dock in his extensive ArsTechnica review of Leopard), but maybe its because I thought the old dock was broken enough as a launcher that I use QuickSilver instead (which works fine under Leopard).
• Leopard finally handles virtual memory use nicely, removing old files in the /var/vm directory once the memory has been released.
• I don’t like the translucent menubar, but there exist various free applications to get rid of those and the changed dock.
• The new OS nuked all my installed printers. Not a huge deal, but I have to re-install all my printers again. I kind of understand why this might of happened, but it was a pain.
• I had to use Disk Utility to Repair Permissions before my Widgets behaved properly, but now, they actually seem to run better than before (less delay in accessing them).
• I patched IDL to version 6.4.1, seems to work now.
• I knew from Ben Bayer’s (Apple’s X11 guy) postings on the matter that
  

  Biggest architectural change in Leopard for X11: Switched from XFree86 codebase (based on, IIRC, X11R6.8) to X.org codebase (X11R7.2)

  Biggest user-visible change: launchd support for X11. The only situation where you should need to manually start X11.app is if you are only running remote X11 applications.

  The way that this is accomplished is by some slight-of-hand with the $DISPLAY variable — if you look, it should be something like “/tmp/ launch-vbXRyu/:0″. If an X client connects to this, it will actually connect to launchd, which will start Xquartz if needed and pass the client’s socket to the server.

  All of that should be invisible to you; the X client library (libX11.dylib) was modified to support this, and all X11 applications link against this library. “DISPLAY=:0″ would still work if X11.app is already running, but it will not trigger X11 to launch.

  So in other words, we are not supposed to set the shell environmental variable DISPLAY to “:0″. Well, I removed all the times I set it from .tcshrc, .bashrc, .login, etc and it still remained stubbornly set until I remembered trying to get Carbon Emacs working a few months back required my setting environmental variables to my entire session using the ~/.MacOSX/environment.plist file. I opened it, removed the DISPLAY variable from the list of those set for the entire session, and viola. Almost everything worked as advertised except:

• SAOImage DS9 refused to launch because of the non-standard DISPLAY variable. I initially hacked around this by launching an xgterm (from IRAF) and setting the DISPLAY variable in it to “:0″ then launching ds9 within that xgterm session. I did this all in one line via: 

  xgterm -geometry 80x45+40+30 -sb -e 'setenv DISPLAY :0; ds9 -fifo ~/iraf/dev/imt1 -geometry 800x800+600+30 &'

  where I was connecting to my IRAF pipes (thus the ‘fifo’ command line entry). However, I emailed the SAOImage DS9 folks on Thanksgiving and they replied same day to tell me about the new ds9 darwin 5.1beta. That fixed the launch issues with ds9. Apparently getting the Aqua version updated is a bit trickier, so its not done yet.
• I had to uninstall the MacPorts version of xephem, but installing it manually from the source worked just fine.
• I installed the unofficial updates to X11 from Xdarwin (see MacSingularity for some notes). The biggest issues this fixes are (1) the focusing problem of X11 windows behind Aqua windows not always being “focusable” and a (b) bug in X11 that caused several programs using the Gimp Toolkit (aka gtk) to crash. NOTE: These updates have been superceeded by those on the MacForce XQuartz updates site.

All in all, I like the new upgrade, the most useful feature for me being the QuickLook interface and the just generally better networking behavior. I also think there has been a lot of thought put into nips and tucks (such as where the Firewall controls are now, in the “security” prefpane instead of “sharing”). More reports from the field as my usage of IRAF and ds9 under Leopard continues.

This version updated Python to version 2.5.1 and correct some minor issue with the bash version of the irafuser.bash script when running under OSX 10.5 Leopard. Missing GCC runtime fortran libraries are also now included. This version was test under OSX 10.5 and seems to run fine. Note that 10.5 does deal with X11 applications slightly differently. Once the Setup.bash script has been source[d], you should add the following line to your .bash_profile: export DISPLAY=127.0.0.1:0.0 This will enable all Scisoft X11 applications to start from Terminal.app

• I did notice this new version of Scisoft OSX doesn’t appear to link its IRAF install with the rvsao IRAF package (used for radial velocity computations). Doesn’t matter to me to much since I compiled the newer version and linked to it, but it is funny they include the rvsao package at /scisoft/all/packages/iraf/extern/rvsao but don’t link to it in the $hlib/extern.pkg file, which I do believe they did in the older versions.
• I may not have noticed this earlier, but in the libraries directory /scisoft/i386/lib, some of the symbolic links are broken. Specifically:
  • All the items in this directory linking to the OpenMotif library items are not linked, it appears /scisoft/i386/Packages/OpenMotif-2.3.0/lib doesn’t exist. However, /scisoft/i386/Packages/OpenMotif-2.3.0/lib.org does. So I symbolically linked lib to lib.org via:

    cd /scisoft/i386/Packages/OpenMotif-2.3.0/
    ln -s lib.org/ lib

    And now all the links to the OpenMotif libraries within /scisoft/i386/lib work.
  • The CFITSIO library is mis-linked to an older version which no longer is installed. So I needed to:

    cd /scisoft/i386/lib/
    rm libcfitsio.a
    ln -s ../Packages/cfitsio-3.040/lib/libcfitsio.a libcfitsio.a

    and the CFITSIO library was properly linked again.
  • libpng.so was apparently not compiled within /scisoft/i386/Packages/libpng-1.2.10/lib, so there is no quick fix for that broken link.
  • I removed a link to python2.4 in /scisoft/i386/lib and replaced it with a link to python 2.5:

    cd /scisoft/i386/lib/
    rm python2.4
    ln -s ../Packages/pygtk-2.8.6/lib/python2.5/ python2.5

• All the CFITSIO headers in /scisoft/i386/include/ are linking to an older version (3.006) instead of the current installed version (3.040). Fixed via:
• There are symbolic links in the /scisoft/i386/bin directory to a variety of executables from the sm plotting package which doesn’t appear to have been installed as part of the Scisoft OSX distribution.
• Not really a bug, but the version of SAOImage DS9 is version 4.1.3 and not the current version 5.0.0. Of course, given the long history of dangerous version X.0.0 software, this maybe safer that way.

• MacOSX 10.4.x (Universal)
• Darwin PPC 10.4.x
• Darwin Intel

• MacOSX Aqua Support: DS9 has been ported to MacOSX Aqua and is an universal application which no longer requires X11.
• Compressed FITS Support: DS9 supports compressed FITS images using RICE compression.
• Mask Support: DS9 supports overlay masks. A mask is defined as a valid FITS image, in which a non zero value indicates that the selected mask color is to be displayed instead of the data value color.
• SkyView Support: DS9 provides support for HEASARC’s image cutout service, SkyView. This site provides image cutout service for a number of image surveys, including SDSS.
• Multi-Language Support: DS9 provides multi-language support. By default, the language used for menus and dialog boxes is based on the value of the operating system locale variable. The user may override the default value by selecting the desired language in the preferences or by the -language command line option.
• Preferences: Preferences are automatically saved when a user changes an option. Selecting the saving preferences menu item is no longer needed.

1. Decompress the command line version of ds9 via the terminal using tar xzvf ds9.darwinppc.5.0.tar.gz (PPC version) or tar xzvf ds9.darwinintel.5.0.tar.gz (Intel version). When the decompression is done, all you have is an executable called ds9.
2. Next, from the terminal, go to the /scisoft/bin directory (on PPC) or /scisoft/i386/bin/ directory (on Intel) and rename the old ds9 executable to something like ds9_old (using something like mv ds9 ds9_old).
3. Copy your newly decompressed ds9 executable into the SciSoft OSX binary directory. I should note the command line version of ds9 still requires X11.

xterm -e callhectospec hcal comp.ms

 Error in message to server, line 6: send: could not find object gterm
    while executing
"send gterm setGterm"
xgterm Xt error: Shell widget gterm-iraf has zero width and/or height

else if (envget("TERM") == "xterm") {
 stty xterm
}

else if (envget("TERM") == "xterm") {
  stty xgterm
}

I found that this problem had been reported on Apple’s X11-users mailing list here, but no solution had been determined. I spent a bit of time looking for “missing” fonts as suggested in the posting, then decided this had to be a problem with the xterm executable and tried my previous solution of installing the program from MacPorts via

sudo port install xterm

sudo mv /usr/X11R6/bin/xterm /usr/X11R6/bin/xterm.disabled
sudo ln -s /opt/local/bin/xterm /usr/X11R6/bin/xterm