richard@aiai.ed.ac.uk (Richard Tobin) (10/09/90)
Can it really be that under Interactive "tar cv" writes the names of the files to standard output, so that "tar cvf -" produces a corrupted file? Is this standard System V brain damage? -- a BSD user -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
ggw%wolves@cs.duke.edu (Gregory G. Woodbury) (10/09/90)
In <3494@skye.ed.ac.uk> richard@aiai.ed.ac.uk (Richard Tobin) writes: > >Can it really be that under Interactive "tar cv" writes the names of the >files to standard output, so that "tar cvf -" produces a corrupted file? >Is this standard System V brain damage? > >-- a BSD user A BSD BIGOT more descriptively. Whatever the ISC supplied "tar" does is whatever it does. By definition, tar is an imported command to System V from the BSD universe. Whatever they did to it sure made it incompatible. This is a problem with a variety of tar imports to system V. It does not seem to be constant from one sV version to another. I gave up trying to figure out just what was wrong with all the bloody tar variants that I have seen on various machines were doing. I fetched the "pdtar" program from one of the sources archives (thanks, UUnet!) and just use that as the tar command when necessary. Brain damage can just as easily be attributed to BSD as to System V. It can also be attributed to stoopid users. -- Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC UUCP: ...dukcds!wolves!ggw ...mcnc!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ] <standard disclaimers apply>
cpcahil@virtech.uucp (Conor P. Cahill) (10/09/90)
In article <3494@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >Can it really be that under Interactive "tar cv" writes the names of the >files to standard output, so that "tar cvf -" produces a corrupted file? Yes. (so you have to use tar cf - or tar cvf file to get a good tar file). >Is this standard System V brain damage? I believe it is. (Interactive would not be so stupid as to add this blunder to the code). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
cpcahil@virtech.uucp (Conor P. Cahill) (10/09/90)
In article <1990Oct9.002629.16247@wolves.uucp> ggw%wolves@cs.duke.edu (Gregory G. Woodbury) writes: >Whatever the ISC supplied "tar" does is whatever it does. By >definition, tar is an imported command to System V from the BSD >universe. If I remember correctly tar is the original tape archiver that came with version 6, PWB, and version 7 UNIX. Then it diverged a bit in BSD, Xenix and AT&T UNIXs (similar to the way that UNIX itself diverged). The one included with System V R3.2 and later is the result of the Xenix tar being merged back into the AT&T tar. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
paul@actrix.co.nz (Paul Gillingwater) (10/10/90)
In article <3494@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: > Can it really be that under Interactive "tar cv" writes the names of the > files to standard output, so that "tar cvf -" produces a corrupted file? I have used tar pipes many times, and never had any corruption problems under ISC 2.02 386/ix. Sure, names do go to stdout, as part of the archive -- the verbose list goes to stderr. -- Paul Gillingwater, paul@actrix.co.nz
guy@auspex.auspex.com (Guy Harris) (10/10/90)
>Whatever the ISC supplied "tar" does is whatever it does. By >definition, tar is an imported command to System V from the BSD >universe. Bzzt! Sorry, wrong answer, next contestant please. S5 source distributions from AT&T include source to "tar"; it's not "by definition" an import! The 3B2 S5R3 "tar" source indicates that the only places where the "v" flag causes "tar" to print something to the standard output, rather than the standard error, is when used with the "t" flag (as you'd expect, the table of contents goes to the standard output) or when used with the "w" flag (the query for user confirmation is sent to the standard output). The BSD "tar" source indicates that the "v" flag will write to the standard output *unless an archive is being written*, in which case it's written to the standard error.
ronald@robobar.co.uk (Ronald S H Khoo) (10/11/90)
cpcahil@virtech.UUCP (Conor P. Cahill) writes: > The one included with System V R3.2 and later is the result of the Xenix > tar being merged back into the AT&T tar. Does the generic 3.2 tar support the 'q' option that SCO does (though *un*documented) which says something like "stop after the first matching file" ? -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
dougm@ico.isc.com (Doug McCallum) (10/11/90)
In article <4173@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: ... >The 3B2 S5R3 "tar" source indicates that the only places where the "v" >flag causes "tar" to print something to the standard output, rather than >the standard error, is when used with the "t" flag (as you'd expect, the >table of contents goes to the standard output) or when used with the "w" >flag (the query for user confirmation is sent to the standard output). The 386 S5R3.2 "tar" source has "printf" everywhere rather than any fprintf(stderr,...) calls. This appears to have been the way it came back to AT&T (and ISC) from Microsoft during the XENIX merge. The version of tar that was shipped with S5R3.0 did it correctly (that is, the same as the 3B2 source does it).
cpcahil@virtech.uucp (Conor P. Cahill) (10/11/90)
In article <1990Oct10.211911.9236@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >cpcahil@virtech.UUCP (Conor P. Cahill) writes: > >> The one included with System V R3.2 and later is the result of the Xenix >> tar being merged back into the AT&T tar. > >Does the generic 3.2 tar support the 'q' option that SCO does (though >*un*documented) which says something like "stop after the first matching >file" ? A simple test of "tar -qvf -" before posting the question would have answered your question: tar: q: unknown option Usage:..... -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
cpcahil@virtech.uucp (Conor P. Cahill) (10/11/90)
In article <1990Oct9.193338.6173@actrix.co.nz> paul@actrix.co.nz (Paul Gillingwater) writes: >In article <3494@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >> Can it really be that under Interactive "tar cv" writes the names of the >> files to standard output, so that "tar cvf -" produces a corrupted file? > >I have used tar pipes many times, and never had any corruption >problems under ISC 2.02 386/ix. Sure, names do go to stdout, as >part of the archive -- the verbose list goes to stderr. If the tar file is small enough, the corruption is at the end and tar silently ignores it. However, if you have a big enough tar file (somewhere around 100K or so from a few tests that I have run) the extra data will cause you to get a directory checksum error. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
ti@altos86.Altos.COM (Ti Kan) (10/12/90)
In article <1990Oct09.114759.1025@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <3494@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >>Can it really be that under Interactive "tar cv" writes the names of the >>files to standard output, so that "tar cvf -" produces a corrupted file? > >Yes. (so you have to use tar cf - or tar cvf file to get a good tar file). > >>Is this standard System V brain damage? > >I believe it is. (Interactive would not be so stupid as to add this >blunder to the code). > tar cv and xv should output the file listing to stderr, not stdout. AT&T's Sys V.3 source code is correct, but many 386 UNIX vendors did not use AT&T's tar sources. Rather, they used the Microsoft tar source which came from Xenix. The Microsoft tar has the wrong behavior of writing the file listing to stdout. For the record, all current Altos UNIX (not Xenix) releases for all its systems has the correct tar behavior. Although our tar sources are derived from Microsoft's base, we have corrected the problem. On a side note, the V.4 tar source from AT&T appears to be a modified version of Microsoft's tar, not AT&T V.3's. Thus, the aforementioned bug is re-introduced into AT&T's own sources! Ugh. -Ti -- Ti Kan | vorsprung durch technik! \\\ Internet: ti@altos.com \\\ UUCP: ...!{sun|sco|pyramid|amdahl|uunet}!altos!ti /// \\\ The opinions herein are not necessarily those of Altos. ////////\
dylan@ibmpcug.co.uk (Matthew Farwell) (10/12/90)
In article <1990Oct11.121032.16745@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <1990Oct10.211911.9236@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >>cpcahil@virtech.UUCP (Conor P. Cahill) writes: >>> The one included with System V R3.2 and later is the result of the Xenix >>> tar being merged back into the AT&T tar. >>Does the generic 3.2 tar support the 'q' option that SCO does (though >>*un*documented) which says something like "stop after the first matching >>file" ? >A simple test of "tar -qvf -" before posting the question would have >answered your question: > > tar: q: unknown option > Usage:..... This is assuming, of course, that you had access to a system which ran a generic SVR3.2...... Which I don't believe ronald does.... Dylan. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| ...!uunet!ukc!ibmpcug!dylan Harrow HA1 4LQ England | CONNECT - Usenet Access in the UK!! Phone: +44 81-863-1191 | Sun? Don't they make coffee machines?
cpcahil@virtech.uucp (Conor P. Cahill) (10/12/90)
In article <4217@altos86.Altos.COM> ti@altos86.UUCP (Ti Kan) writes: > >tar cv and xv should output the file listing to stderr, not stdout. >AT&T's Sys V.3 source code is correct, but many 386 UNIX vendors did >not use AT&T's tar sources. Rather, they used the Microsoft tar source >which came from Xenix. The Microsoft tar has the wrong behavior of >writing the file listing to stdout. Being one to nitpick, AT&T's System V.3.x (where x < 2) probably had the correctly behaving tar. However, with the introductin of 3.2 AT&T's source had the bug. >On a side note, the V.4 tar source from AT&T appears to be a modified >version of Microsoft's tar, not AT&T V.3's. Thus, the aforementioned >bug is re-introduced into AT&T's own sources! Ugh. That's because they brought forward the 3.2 sources to the 4.0 baseline (at least for some parts of the system). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
ronald@robobar.co.uk (Ronald S H Khoo) (10/12/90)
cpcahil@virtech.UUCP (Conor P. Cahill) writes: > A simple test of "tar -qvf -" before posting the question would have > answered your question: How ? I'm a SCO user -- I don't *have* interactive to type it at. -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
ewv@craycos.com (Eric Varsanyi) (10/13/90)
In article <4217@altos86.Altos.COM> ti@altos86.UUCP (Ti Kan) writes: >On a side note, the V.4 tar source from AT&T appears to be a modified >version of Microsoft's tar, not AT&T V.3's. Thus, the aforementioned >bug is re-introduced into AT&T's own sources! Ugh. Looking at the SVR4 tar on load K18.2 (for the 3B2) it does seem to be doing things correctly. If '-' is specified as the output file all messages written with the '-v' option will go to stderr (otherwise they go to stdout). -- -Eric Varsanyi (ewv@craycos.com) Cray Computer Corporation
karl@robot.in-berlin.de (Karl-P. Huestegge) (10/21/90)
In <4217@altos86.Altos.COM> ti@altos86.Altos.COM (Ti Kan) writes: >>In article <3494@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >>>Can it really be that under Interactive "tar cv" writes the names of the >>>files to standard output, so that "tar cvf -" produces a corrupted file? >> >>>Is this standard System V brain damage? >>I believe it is. (Interactive would not be so stupid as to add this >>blunder to the code). >[...] came from Xenix. The Microsoft tar has the wrong behavior of >writing the file listing to stdout. >For the record, all current Altos UNIX (not Xenix) releases for all its >systems has the correct tar behavior. None of The 286 and 386 SCO Xenix Versions I used (2.1 to 2.3.2) had this behavior. All tar's work correct and output the verbose options to stderr. Karl-Peter Huestegge karl@robot.in-berlin.de Berlin Friedenau ..fub!utopia!robot!karl