The 'open' command from Terminal command line is like a double-click on an object, and sometimes it is much faster than using the Finder, at least for me. I've been a CLI user for decades and while I appreciate the GUI, many times it is too slow. Often the Finder requires far too many operations to get to the file or folder that I need to work on. Why 'Find' a location in the directory tree when I already know where it is?

Read the rest of this article for an interesting write-up on using the command line to improve the efficiency of the OS X GUI.

I think I finally figured out how to use something like links or aliases in an ftp server for anonymous logins.

First up there's a link on enabling anonymous ftp here on macosxhints.com. If you haven't set up an anonymous ftp server yet, I suggest you read and follow those instructions. Furthermore I suggest you set up a FireWall for security reasons.

The problem is that for security reasons, ftp servers do not allow anonymous users to access anything outside the dedicated ftp directory e.g. /Users/ftp. Therefore, neither soft links done by "ln -s file1" nor aliases to files and especially directories outside the ftp directory will work. Hard links done by "ln file1" will work, though, but they are hardly a replacement because you can't do hard links on directories therefore you'd have to link every single file and this may take a while if e.g. you want to serve up your collection of 23,156 MP3 songs in 2,167 directories :-)

The solution is to trick the ftp server into believing that linked files are real files within the /Users/ftp directory. And that can be done by NFS, Network File System, which is also built into Mac OS X.

Read the rest of this article if you'd like a detailed how-to on setting up NFS and sharing multiple directories via FTP.

[Editor's note: I have not done this on my machine. You should be comfortable with the command line before proceeding. If you're not UNIX-savvy and have only occasional needs, check out Ben Spink's Java-based FTP server Crush.]

Hard drive thrashing and you don't know why? Just curious to see what apps are doing to your hard disk behind your back? Give yourself a wide terminal window and type:

sudo fs_usage

You will get a running display of file system access. As always, "man fs_usage" for more info. This and other tools can be found in /usr/bin.

/. is running a slashback ditty about users having trouble with XDarwin under 10.1. I've got it running fine, here's the gotchas.

Firstly, the general installation overview is summarized in a previous MacOSXHints article, so I won't rehash that here. Once you have xf86 4.1 and XDarwin 1.0a3 installed, minor tweakage is needed for great justice. The problem is that the xinit binary is not in the default shell's path, I fixed that at the user level by creating a .cshrc file (which belongs in your home directory: cd ~ to get there). Here's how: Obviously, use vi or whatever to create the file. For the contents, first issue this command to an open shell window:

echo $PATH

This will give you your current (and likely your default) path. Highlight the path and copy it. In your newly created .cshrc file, you need a line saying:

setenv PATH [paste default $path here]:/usr/X11R6/bin:/usr/local/X11/bin

You may also want to add a line for the man pages; the procedure is the same, but use echo $MANPATH for the default, and:

sentenv MANPATH [paste default $manpath here]:/usr/X11R6/man

(Note-it's hard to see due to the formatting, but between the copy/paste stuff and the new lines is a :, make sure it gets there)

After doing the above, I have a working XDarwin under 10.1. While you're hacking your .cshrc file, you may also want to check out another previous MacOSXHints article on ssh-see the first comment for another tasty usage of the .cshrc file... Also note-I'm sure this can be done at the system level, but don't know offhand where it's done, if anybody knows by all means post it on this thread...

Apple has included PHP 4.06 in OS X 10.1. Stepwise has the instructions necessary to make it functional - just uncomment the following four lines in /etc/httpd/httpd.conf:

LoadModule php4_module        libexec/httpd/libphp4.so
AddModule mod_php4.c
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Stepwise has a nice page of info on changes in 10.1 that covers this and other aspects of the upgrade; give it a visit to see some things to keep in mind as you upgrade.

If you installed your own version of SSH (particulary using instructions from Stepwise) under 10.0.4, you may get an error such as this

OpenSSL version mismatch. Built against 90581f, you have 90602f

when you try to use SSH in 10.1. Stepwise has the solution in the form of a "SSHCleanup.command" shell script; click here to view the script's contents. To use it, copy and paste the text into a new text file and name it "ssh-cleanup.command". Save the file (in pure text format), then open a terminal and type sudo sh ssh-cleanup.command in the directory where you saved the file.

This should fix your SSH problems in 10.1. Thanks to Peter H. for finding both the error and the solution.

Some users have reported problems when they try to enable Web Sharing (which launches the Apache web server) in OS X 10.1. The issue is apparently related to the "mod_hfs_apple" file, which Apple created to work around an HFS-related security hole.

You can either disable mod_hfs until Apple fixes this (not recommended due to the security issues) or patch it, thanks to Stepwise. The disabling instructions are in the remainder of this article. To patch it, simply do the following in a terminal session:

cd /tmp
curl -O http://graphics.stepwise.com/patches/mod_hfs_apple.tgz
sudo tar -xzf  mod_hfs_apple.tgz -C /

Make sure you stop Apache and restart it after the change. These commands install the new mod_hfs module from the Developer Tools, which are not yet publicly released.

Apple has removed 'wget' from OS X 10.1, apparently due to GPL (the Gnu Public License) issues. This is a most handy command, as it can download files and web pages from the command line over an SSH connection. I use it regularly to start large downloads at home while I'm at work.

To replace 'wget', you can download it from one of the GNU software mirror sites (it's in the 'wget' directory) and compile it yourself (this will require the Developer Tools to be installed). Once you've downloaded and expanded the archive, simply "cd" to that directory and type "sudo make install" to install the new 'wget'.

Once I've received my Dev Tools CD, I'll make a pre-compiled version available on my mac.com home page.

Readers will appreciate that the 'renice' command [Editor: This command changes the default CPU allocation of currently running tasks] appears to be fully functional in 10.1. I started two instances of the distributed.net client and then used 'top' to examine the CPU usage of each. Read the rest of the article if you'd like to see the results (and they're notably changed from what would be seen under 10.0.4!).

For a while now I've been hoping someone would come out with a GUI-based SSH terminal app for OSX. MacSSH and NiftyTerm actually seem to work just fine under Classic, but I was hoping for a native solution to turn up. Naturally one can always open shell and start the default OpenSSH client. It's slightly cumbersome but I guess if you're doing remote terminal logins in the first place, you're not exactly adverse to extra typing. =-) Additionally, someone here posted a great hint about making Finder-launchable SSH shell login scripts.

Anyway, there's been a Java-based SSH app out there called Mindterm. I never thought to give it a try until now. The company's webpage states that it's free for non-commercial use and while they don't explicitly say so, I found it runs fine under Mac OSX.

The only hitch is that after you uncompress the archive, you have to launch it from the shell with:

java -jar mindterm.jar

If someone who knows more about Java could figure out a way to launch it from the Finder, that would be great. (The Applet Launcher didn't seem to work)

The program is a bit flaky here and there (the built-in SFTP client stalled whenever I attempted a transfer) but it is useable and seems support the full range of ciphers and authentications usually associated with SSH1&2.