Adding upstream version 1.12.upstream/1.12

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 44 insertions, 36 deletions

diff --git a/README b/README
index b86ff58..b09c908 100644
--- a/README
+++ b/README
@@ -1,53 +1,57 @@
 Description
 
-Lunzip is a decompressor for the lzip format. It is written in C and its
-small size makes it well suited for embedded devices or software
-installers that need to decompress files but don't need compression
-capabilities. Lunzip is fully compatible with lzip-1.4 or newer.
+Lunzip is a decompressor for the lzip format written in C. Its small size
+makes it well suited for embedded devices or software installers that need
+to decompress files but don't need compression capabilities. Lunzip is fully
+compatible with lzip 1.4 or newer.
 
 The lzip file format is designed for data sharing and long-term archiving,
 taking into account both data integrity and decoder availability:
 
    * The lzip format provides very safe integrity checking and some data
-     recovery means. The lziprecover program can repair bit flip errors
-     (one of the most common forms of data corruption) in lzip files,
-     and provides data recovery capabilities, including error-checked
-     merging of damaged copies of a file.
-
-   * The lzip format is as simple as possible (but not simpler). The
-     lzip manual provides the source code of a simple decompressor
-     along with a detailed explanation of how it works, so that with
-     the only help of the lzip manual it would be possible for a
-     digital archaeologist to extract the data from a lzip file long
-     after quantum computers eventually render LZMA obsolete.
+     recovery means. The program lziprecover can repair bit flip errors
+     (one of the most common forms of data corruption) in lzip files, and
+     provides data recovery capabilities, including error-checked merging
+     of damaged copies of a file.
+
+   * The lzip format is as simple as possible (but not simpler). The lzip
+     manual provides the source code of a simple decompressor along with a
+     detailed explanation of how it works, so that with the only help of the
+     lzip manual it would be possible for a digital archaeologist to extract
+     the data from a lzip file long after quantum computers eventually
+     render LZMA obsolete.
 
    * Additionally the lzip reference implementation is copylefted, which
      guarantees that it will remain free forever.
 
-A nice feature of the lzip format is that a corrupt byte is easier to
-repair the nearer it is from the beginning of the file. Therefore, with
-the help of lziprecover, losing an entire archive just because of a
-corrupt byte near the beginning is a thing of the past.
+A nice feature of the lzip format is that a corrupt byte is easier to repair
+the nearer it is from the beginning of the file. Therefore, with the help of
+lziprecover, losing an entire archive just because of a corrupt byte near
+the beginning is a thing of the past.
 
-Lunzip uses the same well-defined exit status values used by lzip, which
+Lunzip uses the same well-defined exit status values used by bzip2, which
 makes it safer than decompressors returning ambiguous warning values (like
 gunzip) when it is used as a back end for other programs like tar or zutils.
 
 Lunzip provides a 'low memory' mode able to decompress any file using as
 little memory as 50 kB, irrespective of the dictionary size used to
 compress the file. To activate it, specify the size of the output buffer
-with the '--buffer-size' option and lunzip will use the decompressed
+with the option '--buffer-size' and lunzip will use the decompressed
 file as dictionary for distances beyond the buffer size. Of course, the
-smaller the buffer size used in relation to the dictionary size, the
+larger the difference between the buffer size and the dictionary size, the
 more accesses to disk are needed and the slower the decompression is.
 This 'low memory' mode only works when decompressing to a regular file
 and is intended for systems without enough memory (RAM + swap) to keep
 the whole dictionary at once. It has been tested on a laptop with a 486
 processor and 4 MiB of RAM.
 
-The amount of memory required by lunzip to decompress a file is about
-46 kB larger than the dictionary size used to compress that file, unless
-the '--buffer-size' option is specified.
+The option '--buffer-size' may help to decompress a file erroneously created
+with a dictionary size much larger than the uncompressed size. (Lzip adjusts
+the dictionary size to the uncompressed size, but third-party tools may not).
+
+The amount of memory required by lunzip to decompress a file is about 46 kB
+larger than the dictionary size used to compress that file, unless
+'--buffer-size' is specified.
 
 Lunzip attempts to guess the name for the decompressed file from that of
 the compressed file as follows:
@@ -62,12 +66,12 @@ possible, ownership of the file just as 'cp -p' does. (If the user ID or
 the group ID can't be duplicated, the file permission bits S_ISUID and
 S_ISGID are cleared).
 
-Lunzip is able to read from some types of non regular files if the
-'--stdout' option is specified.
+Lunzip is able to read from some types of non-regular files if either the
+option '-c' or the option '-o' is specified.
 
-If no file names are specified, lunzip decompresses from standard input
-to standard output. In this case, lunzip will decline to read compressed
-input from a terminal.
+If no file names are specified, lunzip decompresses from standard input to
+standard output. In this case, lunzip will refuse to read compressed input
+from a terminal, as this might leave the terminal in an abnormal state.
 
 Lunzip will correctly decompress a file which is the concatenation of two or
 more compressed files. The result is the concatenation of the corresponding
@@ -75,16 +79,20 @@ decompressed files. Integrity testing of concatenated compressed files is
 also supported.
 
 The ideas embodied in lunzip are due to (at least) the following people:
-Abraham Lempel and Jacob Ziv (for the LZ algorithm), Andrey Markov (for
-the definition of Markov chains), G.N.N. Martin (for the definition of
-range encoding), Igor Pavlov (for putting all the above together in
-LZMA), and Julian Seward (for bzip2's CLI).
+Abraham Lempel and Jacob Ziv (for the LZ algorithm), Andrey Markov (for the
+definition of Markov chains), G.N.N. Martin (for the definition of range
+encoding), Igor Pavlov (for putting all the above together in LZMA), and
+Julian Seward (for bzip2's CLI).
+
+LANGUAGE NOTE: Uncompressed = not compressed = plain data; it may never have
+been compressed. Decompressed is used to refer to data which have undergone
+the process of decompression.
 
 
-Copyright (C) 2010-2019 Antonio Diaz Diaz.
+Copyright (C) 2010-2021 Antonio Diaz Diaz.
 
 This file is free documentation: you have unlimited permission to copy,
-distribute and modify it.
+distribute, and modify it.
 
 The file Makefile.in is a data file used by configure to produce the
 Makefile. It has the same copyright owner and permissions that configure