Urania

[I have made an updated version of these instructions for adding the SSH2 PHP extension to the pre-installed PHP 5.3.0 installation on MacOS 10.6 available here.]

I just upgraded the software on this blog to WordPress 2.7. The major new feature I am interested in is automatic upgrading, which could prove quite a time saver. Unfortunately, this automatic upgrading uses only FTP (which is totally insecure) or FTPS (which requires me to set up an SSL certificate).

I noticed that the WordPress code had ssh2 support built-in, so all I need to is activate SSH2 support in the MacPorts installed PHP and I should be able to use SFTP in WordPress to handle the upgrades. I poked around and found this posting outlining the process for adding ssh2 support to Ubuntu. It guided me in developing this list of hints:

1. Start by installing libssh2 via MacPorts using the command:
   

   sudo port install libssh2
   

2. Once it is activated, link the libssh and PHP together using the PECL module SSH2. Unfortunately, directly installing the module with PECL under MacPorts is troublesome, so I just used PECL to download the module.
   

   pecl download ssh2
   

   triggered the following error (since ssh2 is apparently beta),
   

   Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.0, stability "beta", use "channel://pecl.php.net/ssh2-0.11.0" to install
   Cannot initialize 'ssh2', invalid or missing package file
   Package "ssh2" is not valid
   download failed
   

   so I used
   

   pecl download channel://pecl.php.net/ssh2-0.11.0
   

   as suggested and was able to download the PHP library for SSH2. Once the download was complete, I started on the standard compilation sequence for a PHP library
   

   tar xzvf ssh2-0.11.0.tgz
   cd ssh2-0.11.0
   phpize
   ./configure --with-ssh2=/opt/local
   make
   sudo make install
   

   The final command informed me the ssh2.so library was placed in /opt/local/lib/php/extensions/no-debug-non-zts-20060613/
3. Now you need to make sure PHP loads the new module, so we open the PHP configuration file /opt/local/etc/php.ini and edit the extension_dir line to point the extension directory above:
   

   extension_dir = "/opt/local/lib/php/extensions/no-debug-non-zts-20060613/"
   

   and then add the following line to the end of the section on “Dynamic Extensions”:
   

   extension=ssh2.so
   

   If you edited everything properly, a simple php -v from the command line should NOT trigger any errors.
4. Finally, I restart the apache2 server so that the reconfigured PHP is loaded using
   

   sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart
   

   At this point, I checked (via the phpinfo(); command to see if the web server was supporting SSH. Near the bottom of the phpinfo(); listing is a listed of “Registered PHP Streams”. As noted here, it should incude “ssh2.shell”, “ssh2.exec”, “ssh2.tunnel”, “ssh2.scp”, and “ssh2.sftp”. If it does, you have enabled SSH support for Apache2 driven PHP pages under MacPorts.
5. If you are doing this to get WordPress 2.7 automatic installation working, you will notice now when the automatic installation dialog box pops up, in addition to ftp and ftps, you now have an ssh option.
   

6. Now that I got this working, I’ll just have to keep an eye out for any future MacPort updates to PHP and make sure they don’t overwrite the

   /opt/local/etc/php.ini

   file or the extensions directory where I installed ssh2.

As I mentioned in my blog post earlier today, I have been having issues using the JpGraph graphing package for PHP with Apple’s built-in PHP under MacOS 10.5. It appears Apple’s security efforts have “secured” PHP to the point where JpGraph (and PDFLib) will not function properly under the built-in PHP. [Note added after initial post: The rest of this post describes installing Apache 2 and PHP under MacPorts and configuring it to be similar to Apple's built-in servers.  This appeared to solve my problems, but then my Mac locked-up [possibly related] and on reboot, the new MacPorts-based PHP installation started throwing the same errors as Apple’s built-in PHP.  More information on this problem is located in my newer post on the issue.]

I had tried to alleviate the solution previously by compiling a version of PHP myself that would be compatible with Apple’s built-in Apache 2 web server. This turned out to be difficult because Apple’s Apache 2 web server is a “universal” binary, meaning it contains four seperate binaries (for 32-bit PowerPC, 64-bit PowerPC, 32-bit Intel, and 64-bit Intel processors). As such I needed to compile a “universal” PHP binary and since I wanted MySQL support, I needed a “universal” MySQL binary. This turned out to be too much for this astronomer, so I gave up on making a new PHP that was compatible with Apple’s built-in web server.

So I bit the bullet and after reviewing the options, I decided to install Apache 2 and PHP under MacPorts. If you have read the other posts on this site, you know I really like MacPorts as the quick and dirty way to get many things running on the Mac. However, despite this, I don’t like installing MacPorts for items Apple provides, instead generally preferring to use Apple’s “pre-installed” versions. Furthermore, there have been a lot of complaints on the MacPorts mailing lists about various issues compiling PHP5. So I wasn’t as quick to jump onto the MacPorts bandwagon for PHP as I am for other problems. However, since I am familiar with MacPorts, I decided this was the best approach for getting my online Finder Charts to work again.

The process proved reasonably painless, especially since I was able to review this blog post, where he lays out pretty much what to do. However, since I wanted to achieve maximum compatibility with Apple’s built-in web server and PHP setup, in case I wanted to switch back, I ended up doing things a little bit differently, so I am outlining my steps here.

1. I started by installing the MacPorts version of Apache 2 using the command sudo port install apache2
2. Next, I had to create the Apache 2 configuration files and edit them. I started by copying the sample configuration file

   sudo cp /opt/local/apache2/conf/httpd.conf.sample /opt/local/apache2/conf/httpd.conf

   and then editing /opt/local/apache2/conf/httpd.conf with my favorite text editor to change the configuration to match the that of the built-in Apache 2 server a closely as possible. My matching the configuration of Apple’s built-in server, I can switch back to it with relative ease if I choose to do so later. So I made the following changes to /opt/local/apache2/conf/httpd.conf:
3. 1. I changed DocumentRoot to "/Library/WebServer/Documents" as is the case with Apple’s built-in server.
   2. To allow index.php files to be used as directory indexes, I changed

      DirectoryIndex index.html

      to

      DirectoryIndex index.html index.php

      (I don’t know why this isn’t necessary with Apple’s built-in server, but it was necessary here).
   3. I changed to and in that directory block of code, I added “MultiViews” to the Options line.
   4. I changed to in order to prevent the listing of .DS_Store files in directory listings by the web server.
   5. Before the ErrorLog block of code in this file, I added the following lines copied from Apple’s default Apache 2 configuration:

      #
      # Apple specific filesystem protection.
      #
      
      Order allow,deny
      Deny from all
      Satisfy All
      
      Order allow,deny
      Deny from all
      Satisfy All

   6. I changed ErrorLog to "/private/var/log/apache2/error_log"
   7. I changed CustomLog to "/private/var/log/apache2/access_log common"
   8. To match Apple’s Apache 2 server configuration, I changed ScriptAliasMatch to

      ^/cgi-bin/((?!(?i:webobjects)).*$) "/Library/WebServer/CGI-Executables/$1"

   9. I changed back to
   10. I added the following Handles to the “To use CGI Scripts” block of code:

       AddHandler imap-file .map
       AddHandler cgi-script .cgi
       AddHandler cgi-script .pl

   11. I uncommended the following lines near the end of the file:

   12. [OPTIONAL] Because I use the WebDAV server on my server, I also uncommented
   13. Finally, I added the following lines to the end of the file in order to allow loading of the PHP5 configuration

4. Next, I editted /opt/local/apache2/conf/extra/httpd-userdir.conf and added the following to the end of the file

   #
   # Users might not be in /Users/*/Sites, so use user-specific config files.
   #
   Include /private/etc/apache2/users/*.conf

5. [OPTIONAL] Since I use the built-in WebDAV server, I made a backup of the WebDAV configuration, then copied the Default MacOS X one, because I have spent a lot of time tweaking it previously and I didn’t want to have to reinvent the wheel. 

   sudo cp /opt/local/apache2/conf/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf.orig
   sudo cp /etc/apache2/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf

6. I had to install PHP5 with MacPorts. Since I wanted to add support for Apache 2 and MySQL, I entered the command: sudo port install php5 +apache2 +mysql5 +pear which has the side effect of installing MacPorts version of MySQL as well. Assuming everything goes well, after a few minutes (this takes longer than the apache2 install earlier), the installation will end. At this point we can configure the Apache 2 mod_php module by typing: 

   cd /opt/local/apache2/modules/opt/local/apache2/bin/apxs -a -e -n "php5" libphp5.so

7. [OPTIONAL] Next, I had to create the PHP5 configuration file and edit it. I started by copying the sample configuration file sudo cp /opt/local/etc/php.ini-dist /opt/local/etc/php.ini and then editing /opt/local/etc/php.ini to make it match /etc/php.ini (which Apple’s built-in PHP uses). All the changes I made were optional and related to the specifics of my setup. The only interesting one was that I wanted to continue to use the MySQL.com binary distribution of MySQL server, so I set the following variables in /opt/local/etc/php.ini: 
   1. mysql.default_port from “” to 3306
   2. mysql.default_socket from “” to /private/tmp/mysql.sock
   3. mysqli.default_socket from “” to /private/tmp/mysql.sock
8. I deactivated Apple’s built-in web server by turning off Web Sharing in the Sharing.prefPane.
9. Finally, I launched the new webserver (and set it up for launching on boot-up in the future) by typing

   sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

   If this breaks anything, I can reverse the process by typing

   sudo launchctl unload -w /Library/LaunchDaemons/org.macports.apache2.plist

10. [OPTIONAL] I like the ability to turn on and off the Apache webserver from the command line using apachectl. I can “emulate” this in /bin/tcsh (my prefered shell) by adding the following command to the ~/.tcshrc file:

    alias apache2ctl 'sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper'

    After which I can bring down the server by typing apache2ctl stop and restart it by typing apache2ctl start.

I am having an interesting problem. In my last post, I noted that on some Macs with Leopard installed, deactivating the lines calling /usr/libexec/path_helper in the /etc/profile file fixed LaTeXit hanging at launch. A bit more investigation by Antonio Molins (posted in the comments to that post) revealed it was possible to add an ASCII file in the /etc/paths.d directory. We could create a file called /etc/paths.d/macports containing the only the line

/opt/local/bin

and it should automatically add everything in macports to most user’s PATH variables. However, when I tried this, all my calls to /usr/libexec/path_helper -s always locked up the command.

Some further investigation revealed new user accounts on my Macs didn’t have this problem. I surmised that since I was setting up the PATH and MANPATH variables in my environment at login, that this could apparently lock up path_helper. Since I use tcsh by default (instead of Apple’s default bash shell), I issued the following two commands from the command line

unsetenv PATH
unsetenv MANPATH 

and sure enough path_helper worked without an issue. So something is buggy in path_helper, or at least hypersensitive to pre-existing PATH environmental variables. I’ll have to investigate this more later. One thing I did discover is that

/usr/libexec/path_helper -c 

will produce the commands to set up tcsh’s environment.

/usr/libexec/path_helper -s 

returns those for the default bash shell.

The nice thing about MacOS X 10.5 Leopard is that it comes with PHP 5.2.4 pre-installed. Unfortunately one of the features Apple choose not to compile in was support for the GD graphics library, which I use extensively. Furthermore compiling in new features has proven to be somewhat troublesome. When I tried to configure PHP 5.2.5 on my Leopard box which the following commands (a variant of the configure command I would issue under Tiger with no complaints):

The result was a failed configure due to an error in mysql configuration. I pinned this down to a request for a library at /usr/local/mysql/lib/mysql/libmysqlclient.15.dylib which is actually located one directory up. This can be fixed via the command line using:

cd /usr/local/mysql/lib
mkdir mysql
cp libmysqlclient.15.dylib mysql/libmysqlclient.15.dylib

Then the ./configure worked just fine. Unfortunately, when I did a

make
make test

to compile the PHP and test it, there was no happiness. There were over 50 errors, some of them major. Crud. This is just the setup. See, all I needed was GD graphics library support in PHP for my website. Well, after googling for some time for some master hacker’s notes on getting PHP 5.2.5 to compile on Leopard, I discovered a fellow named Hill Pei had hacked GD support into the Leopard PHP without too much effort. His method simply requires some comfort with the command line and editing text files. In five minutes, I had GD support with Leopard’s built-in PHP. Excellent! [Despite a report in the comments to the contrary. This still appears to be necessary if you apply Security Update 2008-002, which installs PHP version 5.2.5. In which case, you should grab the php 5.2.5 code and work from there. I can confirm Hill Pei's instructions do work after Security Update 20008-002 if you grab the PHP-5.2.5 code instead of 5.2.4 as he suggests.]

About 6 weeks ago I posted about the various ports that failed to install in my first attempts at getting “my standard suite” of ports installed under MacPorts on Leopard. My standard suite until Tiger involved issuing the following command:

sudo port install aquaterm chmdump contacts coreutils curl file findutils g95 ghostscript gv ImageMagick ksh93 latex2rtf lynx macutil osxutils plotutils subversion teTeX tidy vim wget wine xterm xephem

Since then MacPorts has released version 1.6 and the various porters have been hacking at the various problems. I can now report that of the ports I reported failed to install:

• xterm, wine, and g95 all now install without any issues.
• teTeX can be installed, there was a bad dependency in the portfile. You just needed to install openmotif first manually. I don’t know if the bad dependency is still there, it may have been resolved.
• subversion can be installed, it also had a bad dependency. You just needed to install nawk first. Again, I don’t know if the bad dependency is still there, it may have been resolved.
• gv can be installed if you apply a patch. If you check that bug ticket on gv (you need to get a free MacOSForge account), 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.

This leaves just two of my standard suite of packages that don’t compile right in Leopard, osxutils (See this post) and xephem (See this post). And xephem installs just fine manually if you download the source code.

I decided I should clean up my laptop’s left over digital crap, so I went through my /usr/local directories cleaning out ancient libraries installed two OSes ago (after making a backup first). I decided I would try reinstalling MacPorts under Leopard, if only to build it clean and remove the old source code siting around from various revisions to the packages over time.First, I installed MacPorts from the disk image for Leopard. Then I attempted to install my usual suspects: sudo port install aquaterm chmdump contacts coreutils curl file findutils g95 ghostscript gv ImageMagick ksh93 latex2rtf lynx macutil osxutils plotutils subversion teTeX tidy vim wget wine xterm xephem Long story short, almost everything works but there were a few key packages that failed to build under MacOS X 10.5.1. This also reminded me that when a package fails to build, you should “port clean” the package (see examples below) before attempting to rebuild it:

• 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.]

I’m actually surprised the number of packages that failed to compile seems pretty small.

Like many Macintosh users, the first few months of using MacOS X I wasn’t even aware of what the Keychain really was. After a while, you realize just what a cool little piece of security it is. It ensures many MacOS X programs can securely store passwords and other information without the programmer having to be a great cryptographic genius.

One of my favorite programs which exploits this is 1Passwd. 1Passwd stores all your web form passwords (and any other data you care to secure, like credit card numbers or software serial numbers) in a Keychain, so the cryptography is managed by Apple’s Keychain. Recently, on my iMac at home, 1Passwd started locking up whenever it tried to access it’s keychain. Specifically, I have updated 1Passwd so it presented me with a dialog to allow the updated version access to the Keychain. When I clicked continue, the dreaded rainbox beachball of doom showed up and would not go away. From that point on, logins to the machine failed and most Apps using the keychain were unable to use the keychain.

I checked the system usage from the command line

top -u -s 5

and discovered a program called securityd was eating up CPU cycles and RAM. I called up the manual page on securityd via the command line:

man securityd

and discovered:

securityd maintains security contexts and arbitrates cryptographic operations and Security Authorizations. Access to keychain items is routed through securityd to enforce access controls and to keep private keys out of user process address space. Authorization calls also communicate with securityd to enforce rules contained in the /etc/authorization database. All user interaction with securityd is mediated through the Security Agent.

So by locking up securityd, I was messing up all the cryptographic operations that ran through it. Great. I figured there had to be a corrupted file on my computer that was mucking up the works, but where. My first thought was a corrupted keychain file, so I checked out my keychains using the “Keychain First Aid” item in the Keychain Access (in /Applications/Utilities) [shown in the figure below].

The files all checked out as intact, so that wasn’t it. Something was corrupted on my computer, but what.

Just a Google search on “securityd” later, I found the solution on the Unsanity programmers blog in an article titled “Fix for securityd hogging RAM when reauthorizing apps’ Keychain access“. In a nutshell, the corrupted file is a cryptographic database at /var/db/CodeEquivalenceDatabase. In order to fix this problem they suggest:

just open the Terminal (/Applications/Utilities/Terminal) and type:

sudo mv /var/db/CodeEquivalenceDatabase /var/db/CodeEquivalenceDatabase.old

Upon rebooting, God should be in His Heaven and all should be well with the keychain.

And I verified this worked to fix my iMac and all the Keychain apps are happy again. Excellent!

Update: I have updated this blog entry to reflect some updated information from Nor Pirzkal regarding the best way to fix this glitch.  This problem has been fixed in Scisoft OSX MacIntel version (2007.9.1).

During my adventures compiling the hectospec-related IRAF packages, I was using Scisoft OSX and discovered there were a couple of issues with the symbolic links for the mkpkg command necessary for compiling new IRAF packages.

• In the Scisoft OSX PPC Beta (2006.11.1b) mkpkg appears to be mis-linked, so it can’t be executed. So I did the following in the terminal:

  cd /scisoft/binsudo rm mkpkgsudo ln -s ../iraf/iraf/unix/bin.macosx/mkpkg.e mkpkg

• In the Scisoft OSX MacIntel version (2007.1.1) and Scisoft OSX MacIntel version (2007.7.1), there are some missing symbolic links to mkpkg and xc in the directory for MacIntel binaries.  As a result, both mkpkg and xc were instead pointing to PowerPC binaries. I fixed this as follows (again, from the command line):

  cd /scisoft/i386/bin/sudo ln -s /scisoft/all/packages/iraf/iraf/unix/bin.macintel/mkpkg.e mkpkgsudo ln -s /scisoft/all/packages/iraf/iraf/unix/bin.macintel/xc.e xc

  This mis-linking certainly didn’t help getting things to compile under MacIntel, since IRAF was attempting to compile MacIntel code using PowerPC versions of mkpkg and xc.

Thanks for Nor Pirzkal for giving me some feedback on fixing this problem.  He tells me he has made the appropriate changes so that the next version of Scisoft OSX will not have this  issue.By the way, my complaint here should in no way be construed as a critique of the efforts of Francesco Pierfedericki and Nor Pirzkal in putting together Scisoft OSX. They have done a great deal of work to put together an awesome package. For two people to track over 2 GB of software and not expect some glitches is unrealistic. And I for one am extremely grateful that his efforts have saved me a lot of time.

On the Mac, X11 is part of the optional install. To quote Apple’s X11 Developer Note on Installing and Configuring X11 Applications on MacOS X on the Mac:

X11 is available as an optional install on the […] Mac OS X v10.4 Tiger install disks. Run the Installer, select the X11 option, and follow the instructions.

Once you have installed X11, you can launch X11 by going to the /Applications/Utilities/ directory and double clicking X11.app (this may display in the Finder as “X11” depending on your settings for showing File Extensions). And now some hints for better X11 usage (these are not in any particular order):

1. If you are an astronomer, you probably use a lot of programs like IRAF, AIPS, or XEphemthat need X11. So it probably makes a lot of sense to set it up so that X11 automatically launches when you login. To do this:
   • Open your “Accounts” preference pane in the System Preferences.
   • Choose the “Login Items” tab within the Accounts pane and then you will see a list of login items (possibly empty).
   • You can add X11 to this list by pressing “+” at the bottom of the list of login items. This will bring up a dialog to select the file, work your way to the /Applications/Utilities/ directory and select X11 and you are done. NOTE: On MacOS X Tiger, there is no ability to control the order in which items are launched, so its position on the list is somewhat meaningless.
2. There are many hidden preferences in X11 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 X11 preferences, type:
   

   defaults read com.apple.x11
   

   In addition to “reading” the preferences, you can write to them. From the command line you can type:
   • defaults write com.apple.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 com.apple.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 com.apple.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. On the Mac X11 launches the quartz-wm Window Manager and while you can run any other window manager of your choosing, I like it. However, if you modify your ~/.xinitrc file, you can control which window manager is launched. 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. You can launch an X11 application from the Terminal directly if you have set the DISPLAY environmental variable properly or by using the open-x11 command, for example:
   

   xclock &
   

   will launch the xclock in the background if I have already set the >DISPLAY variable.

   open-x11 /usr/X11R6/bin/xclock &
   

   will do the same without DISPLAY being set.

5. BIG LAPTOP USER HINT: Because X11 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.
6. 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<br />X11DisplayOffset 10<br />X11UseLocalhost yes
   

7. The X11 Dock icon on the Mac can let you select specific X11 windows when X11 apps are running.
8. Tektronix emulation in xterm is broken under MacOS X (at least in Tiger). To get it functional again, see my previous posting about this.

And that is it for the hints for now.

After several days of trying to get the Hectospec folk’s data reduction packages working on my Mac, I realized one of the major problems was that ksh on the Macintosh had a major problem. Normally, in ksh (korn shell), you can set up a loop to read through a list of objects via a read command within a while..do loop. For example, to echo a list of files your ksh script could contain

#!/bin/ksh
ls -1 . | while read fname; do
  echo $fname
done

where the read filename bit reads a line from the piped input and assigns the first block of text (before a space) to the variable fname. Try this script on MacOS X and it produces no output. “read” fails. This has been documented elsewhere at least twice that I have been able to find with Google, here and here. So clearly, there is a serious bug in the installed version of ksh on MacOS X. I fixed it by updating my ksh using MacPorts, a simple

sudo port install ksh93

followed by changes in the Hectospec scripts to point to/opt/local/bin/ksh instead of /bin/ksh and I was done.

Maple is a nice symbolic mathematics pages from the Canadians at Maplesoft. Our school as a site license which is an awesome deal as students can buy personal copies for much less than the price of a typical textbook. As such, our students can be expected to use the software for their classes. One of the really slick bits on the Mac is you can run Maple from the command line (useful when I need to compute an integral quickly).

I am running Maple 11, so I just placed the following alias in my ~/.tcshrc file (I run tcsh by default because I am old school and dislike bash):

alias maple "/Library/Frameworks/Maple.framework/Versions/11/bin/maple"

If you are running the PPC version of SciSoft, it messes around with some environmental variables, breaking this trick, you can instead use

alias maple "unsetenv DYLD_FALLBACK_LIBRARY_PATH; /Library/Frameworks/Maple.framework/Versions/11/bin/maple; setenv DYLD_FALLBACK_LIBRARY_PATH /scisoft/lib"

If you are using Maple 10, substitute a “10″ where you see an “11″ above.

NOTE: I will assume you have installed teTeX (a modern LaTeX package) in one of a variety of ways. Personally I recommend either Fink or MacPorts. However you can get a lot more information about this by visiting the “Getting Started” page at the Mac TeX website.

AASTeX is used to help typeset publications for all the major astronomical journals (at least in the US). You have two fundamental options for installing AASTeX on the Mac:

1. Single User Install: The easiest way is to download AASTeX (the version for LaTeX 2e) from http://www.journals.uchicago.edu/AAS/AASTeX/ and then just copy the aastex.cls file to whatever directory contains your latex source code for your paper. It should work just fine if you do that.
2. Global Install: If you want to make the AASTeX class file available to all your Mac users, you need to install it globally where the laTeX installation keeps its latex libraries. The easiest way to do this is to first determine where teTeX keeps its laTeX libraries (referred to as TEXMFMAIN). One simple way to do this is to type the following from the command line
   

   texconfig conf | grep TEXMFMAIN

   
   Once you have found that directory, edit the Makefile that comes with AASTeX so that INSTALLDIR equals that directory and fire off a
   

   sudo make install

   
   Once you have installed AASTeX, run
   

   sudo texconfig rehash

   
   And you should be set.

P.S. – Most teTeX installs come set to European paper sizes. If you want US Letter size, just run the configuration program and set US Letter size pages as the default using:

sudo texconfig

Its text menu driven and pretty straight forward.