here is a short update on the progress of the compatibility script.

I have put together a shell script that accepts all command-lines that
unrar-free or unrar-nonfree would accept and correctly parses them into
internal variables. Doing so, I found that:

 - Both unrar-free and unrar-nonfree have a ridiculously ambigious
   command-line syntax. There is no way of telling whether the last
   argument is a file to extract from the archive or a path to the
   output directory. For now, I decided to assume that the last argument
   is the output directory, but I am considering applying some
   heuristics that check archive contents and direcotries on disk to
   determine what would make the most sense.
 - The unrar manpage is incomplete - there are more options than are
   listed in there.

The script does some extra work to satisfy programs that call it. I use
nzbget to test the "API" in a real-life scenario, and it makes me
scratch my head every few minutes. Mind you, the way nzbget uses unrar
is not unrar's fault, although by now I'd really go with assassinating
both nzbget's and unrar-nonfree's upstream if I had the choice. One
thing is that unrar-nonfree _does_ provide a sensible exit status (0 on
success, >0 on failure) and nzbget _does_ check that, but additionally
it checks for a line containing "All OK" on unrar's stdout. Why the…‽ I
made my wrapper script output "All OK" if calles with the unrar-nonfree
syntax, if the exit code of unar is 0. It works good.

I am trying to add some more compatibility by transforming unar's output
ins something that resembles unrar's output because I herad of packages
out there that parse unrar's output for other reasons than determining a
successful run. unrar's output appears to be an artifact from the MS-DOS
era when human-readable tables and BIG CAPITAL LETTERS were cool. Thus,
unrar l, which should list the archive contents, lists a hell of a lot
of information nobody needs. There is unrar lb (list bare), which only
prints the file names in much the same way lsar does. Sadly, both
commands fail to list all files in the archive. I use an archive that,
as a matter of fact, contains 5 files, listed by lsar and even unpacked
entirely by unrar x, but unrar l simply does not list more than one

The RAR format's quality is arguable, but the software surrounding it is
a mess. I am doing my best to provide good compatibility from my wrapper
script - at least, it cannot get worse than unrar-free ;).

I think I will send a first patch against unar's Vcs-Git in the course
of today. Besides, I would really like to hear the unar maintainer's
thoughts ☺.


# apt-assassinate --help
Usage: apt-assassinate [upstream|maintainer] <package>

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Attachment: signature.asc
Description: Digital signature

Reply via email to