-@FIXME{I have one question, or maybe it's a suggestion if there isn't a way
-to do it now. I would like to use @option{--gzip}, but I'd also like
-the output to be fed through a program like @acronym{GNU}
-@command{ecc} (actually, right now that's @samp{exactly} what I'd like
-to use :-)), basically adding ECC protection on top of compression.
-It seems as if this should be quite easy to do, but I can't work out
-exactly how to go about it. Of course, I can pipe the standard output
-of @command{tar} through @command{ecc}, but then I lose (though I
-haven't started using it yet, I confess) the ability to have
-@command{tar} use @command{rmt} for it's I/O (I think).
-
-I think the most straightforward thing would be to let me specify a
-general set of filters outboard of compression (preferably ordered,
-so the order can be automatically reversed on input operations, and
-with the options they require specifiable), but beggars shouldn't be
-choosers and anything you decide on would be fine with me.
-
-By the way, I like @command{ecc} but if (as the comments say) it can't
-deal with loss of block sync, I'm tempted to throw some time at adding
-that capability. Supposing I were to actually do such a thing and
-get it (apparently) working, do you accept contributed changes to
-utilities like that? (Leigh Clayton @file{loc@@soliton.com}, May 1995).
-
-Isn't that exactly the role of the @option{--use-compress-prog=@var{program}} option?
-I never tried it myself, but I suspect you may want to write a
-@var{prog} script or program able to filter stdin to stdout to
-way you want. It should recognize the @option{-d} option, for when
-extraction is needed rather than creation.
-
-It has been reported that if one writes compressed data (through the
-@option{--gzip} or @option{--compress} options) to a DLT and tries to use
-the DLT compression mode, the data will actually get bigger and one will
-end up with less space on the tape.}
+@cindex gpg, using with tar
+@cindex gnupg, using with tar
+@cindex Using encrypted archives
+The @option{--use-compress-program} option, in particular, lets you
+implement your own filters, not necessarily dealing with
+compression/decomression. For example, suppose you wish to implement
+PGP encryption on top of compression, using @command{gpg} (@pxref{Top,
+gpg, gpg ---- encryption and signing tool, gpg}). The following
+script does that:
+
+@smallexample
+@group
+#! /bin/sh
+case $1 in
+-d) gpg --decrypt - | gzip -d -c;;
+'') gzip -c | gpg -s ;;
+*) echo "Unknown option $1">&2; exit 1;;
+esac
+@end group
+@end smallexample
+
+Suppose you name it @file{gpgz} and save it somewhere in your
+@env{PATH}. Then the following command will create a commpressed
+archive signed with your private key:
+
+@smallexample
+$ @kbd{tar -cf foo.tar.gpgz --use-compress=gpgz .}
+@end smallexample
+
+@noindent
+Likewise, the following command will list its contents:
+
+@smallexample
+$ @kbd{tar -tf foo.tar.gpgz --use-compress=gpgz .}
+@end smallexample
+
+@ignore
+The above is based on the following discussion:
+
+ I have one question, or maybe it's a suggestion if there isn't a way
+ to do it now. I would like to use @option{--gzip}, but I'd also like
+ the output to be fed through a program like @acronym{GNU}
+ @command{ecc} (actually, right now that's @samp{exactly} what I'd like
+ to use :-)), basically adding ECC protection on top of compression.
+ It seems as if this should be quite easy to do, but I can't work out
+ exactly how to go about it. Of course, I can pipe the standard output
+ of @command{tar} through @command{ecc}, but then I lose (though I
+ haven't started using it yet, I confess) the ability to have
+ @command{tar} use @command{rmt} for it's I/O (I think).
+
+ I think the most straightforward thing would be to let me specify a
+ general set of filters outboard of compression (preferably ordered,
+ so the order can be automatically reversed on input operations, and
+ with the options they require specifiable), but beggars shouldn't be
+ choosers and anything you decide on would be fine with me.
+
+ By the way, I like @command{ecc} but if (as the comments say) it can't
+ deal with loss of block sync, I'm tempted to throw some time at adding
+ that capability. Supposing I were to actually do such a thing and
+ get it (apparently) working, do you accept contributed changes to
+ utilities like that? (Leigh Clayton @file{loc@@soliton.com}, May 1995).
+
+ Isn't that exactly the role of the
+ @option{--use-compress-prog=@var{program}} option?
+ I never tried it myself, but I suspect you may want to write a
+ @var{prog} script or program able to filter stdin to stdout to
+ way you want. It should recognize the @option{-d} option, for when
+ extraction is needed rather than creation.
+
+ It has been reported that if one writes compressed data (through the
+ @option{--gzip} or @option{--compress} options) to a DLT and tries to use
+ the DLT compression mode, the data will actually get bigger and one will
+ end up with less space on the tape.
+@end ignore