« I wish I lived in the UK | Main | Danger Will Robinson! »

May 29, 2005

Tar Wars Or Is the FSF the Microsoft of UNIX?

Friday at work, I had to unpack a gzipped tarball... in Solaris. This ordinarily is quite a mundane task that I've done thousands of times. But this time something was rotten in the state of UNIX. Normally with gnu tar, tar xf file.tar.gz does the task. I wasn't surprised when this didn't work though as this feature was added to gnu tar quite recently. so i tried what I used to do when I first started using Linux, tar xzf filename.tar.gz, again this didn't work. Then I remembered that I had heard that the compression flags were a gnu extension to tar and not supported by many implementations of tar. I also remembered seeing pipe instructions come with many gzipped tar balls. I quickly found on gzip.org: gunzip < file.tar.gz | /usr/bin/tar xvf -.

Now I've never had problems with this on EECS's sun boxen. This appears to be because we actually have tar in four different places on them. In PATH order we have:

ajc30@bender ~ $ /usr/pkg/bin/tar
usage: tar [-]{crtux}[-befhjlmopqvwzHLOPXZ014578] [archive] [blocksize]
           [-C directory] [-T file] [-s replstr] [file ...]
ajc30@bender ~ $ /usr/local/bin/tar
/usr/local/bin/tar: You must specify one of the `-Acdtrux' options
Try `/usr/local/bin/tar --help' for more information.
ajc30@bender ~ $ /usr/bin/tar
Usage: tar {txruc@}[vfbFXhiBDEelmopwnq[0-7]] [-k size] [tapefile] [blocksize] [exclude-file] [-I include-file] files ...
ajc30@bender ~ $ /bin/tar
Usage: tar {txruc@}[vfbFXhiBDEelmopwnq[0-7]] [-k size] [tapefile] [blocksize] [exclude-file] [-I include-file] files ...

In order they appear to be NetBSD's tar, Gnu tar 1.13, Sun's tar, and Sun's tar not on PATH. NetBSD's tar seems to support the compression flags like gnu tar but not auto detection of compression. Gnu tar 1.13 also lacks auto detect. And obviously Sun's tar doesn't support either.

Now command line incompatibility is one thing but apparently there are problems with opening tar files themselves. It seems that OpenBSD's tar could not properly unpack Zope, which apparently used gnu extensions to tar to support long file names. Now it appears that since then OpenBSD tar has become compatible (based on unpacking with both tars on OpenBSD 3.6 and comparing with diff -r).

Another example is m4. The tex build system uses m4 -P yet according to tex-live mailing list m4 -P is a GNUism and not supported by IRIX's m4.

More familiar to people is the bash issue. Bash (maintained by out very own Chet Ramey) is a POSIX compatible shell and also adds a variety of use features that we desire from a more modern shell. Some systems (such as Debian) use bash as their /bin/sh. Then in these systems shell scripts assuming /bin/sh is bash creep in. And voilà incompatibility with other POSIX shells. Of course the shell world is compatibility is a nightmare. To quote the autoconf documentation: "there are some corner cases in the Bourne shell that are not completely compatible with a POSIX shell.... While most (at least most System V's) do have a Bourne shell that accepts shell functions most vendor /bin/sh programs are not the POSIX shell. So while most modern systems do have a shell somewhere that meets the POSIX standard, the challenge is to find it." And Bash even has it's own list of incompatibilities with it's own 1.x series (despite that bash is still my favorite shell)

Now it seems to me that in these examples GNU "embraced and extended" existing standards. For this very same behavior we vilify Microsoft. In this era of of GNU/Linux's rapid growth it seems like this might hurt competing UNIX like systems and cause unintentional GNU/Linux lock-in.

Posted by ajc30 at May 29, 2005 12:06 AM

Trackback Pings

TrackBack URL for this entry:
http://blog.case.edu/ajc30/mt-tb.cgi/1539

Comments

Post a comment




Remember Me?

(you may use HTML tags for style)