Hello!

I can't find the pax (Posix Archiver, which supports cpio and tar archives) command in Slackware. Is there any reason for that?

Best Regards
Christian

Is there any reason to add it? In other words, does it do something that tar(1) and cpio(1) are unable to do?

Hello rworkman,

Yes, it does provide a certain amount of convenience when scripting.

However, not having this out-of-the-box is not criticism against Slackware. However, I don't see why you should be able to compile it. Did you check out slackbuilds.org?

Murdock

I built a Slackware 10.0 package for pax long ago - see http://www.slackware.com/~alien/slackbuilds/pax/
Basically it is non-maintained and is only available in source form from a SuSE ftp server.

Eric

Not any more. According to the home page the expectation is that all 3 will merge - into paxutils.

Last code release 1999, last webpage update 2002. paxutils appears to be on a similar timeline to that of the Hurd kernel. tar handles pax archives so paxutils are not needed.

Hmmm - might be a bit of wishful thinking in what I read. It has been resurrected as of 2003 apparently; doesn't seem to have progressed much. See here for what I was going on.

I've used the sources available from Suse, too. I couldn't find other sources. Now I've written a Slackbuild Script, too (Because I didn't know, that Eric has got one).
Normally I use tar to create and extract archives, but I got a script which makes use of pax.

If anyone is interested, send me a message via LQ with your email adress for getting the script/slack-desc or the package. I haven't got a server where I can put it.

Best Regards
Christian

Posix compliance is the primary reason. Those who script to the standard will find things break on Slackware. This would seem to fit with Slackware's Unix-like focus.

Doubtful, using pax in scripts intended for use on Linux is a stupid idea given that almost no distro installs pax by default and those that do (or include it as part of an LSB compliance meta package) offer a poorly maintained fork of an old MirBSD pax. That version cannot even create pax archives, only USTAR (and hence that pax is not POSIX.1-2001 compliant in any case). Furthermore the USTAR format is not a serious backup format for modern system due to various limitations, e.g. 8 GB limit on files within the archive. If you are writing scripts for use on Linux you should not rely on Pax being present, Posix requirement or not. Additionally I do not believe it is one of Slackware's goals to be 100% Posix compliant. Slackware is trying to stay true to the spirit of what UNIX is/was, not necessarily the latest iteration of Posix.

By the way modern versions of tar, like GNU tar and BSD tar can create Pax archives. Both of these versions have a wide range of options, vastly surpassing the feature set defined by Posix for Pax. The Pax format is IMHO a worthwhile standard, however the case for the pax binary is less clear. Tar has won that war and remains the de facto standard.

I say all of this as someone who actually has a soft spot for pax (it was a nice idea in theory). Indeed I maintain a SlackBuild for the pax provided by The Heirloom Toolchest. This version of pax can create POSIX.1-2001 pax archives. It can also can read and write zip files, RPM packages, various tar formats (including GNU tar), and the extended cpio formats of Cray UNICOS, SGI IRIX (-K), SCO UnixWare (-c) and Tru64 UNIX (-e).

2 members found this post helpful.