[Raion]

Nothing is more jarring for new users on IRIX than trying:

tar xzvf randomprog.tar.gz

And finding out that no; tar doesn't support compression

Clearly, IRIX tar is inadequate as is. 

There's a few options we have to replacing it; all with benefits, drawbacks and often serious problems, as well as one option that while possible, carries legal risks. 

star - Schily Tar, a derivative of solaris tar. 
Benefits: Supports compression for gz, bz2 and xz, solving most of our immediate concerns, and presumably more sysv compliant. 
Drawbacks: Wasn't able to get it compiled to test for inst, am asking on their mailing list for help. Depends on schily make, which also is having compilation issues. 

libarchive tar - FreeBSD Tar and library. 
Benefits: Incredibly flexible, well-documented and covers pretty much everything include zip and CPIO files. 
Drawbacks: Dozens of deps, latest version doesn't compile (3.3.2 is the latest I got to work), and last time I tried, over a year ago, inst didn't like it. 

GNU tar - GNU Tar
Benefits: Everyone knows GNU tar. It's also reasonably portable. 
Drawbacks: GPLv3, doesn't work with inst, bloated and slow, poor documentation and highly obfuscated. 

And finally, I do actually know where I can get the IRIX tar source. I also know it's based on 1980s BSD tar. I also definitely did not peek at it and confirm it was about 400 lines of code. But of course, modding the code and opening one's self up to legal liability is a huge risk. And while there's a few approaches to solving the "no compression support" issue, the one I was thinking of if someone were to take this route is:

Have it check the extension of the file, and call the appropriate program to uncompress, and then untar it as normal. 

My .02: I don't want to Linuxify IRIX. this is why I have looked at replacements for stuff like libtool, and getting around stuff like bash, gnu tar etc. I'm always willing to put money and my own two hands down to avoid that conclusion, but I guess I'm alone there? I would almost prefer if IRIX were to remain proprietary than for it to be mostly GPL and be released and turned into a monstrosity of Linux-derived code and tools.

[jirka]

I still I use tar from the old Freeware. But it's probably an older version of GNU Tar.

But I'm not sure if use of older tar (pre-GPL3)  is a viable solution :-(

[Raion]

I would personally refuse GNU tar myself. I'm happy to publish the specifications for replacing it, but I won't be likely to say, turn it into an IRIX Community Edition patch. I don't want Linux in my IRIX where possible.

[dexter1]

Libarchive 3.3.3 compiles fine with MIPSPro, see https://tudl1910.home.xs4all.nl/nekoware...s_patches/ for the libarchive release notes and patch file.
There are some problems with gnu-cc-isms when doing the check unittests, and yes there are many dependencies but then you get full support for compressed archives.

I have an alternative solution based on a tcsh alias:

Code:

alias   gztar   'gzcat \!$ | tar \!^- -'

Upon issuing 'gztar xvf archive' this will pipe the archive through gzcat first. You can also use bunzip2 for making a similar alias for .bz2 archives.

[Raion]

Yeah, we could do that too for the interim.

And neat, I didn't realize you'd patched it. Thank you.

[jpstewart]

Raion's comment about libarchive tar not being liked by inst got me wondering about what the difference is.  Turns out there's quite a few options that differ between IRIX tar and libarchive tar:  XCdDNlehBEROSVaqKFM.  (Those are listed in the order they appear in the IRIX tar man page.)  Some have different meanings; some IRIX tar options aren't supported by libarchive tar at all. 

I suspect it's much the same situation with GNU tar since libarchive tar specifically documents which of its options originally came from GNU tar.

Also noteworthy is that RMT (remote tape protocol) support is a "wishlist" item for libarchive tar.  I don't know for sure, but it wouldn't surprise me if inst uses that when installing from a remote source.

So what if, instead of replacing IRIX tar completely, we replaced it with a wrapper (script or binary) that essentially did the same thing as dexter1's alias(es) before calling the original IRIX tar?

The wrapper would need to parse the mode options to tar (c, t, x, ...) to determine whether to compress or decompress and the ones related to compression (z, j, J, ...) to determine which compressor program to use (if any).   Of course the filename would need to picked out and passed to the compressor while the tar command reads or writes standard input or output instead.  Any remaining options would just be passed along to the real tar command (as would be the case when no compression was specified). 

That might be a lot less work and more compatible than completely replacing tar.  Anyone have any thoughts?

[Raion]

Raion's comment about libarchive tar not being liked by inst got me wondering about what the difference is.  Turns out there's quite a few options that differ between IRIX tar and libarchive tar:  XCdDNlehBEROSVaqKFM.  (Those are listed in the order they appear in the IRIX tar man page.)  Some have different meanings; some IRIX tar options aren't supported by libarchive tar at all. 

I suspect it's much the same situation with GNU tar since libarchive tar specifically documents which of its options originally came from GNU tar.

Also noteworthy is that RMT (remote tape protocol) support is a "wishlist" item for libarchive tar.  I don't know for sure, but it wouldn't surprise me if inst uses that when installing from a remote source.

So what if, instead of replacing IRIX tar completely, we replaced it with a wrapper (script or binary) that essentially did the same thing as dexter1's alias(es) before calling the original IRIX tar?

The wrapper would need to parse the mode options to tar (c, t, x, ...) to determine whether to compress or decompress and the ones related to compression (z, j, J, ...) to determine which compressor program to use (if any).   Of course the filename would need to picked out and passed to the compressor while the tar command reads or writes standard input or output instead.  Any remaining options would just be passed along to the real tar command (as would be the case when no compression was specified). 

That might be a lot less work and more compatible than completely replacing tar.  Anyone have any thoughts?

I think it's a good solution; barring an inst replacement happening from my bounty. I would say a binary would be preferable, as even a shell script would be slower on the Indy and other systems, and as I've said, I don't want to leave those behind if at all (I do plan to try and build a MIPS III mplayer after all, just with less codecs available)

As for how to do it, I would need to research. While it sounds simple, coding anything in C /rarely/ is.

[Raion]

Code:

#include <stdio.h>
#include <stdlib.h>

int main( int argc, char *argv[] )
{

  FILE *fp;
  char path[1035];

  /* Open the command for reading. */
  fp = popen("/bin/ls /etc/", "r");
  if (fp == NULL) {
    printf("Failed to run command\n" );
    exit(1);
  }

  /* Read the output a line at a time - output it. */
  while (fgets(path, sizeof(path), fp) != NULL) {
    printf("%s", path);
  }

  /* close */
  pclose(fp);

  return 0;
}

Well this didn't make mipspro puke out its guts, so I'll assume that with enough patience and time, i could get something working. My main concern is security, but I'm sure with the number of fellow programmers here, assuming I come through with this okay, I'll be grilled on how to better do this. I'll mess around for a few weeks on this and come up with a decent stopgap.

[jpstewart]

As for how to do it, I would need to research. While it sounds simple, coding anything in C /rarely/ is.

I wasn't suggesting you need do it yourself.  If there's interest, I'm prepared to offer to write it.  (I write shell scripts on an almost daily basis and have more than 25 years experience programming C on Unix.)

[Raion]

That does work too lol. I'm still gonna research how I would do it just for fun, but I'm sure you could come up with a better result.