The dabe command can either read the standard input, or be given a list of files containing ABE data. If files are provided, they are concatenated together. (ABE encodings of large files are often split up into several files so that no file is too large for the communications channel. Simply pass all the files to the decoder.)
Dabe can handle files with randomly inserted lines and extraneous headers and comments. There is no need to edit a mail message with an ABE file before passing it to dabe.
Some ABE file sets are encoded in such a way that redundant information is included with each part of a split-up encoding. In this case, you can pass such sets of files to dabe in any order, and duplicates may also exist.
If redundant information is not included, you can always put an ABE encoding in order with the sort(1) program. Use "sort -u" if your set of files might contain duplicates of parts of the file. If all lines of an encoding are present and intact, then sort can always make the encoding right, no matter how much mangling has been done to it.
Say that a binary encoding has arrived on USENET, and that the encoding was done with redundant information in each part. Say that the parts arrived at your site in a random order, with other articles mixed in, and that some of the parts were reposted because they were lost in some sections of the net. If those articles ran from article 340 to article 347, you could simply say:
The only thing dabe are certain missing header lines and the presence of a different, independently made ABE encoding in the middle of the group of files passed to the decoder. An error message is always given if there is something wrong with the file.
It is even possible for dabe to decode an encoding that has missing or damaged blocks. Those sections of the resulting file will be blank or in error, but other sections will be correct and in place. With some types of files -- namely certain archives, this is still useful so long as the first section is not one of those missing or damaged.
Dabe writes to files as named in the encoding. If the encoding was done on the same operating system as you are using, the files will appear with their valid names, and often with permissions and modification times properly set. If the file comes from another operating system, it will be stored in the current directory according to a "universal name" defined at the time of encoding.
It is possible for several files to be combined in the same encoding. This allows the ABE system to be used as a primitive archiver. It is not possible for blocks from different files to be presented to the decoder in any order. Multiple file encodings must either be given in order, or sorted.
Some ABE files come with the source code to a tiny decoder. Do not use this if you have the full dabe decoder.
In an ABE encoding, printable characters always map to themselves, if possible. This means that printable character strings found in binary files are still readable in an ABE encoding. You can often look at a raw ABE file and see what it is, which is quite useful. In addition, the byte 0 maps to the ASCII digit "0," and several other similar useful mappings are made.
ABE files also have header information that defines information about the encoded files, block headings, sizes and checksums. For full details on the encoding format, see the special file on that in the ABE kit.
The dabe decoder is actually very general, and it has facilities to handle arbitrary ABE-style encodings as well as ABE encased uuencode(1) encodings. It understands many header lines which are not yet used by the encoder, but which may be implemented in future.
No fee is requested or required for the use of these programs. If you feel the need to show appreciation, You might order copies of the REC.HUMOR.FUNNY Computer Network Humour Annual(s) (a USENET jokebook) for 9.95 USD+S/H. Mail to jokebook@looking.UUCP or call 519/884-7473. There is no requirement to buy the jokebook in order to use these programs.