Sun's Solaris operating system has been around for a long time now, and as commercial Unix goes, they might be the best game in town from the perspective of users and ISVs. But there are a couple things about Solaris that really suck.

diff and patch

A very long time ago, Larry Wall (of PERL fame) wrote a useful doodad called patch. patch is used to take the output from diff and reliably make changes to text files. Basically, diff shows all the differences between two files, and patch uses that information to programmatically turn one into the other. This is awfully handy, especially when dealing with source code and complex configuration files. I love diff and patch.

But over time, as source code got complicated, dealing with only one file at a time got pretty lame. So diff learned to recurse, and so did patch. Except not the version of patch Sun has put in every version of Solaris I've ever encountered until the release of Solaris 9. Sun's pathetic version of patch can't apply multifile patches, such as you would get using Sun's recursive-mode diff.

This asymmetry cost me several hours of blinding headaches a few years ago as I struggled to understand what I was doing wrong that I couldn't successfully produce a diff that could be applied using patch. Thanks Sun!

tar

Now a lot of weenies will gripe about Solaris tar not linking against GNU's zlib, precluding the use of the practically obligatory -z flag for automatic GZIP file handling. And some might be boggled that the default device is /dev/rmt/0. But my gripe with tar has to do with long pathnames, like you might find in the deep hierarchy on a Solaris installation CD. Solaris tar truncates paths (among a few limitations) past a certain point unless you set the -E flag. Insidiously, tar will tell you it's truncating paths, but that might not help the many folks who are partial to the -v flag. I suppose Sun's logic here is they figure it might be more entertaining for you to only slowly figure out what has happened over the course of bludgeoning your forehead against various hard surfaces. I, being an expert with Solaris, have never been thus entertained by Sun. Really.

grep

Historically, Sun's implementation of grep (and its siblings, egrep and fgrep) did not support the standard -q flag required by XPG4, among other Unix "standards." The -q flag to grep requests that grep silently return 0 if any match occurs or return non-zero if the match is not found. The "correct" Solaris equivalent is to run regular grep and throw away STDOUT and STDERR and then check the return value. To wit, instead of getting to do:

								
grep -q foo file-containing-foo && echo Found foo

								
							

we have the privilege of writing the eminently preferable:

								
grep foo file-containing-foo > /dev/null 2>&1
test "$? = 0" && echo Found foo
								
							

The reasoning, I imagine, is that if you fed an uncompilable regular expression to grep or egrep (sometimes known as "grep -E": read on), grep would need to return non-zero to inform you of the problem. The -q flag invites the ambiguous case where non-zero might mean "Didn't bother looking because the expression makes no sense" instead of the expected "Expression not matched" meaning. As a result, Sun puts an XPG4-compliant version of grep in /usr/xpg4/bin.

Is it just that Sun engineers are annoying pedants or what?

ps

When Sun introduced the rather clever proc filesystem to Solaris, they decided that all process-related data should be interfaced through a consistent interface based on this new filesystem. The psinfo data structure holds the relevant data reported by ps(1), but for whatever reasons (probably in order to have a fixed-size data structure) the argument list to any command as stored in psinfo is truncated at 80 characters, the value of the PRARGSZ constant. As a result, the standard /usr/bin/ps cannot report more than 80 characters of a process's argument list.

Now 80 characters might seem like a lot. It is a lot. It's a classic terminal's line width. But do you run much Java? Java processes have the unfortunate tendency to be invoked with incredibly long arguments. Just setting the CLASSPATH could easily consume all 80 characters Sun allots. Now Sun determined the size of the PRARGSZ constant way before Java came along, but people have been complaining about this arbitrary limit since 1994. Seriously. I checked in Sunsolve. Modifying ps(1) to do more legwork and extract the full argument list by other means is certainly possible. Sun needs to take care of this problem. Until then all of us are stuck using the "deprecated" "/usr/ucb/ps axww" approach to do what we need.

Summary

Like I say at the beginning, in general I think Solaris offers excellent breadth of functionality and what may be the most generally usable commercial Unix I have encountered, in terms of providing consistent, stable and thoughtful interfaces at all levels (GUI, CLI, API). I'm not some anti-Sun freak and make my living primarily from working on Solaris systems. But that doesn't mean I haven't noticed some shortcomings in the course of my career. I'm gratified to see Sun adopt the current GNU versions of diff and patch for Solaris 9, and the adoption of GNU tar is helpful (the -z flag is useful).

(C) 2002, Michael Han
$Id: solaris-tools.html,v 1.4 2003/06/28 22:01:46 mikehan Exp $