HDTenEightyP/NetNews huggingface dataset:
From: sow@cad.luth.SE (Sven-Ove Westberg)
Newsgroups: gnu.utils.bug
Subject: ucsb_info in Finger 1.35 release.
Date: 8 Sep 92 17:03:34 GMT
Distribution: gnu
Organization: University of Lulea, Sweden

The file ../finger.h is missed in the distibution. Did anyone
know where I can find one?


Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Newsgroups: gnu.utils.bug
From: cis@galton.uchicago.edu (Cis Administrator)
Subject: Possible bug in GNU make
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 21:01:02 GMT

GNU make 3.58 seems not to ignore trailing white space when a variable
definition is followed by a comment. For example, with the makefile

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

var = this is a test     # a variable definition, followed by a comment
show:
	@echo "'$(var)'"

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

the command "make show" produces the output

'this is a test     '


I was expecting 

'this is a test'

That's what the SUN version of make produces, and it's what page 53 of
the GNU make manual (Edition 0.26 Beta, 1/20/1990) seems to suggest: 
"A variable name may be any sequence [of] characters not containing `:', 
`#', `=', or leading or trailing whitespace." (The word "of" is missing
in the manual.)

Is this a bug, or a feature?

Newsgroups: gnu.utils.bug
From: asmith@synoptics.com (Andrew Smith)
Subject: binutils-2.0 problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 16:29:00 GMT

I found some problems with ld 2.0 configured for "coff-m68k"


1. ld now appears to require LDEMULATION to be set to something. The list of
	acceptable values in the manual are not accepted any more: document
	needs updating to say that "sun3", "sun4" etc. are now accepted instead.

2. ld now issues a "warning, xxxxxx architecture of input file `yyyyy' incompatible
	with unknown output" when none of TARGET or OUTPUT_FORMAT and LDEMULATION
	is specified. 
	When configured for "coff-m68k", no mt file is found in the config directory
	and so the variable EMUL is not set in the Makefile. Thus, the default
	target ends up as "unknown" which means that ld must be fed with a 
	target by hand. 
	This is often the case when running ld in partial-link mode (ld -r) without 
	a script file. The trouble is, it is only a *warning*, not an *error* even 
	though garbage output file is produced (doesn't output any code, 
	although symbol table info is output correctly!). When running with
	ld -r, can this "warning" be turned off and the output file format
	default to the current input file architecture? This is how 1.94-beta
	behaved I think.

3. I copied config/m68k.mt config/m68k-coff.mt in order to get "sun3" as the
	default target (which *does* seem somewhat bogus, as the comment in that
	file says!).

4. ld -c xxx.sc for an "MRI-compatible" script file now doesn't accept so
	many of the script commands e.g. OUTPUT_FORMAT("coff-m68k") is now
	illegal, when 1.94-beta accepted it. Maybe this is now correct behaviour
	but I couldn't find any mention of this in ChangeLog. [ ld -

5. The Makefile.in for ld needs to be updated so that Makefile depends on
	the relevant config/mt-* files and so that ldmain.c depends on Makefile


Other than that, I think that the linker performs correctly for the following
scenarios:
		a.out -> coff     in partial-link mode (ld -r)
		coff -> coff	  in normal mode (produce absolute output).

Next, I will try it with a mixture of a.out and coff inputs, as well as with
a.out and coff archive libraries as input - these did not use to work with
binutils-beta-1.94.



Andrew Smith
Distributed Network Systems
SynOptics Communications Inc.




P.S. Is there any chance of a new GAS to take advantage of the new opcodes and
	use of MOTOROLA-style "move.b" opcodes in
	binutils-2.0/include/opcode/m68k.h ??? I put some patches up a few
	weeks ago but these will not work on this new style of m68k.h file.

Newsgroups: gnu.utils.bug
From: cudcv@csv.warwick.ac.UK (Rob McMahon)
Subject: finger-1.35 - locks up
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 16:19:13 GMT

finger-1.35 / Sun4 / SunOS-4.1.2 / gcc-2.2.2 -O2

Fingerd seems to quickly lock up.  (In fact it appears it only checks other
hosts on the network when I send it a `HUP'.)  Then you start getting the 

/usr/local/etc/fingerdir/hostdata: file has not changed in  0:10:38

message.  An `strace' of the daemon gives the last few system calls as

------------------------------------------------------------------------------
open("/usr/local/etc/fingerdir/clients".., WRONLY|CREAT|TRUNC, 666) = 3
write(3, "bramble.csv.warwick.ac.uk\0\0\0\0\0\0\0".., 84) = 84
write(3, "clover.csv.warwick.ac.uk\0\0\0\0\0\0\0\0".., 84) = 84
write(3, "lily.csv.warwick.ac.uk\00.0)\0\0\0\0\0".., 84) = 84
write(3, "limpid.csv.warwick.ac.uk\0on\0\0\0\0\0".., 84) = 84
write(3, "orchid.csv.warwick.ac.uk\0\0\0\0\0\0\0\0".., 84) = 84
write(3, "shark.csv.warwick.ac.uk\0\0\0\0\0\0\0\0\0".., 84) = 84
write(3, "thistle.csv.warwick.ac.uk\0\0\0\0\0\0\0".., 84) = 84
close(3) = 0
sigcleanup() = 0
sigpause(0
------------------------------------------------------------------------------

A `finger .clients' gives

------------------------------------------------------------------------------
/usr/local/etc/fingerdir/clientstatus: file has not changed in  0:13:24
There are 7 clients served by orchid.

Hostname                 Address         Status           Idle Time
bramble.csv.warwick.ac.uk 137.205.192.10  up(3 users)      
clover.csv.warwick.ac.uk 137.205.192.6   up(47 users)     
lily.csv.warwick.ac.uk   137.205.192.7   up(18 users)     
limpid.csv.warwick.ac.uk 137.205.193.194 idle(5 users)    2 days, 21:41:52
orchid.csv.warwick.ac.uk 137.205.192.5   idle(5 users)     0:03:24
shark.csv.warwick.ac.uk  137.205.193.193 up(4 users)      
thistle.csv.warwick.ac.uk 137.205.128.4   idle(3 users)     0:07:24
------------------------------------------------------------------------------

Any ideas ?

Cheers,

Rob

Newsgroups: gnu.utils.bug
From: bmw@isgtec.COM (Bruce M. Walker)
Subject: a few tar-1.11 bugs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 07:30:25 GMT

I built tar-1.11 on a Sun Sparcstation SunOS 4.1.1.

I found several indented cpp-directives in buffer.c and extract.c; after
removing leading spaces, these compiled OK.  Search for:

    /^ [ ]*#/


I also had to add a target in Makefile.in (and so the Makefile):

    getdate.c: getdate.y
	    yacc getdate.y
	    mv y.tab.c getdate.c


Small point: Makefile says:

    # getdate.y has 8 shift/reduce conflicts.

But I get "9 shift/reduce conflicts" from yacc.


Lastly:  I notice there's no pre-yacc'ed getdate.c in the distribution
tar file; how do you expect PC users to build it?

-- 
"The path of my life is strewn with cowpats from the devils' own herd."
                                          -- Edmund Blackadder II
bmw@isgtec.com   [ ...!uunet.ca!isgtec!bmw ]  Bruce Walker

Newsgroups: gnu.utils.bug
From: gie@charon.er.usgs.gov (Gerald I. Evenden)
Subject: Link failure for X11 procedures
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 13:15:31 GMT

I am very interested in your efforts with the "Font Utilities" package
and would gladly volunteer some effort.  However, ...

I attempted to install your material on a DELL 433DE with Dell's SVR4,
issure 2.2, but ran into snags---some curable, some not so easy.

In order to get all the material to compile I had to add -DSYSV compiler
flag for code from the "pbmplus" system.  They do not use the same
System V flagging you do.

The X11 code would not link!
For "limn" the linker's output reads:

Undefined                       first referenced
 symbol                             in file
 XtStrings                           xserver.o
 ld: limn: fatal error: Symbol referencing errors. No output written to limn
 make[1]: *** [limn] Error 1

And, similarly for "xbfe":

 Undefined                       first referenced
  symbol                             in file
  XtShellStrings                      .././lib/lib.a(xmessage.o)
  XtStrings                           char.o
  ld: xbfe: fatal error: Symbol referencing errors. No output written to xbfe
  make[1]: *** [xbfe] Error 1

Both these globals are hidden by the X11 macros and not directly referred
to by the application programmer.  Hacking around with various mods to
the loader flags and libraries produced zip results.

Note, I was using Dell's installation of gcc: -v yields:
> Reading specs from /usr/dell/gcc-2/lib/gcc-lib/i386v4/2.1/specs
> gcc version 2.1
and installed make-3.60 for this job.  It appears I will have to add
gawk also(?).

Outside of a Herculean effort to dig into your code and decipher your
methodology, there does not seem much that I can do without some
suggestions on your part.  Perhaps someone else has run into this
problem.

At the moment, I do not consider this to be the system's fault because I
have successfully installed several packages using X11, but using, I might
add, much more standard procedures.

Do you have any suggestions?

---------------------------------------------------------------------
Lastly, and please take this as friendly comment from someone who has
been hacking on machines since 1959, I take STRONG exception with most of
the statements in manual section 16.3 "Portability," p.78.  What you
have basically said: "it's my sandbox and I'll make up any rules I want!"
Unfortunately, a point-by-point critique would take too long here.

I am sorry if I have offended you, but having ported A LOT of software
makes me very sensitive to this issue.  What's worse, I took the risk
of alienation even though I would like remain on friendly, speaking terms.

Please forgive and old hacker.
---------------------------------------------------------------------

Ciao. (Jerry)
From: cliff@cs.cornell.edu (Cliff Krumvieda)
Newsgroups: gnu.utils.bug
Subject: regex-0.10 installation problems (with fixes)
Date: 11 Sep 92 05:54:04 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Howdy:

I found two installation bugs while trying to install the regex-0.10
info pages.  From the makefile:

======================================================================
install: regex.info
	-mkdir $(prefix) $(infodir)
	for i in *.info; do $(INSTALL_DATA) $$i $(infodir)/$$i; done

regex.info: regex.texinfo
	$(MAKEINFO) $<

regex.texinfo: xregex.texinfo regex.h
	rm -f $@
	gawk -f include.awk -vsource=regex.h <$< | expand >$@
	add-version $(version) regex.texinfo
	add-date regex.texinfo
	chmod a-w $@
======================================================================

Unfortunately:

 1.  The programs (scripts?) add-version and add-date were not
     included with the distribution (are they distributed with
     something else?). They are probably supposed to replace
     the strings "REPLACE-WITH-VERSION" and "REPLACE-WITH-DAY-MONTH-YEAR"
     with the appropriate values.
 2.  The info files "regex.info-{1,2}" do not get installed.  The
     for loop should be "for i in *.info*" instead of "for i in
     *.info".

						--Cliff Krumvieda
From: asmith@synoptics.com (Andrew Smith)
Newsgroups: gnu.utils.bug
Subject: GDB-4.x, BFD and m68k-coff symbols
Date: 11 Sep 92 19:05:31 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I have a problem with gdb-4.6 (same in 4.5) configured for m68k, COFF (don't
ask me how I got configure to work, that's another story). This uses BFD
configured for target "coff-m68k" and gdb configured to use a machine description
based on standard tm-m68k.h.

SYMPTOM:
	GDB appears to have no symbol information on .text symbols, including
filenames, and no type information on .data symbols.
	GDB has no problem reading COFF files normally when the complete tool-chain
uses COFF files.

DIAGNOSIS:
	When I dump symbols using "maintenance print symbols" there are no 
complete symbols known. Ditto for "maintenance print psymbols" for partially
read symbols. There are, however, 3797 symbols when I do "maintenance print
msymbols" for minimally-known symbols. There are also no known data types ("info
types").

	coffread.c seems to have problems with the 68k COFF format produced
by ld-2.0 (and by ld-beta-1.94). This COFF output is generated by ld-2.0 by 
translating A.OUT files produced by gas-1.92.3.

QUESTION:
	Is this what the warning that comes with BFD means by "losing symbolic
information in translation between formats"?


Andrew Smith
SynOptics Communications Inc.
Newsgroups: gnu.utils.bug
From: kirk@frnk411.UUCP (Kirk G. Kanzelberger)
Subject: Bison version 1.16
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 14:15:27 GMT

Some "long" command line options do not work, but instead provoke
the usage message.  They include --yacc and --verbose.

E.g., type:

% bison --verbose file.y       

(Contents of file.y irrelevant.)

--Kirk Kanzelberger	(kirk@franklin.com)

Newsgroups: gnu.utils.bug
From: tap@src.honeywell.com (Thomas A Peterson)
Subject: finger 1.35
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 01:29:27 GMT

Line 797 of in.fingerd.c has a fprintf that expects two strings but
only one is specified. I would recommned using 'gcc -Wall' to make
certain that errors of this type are caught. I use it religiously.

	fprintf (error_stream, "%s: Unable to read host data from %s\n",
		 HOSTSTAT);

Newsgroups: gnu.utils.bug
From: leisner@eso.mc.xerox.COM (Marty Leisner 311/? x?)
Subject: chown doesn't seem to work in fileutils-3.3
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Fri, 11 Sep 1992 13:46:56 GMT

I'm running chown from fileutils on a SS2 runing sunos 4.1.2.

It doesn't seem to work...

annapurna# cd /tmp
annapurna# echo >foo
annapurna# ls -l foo
-rw-r--r--   1 root     staff           0 Sep 11 09:47 foo
annapurna# which chown
/usr/gnu/bin/chown
annapurna# chown leisner foo
annapurna# ls -l foo
-rw-r--r--   1 root     staff           0 Sep 11 09:47 foo
annapurna# /etc/chown leisner foo
annapurna# ls -l foo
-rw-r--r--   1 leisner  staff           0 Sep 11 09:47 foo

Marty    leisner.henr801c@xerox.com 
          Member of the League for Programming Freedom 
 	Give me source or waste my time..

Newsgroups: gnu.utils.bug
From: seki@sysrap.CS.fujitsu.co.JP (Masahiro SEKIGUCHI)
Subject: binutils 2.0, ld, item count in DTOR_LIST
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 07:16:12 GMT

Dear binutils maintainers,

I guess ld in binutils 2.0 puts a wrong item count in DTOR_LIST.  It makes
__do_global_dtors() in libgcc2.c (in gcc 2.2.2 distribution) fail to work.

Environment:

	SunOS 4.0.3
	binutils 2.0 (configure sun3)
	gcc 2.2.2 (configure sun3 --with-gnu-as --with-gnu-ld)
	gas 1.38.1
	libg++ 2.2

Test case:

	The following program, ctor.cc, runs properly in the above
	environment with binutils 1.9.  With binutils 2.0, the
	destructor is not called.

    ctor.cc:

	#include <stdlib.h>
	#include <stdio.h>

	class Foo
	{
	 public:
	  Foo ()	{ printf( "init\n" ); }
	  ~Foo ()	{ printf( "exit\n" ); }
	};

	Foo foo;

	main ()
	{
	  printf( "running...\n" );
	  exit( 0 );
	}

    log (with binutils 2.0):

	% gcc ctor.cc
	% a.out
	init
	running...
	% gdb a.out

		... abridged ...

	(gdb) x/x __DTOR_LIST__
	0x208a8 <__CTOR_LIST__$e>:	0x00000000	<= this should be 1
	(gdb) 
	0x208ac <__DTOR_LIST__+4>:	0x00002342
	(gdb) 
	0x208b0 <__DTOR_LIST__+8>:	0x00000000
	(gdb) 

Regards,

Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: Configure [was: tar 1.11]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 11:00:17 GMT

   Date: Tue, 15 Sep 92 07:42:26 EDT
   From: pinard%icule.UUCP@Larry.McRCIM.McGill.EDU (Francois Pinard)
   Reply-To: pinard@iro.umontreal.ca

      Configure should correctly figure out the options to use, or it has
      a bug.  You should never need to edit the Makefile produced by GNU
      programs which come with configure.

   These statements look quite strong to me, too strong in fact!  I would
   certainly never expect `configure' to discover all peculiarities and
   strangenesses of all systems and installations.  I'm just speaking for
   Autoconf, which I know better.  There is a certain amount of ugliness
   beyond which GNU configurators should refuse to go.  In these cases,
   we should rather let users correct their own system installation,
   fiddle with config.status (thus, indirectly editing the Makefile), or
   even, in the worst cases, playing with the generated Makefile itself.

   As of now, Autoconf generates configure scripts which behave fairly
   well for almost all machines I work on.  This is a Good Thing, and am
   quite satisfied with it.  This is *far* better than doing all the
   configuring job by hand, as was done before.  It is a very helping
   tool.  But it does not pretend to do everything everywhere and anyhow.
   I feel David Mackenzie has the right attitude on this.

If a program cannot be completely configure by autoconf, then other
things need to be done.  GCC does not use autoconf, but it still needs
no editing to be installed; similarly for gdb and the other
cygnus-maintained utilities.  The coding standards make this quite
clear.  Users should never need to edit machine generated files.

	-mib




Newsgroups: gnu.utils.bug
From: R.K.Lloyd@csc.liv.ac.UK (Richard Lloyd)
Subject: Problems with GNU tar 1.11
Organization: Computer Science, Liverpool University
Distribution: gnu
Date: Mon, 14 Sep 1992 15:38:51 GMT

I got GNU tar 1.11 compiled on our HP 9000/720 machines running HP-UX 8.07, but not after some struggles:

[Note that if you set CFLAGS to any optimisation level (e.g. +O3), create.c
generates some very "dangerous" compiler warnings about optimisation. It's a
message about "differences between two arrays won't be properly optimised"]

Source code changes:

buffer.c and extract.c had some cpp directives indented by one column, which
isn't right.

SERIOUS BUG IN list.c:

The "v" option of "tar cvf" was only printing blank lines for the filenames !
After comparing 1.10 and 1.11, it was clear that a new variable had been
substituted in list.c (current_file_name) that wasn't properly set up. I
changed it back to the old 1.10 variable (although it was now arch_name rather than name) and tar cvf correctly printed the filenames out.

A modified version of tar 1.11 for HP-UX machines is now available from our
anonymous FTP site, ftp.csc.liv.ac.uk (138.253.42.172).

Archive Librarian,        E-mail: ftp@csc.liv.ac.uk
Computer Science Dept.,
Liverpool University, 
Merseyside, England,
Great Britain.





Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Configure [was: tar 1.11]
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 20:55:30 GMT

Hi, Michael.  I apologize for arguing, I'm really not wanting to start
a debate.

	 Michael> [...] Configure should correctly figure out the
	 Michael> options to use, or it has a bug.  [...]

      Franc,ois> These statements look quite strong to me [...]

   Michael> If a program cannot be completely configure by autoconf,
   Michael> then other things need to be done.  GCC does not use
   Michael> autoconf, but it still needs no editing to be installed;
   Michael> similarly for gdb and the other cygnus-maintained
   Michael> utilities.

If I understand things correctly, Cygnus configuration process relies
on a database expressing the capabilities or features of a wide
variety of systems.  Editing *is* indeed required somewhere for any
system unknown to the database, preferably by completing the database,
of course, or else, the lazy way, by adjusting the Makefile.

   Michael> The coding standards make this quite clear.  Users should
   Michael> never need to edit machine generated files.

I read the GNU standards as discouraging the edition of generated
files, not prohibiting it.  I would perfectly agree with you in a
world in which all possible machines/systems would be tabulated for
Cygnus configure or properly checked by Autoconf configure's.  What
triggered me to reply is that I just felt incomfortable to call a
*bug* the fact that one machine is unknown to the configure process.

Passing by, one of my pleasures with the GNU people is the ease of
exchanges about bugs.  I do not feel that perennial reluctance to
which non-free software providers accustomed us.  I find it bizarre to
see myself in a position in which I think we are going too far :-).

					Keep happy!

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU `wc -c' optimization
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 14:36:44 GMT

   Whether the optimization is worth putting in depends on how often
   people use wc -c, I guess.

The unsharing process, among others, makes frequent use of `wc -c'.
The `wc -c' usage which originated this thread was a `ddsplit' script
(for a particular machine where I may not install GNU split) where I
needed to know the overall size of a big file for computing the number
of resulting pieces.  It happened that the "size=`wc -c $input`" line
was taking a fair amount of real time.  Being curious, I just checked
how GNU wc would behave on the same problem and discovered it was not
as fast as I would have expected.

I think GNU wc should be made faster, would it be only for the
principle that GNU programs should do the best/proper thing in all
circumstances :-).

				Keep all happy!

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.utils.bug
From: brown@quorum.COM (Robert E. Brown)
Subject: GNU tar 1.11 bug ??
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 20:48:27 GMT

Running GNU tar version 1.11 on a Next with OS release 2.1 ...


The tar files that GNU tar 1.11 produces cannot be read by /bin/tar when files
have long names.


COMMAND:

  ~/etc/garbage/tar-1.11/tar cf - apps/illustrator3.0.1 | /bin/tar  tf -

OUTPUT:

apps/illustrator3.0.1/
apps/illustrator3.0.1/Gallery%20Disk/
apps/illustrator3.0.1/Gallery%20Disk/Gallery%20Installer
apps/illustrator3.0.1/Gallery%20Disk/_Gallery%20Installer
apps/illustrator3.0.1/Gallery%20Disk/PPD%20Installer
apps/illustrator3.0.1/Gallery%20Disk/_PPD%20Installer
apps/illustrator3.0.1/_Gallery%20Disk
apps/illustrator3.0.1/Program%20Disk/
apps/illustrator3.0.1/Program%20Disk/Adobe%20Illustrator%A8%203%20Installer
apps/illustrator3.0.1/Program%20Disk/_Adobe%20Illustrator%A8%203%20Installer
apps/illustrator3.0.1/Program%20Disk/Read%20Me%203.0.1%20%28TeachText%29
apps/illustrator3.0.1/Program%20Disk/_Read%20Me%203.0.1%20%28TeachText%29
apps/illustrator3.0.1/Program%20Disk/TeachText
apps/illustrator3.0.1/Program%20Disk/_TeachText
apps/illustrator3.0.1/_Program%20Disk
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/Adobe%20Separator%203.0.2
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/_Adobe%20Separator%203.0.2
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/Densitometer%20Control%20Chart
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/_Densitometer%20Control%20Chart
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/DrawOver%203.0
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/_DrawOver%203.0
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/PANTONE%A8%20Color%20Look%2Dup%20tables%A9%20/
././@LongLink
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/PANTONE%A8%20Color%20Look%2Dup%20tables%A9%20/PANT
tar: directory checksum error (11797 != 25861)
Broken pipe

Newsgroups: gnu.utils.bug