Weird problems in NEXTSTEP (and workarounds)

So NEXTSTEP has some quirks - especially if you're used to a more modern UNIX system. I've encountered lots of problems in my dealings with the system and have come up with a variety of workarounds for most of them. Here's a list:

• mkdir -p doesn't work.

  Right. That's because /bin/mkdir doesn't accept that option. However, there is a /bin/mkdirs that does what you want. My solution was to move /bin/mkdir to /bin/mkdir.bin and create a /bin/mkdir wrapper script that calls the correct one.

• ./configure scripts fail because uname isn't found.

  There's no uname on NEXTSTEP. I wrote a /usr/local/bin/uname script which accepts all the options of the GNU one and spits out whatever information those scripts expect to find.

• I can't delete directories!

  If you supply rm a directory name and include the trailing slash on it (for example: rm bin/), it will complain that it can't remove the directory. The fix is to simply leave off the trailing slash.

• I can't mv across filesystems!

  I know. Linux lets you do this and I've gotten used to it. So now when I try to do it on NEXTSTEP, I can't. The workaround is simply copy the directory first, then delete the original copy.

• tar doesn't accept the -z option.

  That's a GNU tar option. Luckily, NEXTSTEP includes the GNU tar as gnutar. Try that, or build your own. (Of course, there's always gzip -dc foo.tar.gz | tar -xf - )

• strip kills symlinks.

  If you try to strip a symlink, strip will dereference the symlink and replace it with the name of the program it points to, but retain the same name. Allow me an example. vimdiff is a symlink to vim. If you strip vimdiff, it will replace vimdiff with a copy of the vim binary but still name if vimdiff. The solution is to strip first, then symlink. Or something.

• Compiling Objective-C dies with some message about the -lang-objc flag.

  Strange that there should be problems compiling Objective-C on the NeXT, huh? The problem is that it should be using the -ObjC compiler flag instead of -lang-objc. The solution is to move /lib/m68k/cc1obj to /lib/m68k/cc1obj.bin. Then write a new cc1obj wrapper script which examines all arguments passed to it and replaced -lang-objc with -ObjC. I have a feeling this problem has only occurred on my machine and that it's a local misconfiguration.