From 20ab569dc33b640354f862f584b9c964a367ac34 Mon Sep 17 00:00:00 2001 From: Benno Schulenberg Date: Thu, 5 Jun 2014 18:26:46 +0200 Subject: [PATCH] Fix a typo and some wordings in the documentation. * doc/tar.texi: Fix some missing articles, and make it clearer that "any" does not mean "anything" but "either of the two". --- doc/tar.texi | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/tar.texi b/doc/tar.texi index e3df0c9..82c303d 100644 --- a/doc/tar.texi +++ b/doc/tar.texi @@ -9813,15 +9813,15 @@ free from many of @samp{v7}'s drawbacks. @subsection Ustar Archive Format @cindex ustar archive format -Archive format defined by @acronym{POSIX}.1-1988 specification is called -@code{ustar}. Although it is more flexible than the V7 format, it +The archive format defined by the @acronym{POSIX}.1-1988 specification is +called @code{ustar}. Although it is more flexible than the V7 format, it still has many restrictions (@pxref{Formats,ustar}, for the detailed description of @code{ustar} format). Along with V7 format, @code{ustar} format is a good choice for archives intended to be read with other implementations of @command{tar}. -To create archive in @code{ustar} format, use @option{--format=ustar} -option in conjunction with the @option{--create} (@option{-c}). +To create an archive in @code{ustar} format, use the @option{--format=ustar} +option in conjunction with @option{--create} (@option{-c}). @node gnu @subsection @acronym{GNU} and old @GNUTAR{} format @@ -10024,18 +10024,18 @@ same contents: SunOS and HP-UX @command{tar} fail to accept archives created using @GNUTAR{} and containing non-@acronym{ASCII} file names, that -is, file names having characters with the eight bit set, because they +is, file names having characters with the eighth bit set, because they use signed checksums, while @GNUTAR{} uses unsigned checksums while creating archives, as per @acronym{POSIX} standards. On -reading, @GNUTAR{} computes both checksums and -accepts any. It is somewhat worrying that a lot of people may go +reading, @GNUTAR{} computes both checksums and accepts either of them. +It is somewhat worrying that a lot of people may go around doing backup of their files using faulty (or at least non-standard) software, not learning about it until it's time to restore their missing files with an incompatible file extractor, or vice versa. -@GNUTAR{} computes checksums both ways, and accept -any on read, so @acronym{GNU} tar can read Sun tapes even with their +@GNUTAR{} computes checksums both ways, and accepts either of them +on read, so @acronym{GNU} tar can read Sun tapes even with their wrong checksums. @GNUTAR{} produces the standard checksum, however, raising incompatibilities with Sun. That is to say, @GNUTAR{} has not been modified to @@ -10050,7 +10050,7 @@ the default signing of @code{char}'s in their compiler. So they started computing checksums wrongly. When they later realized their mistake, they merely decided to stay compatible with it, and with themselves afterwards. Presumably, but I do not really know, HP-UX -has chosen that their @command{tar} archives to be compatible with Sun's. +has chosen their @command{tar} archives to be compatible with Sun's. The current standards do not favor Sun @command{tar} format. In any case, it now falls on the shoulders of SunOS and HP-UX users to get a @command{tar} able to read the good archives they receive. -- 2.43.0