Tue, 15 Jul 2008 22:18:03 -0400
Give extraction stderr more context, and suppress normal cpio stderr junk.
cpio will write a useless "N blocks" message to stderr without --quiet, so
use that.
When we show extraction's stderr to the user, first write a line explaining
what it is, and also don't forget to strip the trailing newline, since
.warning() writes its own.
-*- text -*- To do: * Everything is messed up when an archive contains one file... but I forget what I meant by this. * When we extract a compressed file (or just one file?), check to see if it itself is an archive. Follow all the usual rules for recursive extraction when we do this. * --expert mode: prompts don't show an explanation of what the options are, unless you ask with ?. Things which I have a use case/anti-use case for: * Support pisi packages (http://paketler.pardus.org.tr/pardus-2007/) * Steal ideas from <http://martin.ankerl.com/files/e>. * More consistently raise and handle exceptions. Things that are generally good: * Better tests. * Better error messages. Things I think might be good but can't prove: * Consider having options about whether or not to make sane directories, have tarbomb protection, etc. * Use zipfile instead of the zip commands. * Processing from stdin. * shar support.