Howdy, 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 file. 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 ☺. Cheers, Nik -- # 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