HDTenEightyP/NetNews huggingface dataset:
From: hoymand@wissago.uwex.edu (Dirk Herr-Hoyman)
Subject: gdbm 1.5 bug on Next 3.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Dec 1992 04:04:27 GMT

I have found a problem when building gdbm 1.5 on a Next running nextstep 3.0.   
Here is what I see:

wissago{hoymand}42: make all
cc -g  -c global.c
rm -f gdbm.a
ar q gdbm.a dbminit.o delete.o fetch.o store.o seq.o dbmopen.o dbmdelete.o  
dbmfetch.o dbmstore.o dbmseq.o  dbmclose.o dbmdirfno.o dbmpagfno.o gdbmopen.o  
gdbmdelete.o gdbmfetch.o  gdbmstore.o gdbmclose.o  gdbmreorg.o gdbmseq.o   
bucket.o falloc.o findkey.o global.o hash.o update.o version.o
ar: creating gdbm.a
if [ -f /usr/bin/ranlib -o -f /bin/ranlib ];  then ranlib gdbm.a; fi
cc -g   -o testgdbm testgdbm.o gdbm.a 

/bin/ld: Undefined symbols:
_gdbm_errno
*** Exit 1
Stop.

The problem disappears when I change the declaration of gdbm_errno in  
global.c to:

/*gdbm_error gdbm_errno;*/
gdbm_error gdbm_errno=GDBM_NO_ERROR;

Everything seemed to work correctly with this change in place.

My local Next support contacted Next and this was their response:

Begin forwarded message:

> Date: Mon, 28 Dec 92 09:35:39 -0600
> From: Don Thomson <thomson@zazen.macc.wisc.edu>
> To: hoymand@wissago.uwex.edu
> In-Reply-To: Dirk Herr-Hoyman's message of Wed, 23 Dec 92 08:38:45 -0600  
<9212231438.AA03175@wissago.uwex.edu>
> Subject: External reference problem
> 

> >> Thanks for following up on this one Don.  One more bit of evidence.  I  
used
> >> otool on the library (otool -tv) and found that the symbols weren't even  
in
> >> the library.
> 

> > From: John_Immordino@NeXT.COM (John Immordino)
> > Date: Wed, 23 Dec 92 11:48:55 -0800
> > To: <thomson@zazen.macc.wisc.edu>
> > Subject: [37539] External reference problem
> > 

> > Don -
> > 

> > Well the response came back almost immediately.  Apparently, ANSI C  

> > states that this
> > 

> > gdbm_error gdbm_errno;
> > 

> > is a tentative definition and that this
> > 

> > gdbm_error gdbm_errno = GDBM_NO_ERROR;
> > 

> > is a real definition.  You can either change the code or use 

> > 

> > 

> > ranlib -c 

> > 

> > 

> > on the library created with the old code.  I've tested both and they  

> > both work.
> > 

> > John Immordino
> > NeXT Developer Support
>  

> ----- Don Thomson ----- MACC, 1210 W. Dayton, Madison, WI  53706  
-------------
>     (608) 262-0138      thomson@zazen.macc.wisc.edu /  
thomson@wiscmacc.bitnet
> 

---
Dirk Herr-Hoyman
Internet Publishing Specialist
University of Wisconsin - Extension
hoymand@wisplan.uwex.edu
608-262-0518 (voice)
608-265-2530 (fax)



Newsgroups: gnu.utils.bug
From: rob@dinner.asrc.albany.edu (Robert D. Seals)
Subject: Oleo install problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 05:10:53 GMT

Trying to build oleo-1.2 on an IBM RS/6000 (AIX 3.2.3), I encountered
several difficulties:

I ran ./configure, then changed prefix to /usr/gnu, and CFLAGS to -O.
gcc 2.2.1 is on the system.

1. gcc got fatal signal 6 when compiling regions.c, so I recompiled it
without optimization and got no complaints. [I'm not going to report
this gcc bug to bug-gcc since the current gcc is 2.3.3]

2. utils.c gets compile errors (namlen) with gcc and system's cc, but
not system 'bsdcc', so I used that.

3. io-utils.c has a function 'div' which conflicts with one in the
system, defined in stdlib.h (!). I changed 'div' to 'loc_div' without
incident.

4. io-x11.c redefines getenv in a different way than stdlib.h (no 'const'),
so I ifdef'ed it out.

5. You don't need -ltermlib on AIX.

6. ualarm.o apparently needs to be included in the 'objs' line in
Makefile, since 'alarm_interval' can't be resolved.

7. gcc complains a couple times about assignments between incompatible
types, but they are warnings, and on rs/6000, they shouldn't matter.

8. The executable doesn't work! On the console, with DISPLAY defined,
when I start oleo, I get the startup message in my xterm, then
nothing. No windows, nuttin. Then only thing I can do is send
2 ^C or ^Z. Perhaps this is just ignorance on my part.

9. The INSTALL file refers to a mailing address in README, but
README doesn't show a mailing address.

rob

Newsgroups: gnu.utils.bug
From: schwartz@groucho.cs.psu.edu (Scott Schwartz)
Subject: regex-0.11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 11:56:06 GMT

regerror should check the index of the error code before 
indexing into the table of error strings.

Newsgroups: gnu.utils.bug
From: dla@se05.wg2.waii.COM (Doug Acker)
Subject: gzip-0.5
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 05:20:41 GMT

Try compress an empty file ...


i.e.   touch foo
       gzip foo

you get foo.z that is 20 bytes big .....

Newsgroups: gnu.utils.bug
From: ber@fid.morgan.COM (Brian Redman)
Subject: problem with included makefiles
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 15:47:47 GMT

I appreciate GNU make, your past and continuing efforts.

I compiled version 3.62 on an rs6000 running AIX 3.2.  Here is my Makefile:


yomomma:
	echo yomomma

include /dev/null

The documentation doesn't seem to point out that GNU make attempts to
"make" all the included files before it begins processing targets.
Not only that, it appears to try to make them in the reverse of the order
they're included.
In the above example I would expect "yomomma" to be executed before
/dev/null was read.  This is a trivial example but the problem came
about when I wanted to simulate the behavior of sunos's .INIT target.
On sunos 4.1.3 make, .INIT is the first target processed and in my application
it makes the file which I want to include.  Specifically I'm using imake
to make imake.  (you can stop reading here, I'll understand)

The file I want to include depends on Makefile.  Unfortuately (in this case)
imake sees to it that Makefile depends on the program I want to build (in this
case imake).  My .c.o rules try to place the binary in a machine specific
subdirectory.  The rub is that that subdirectory is created by the first
dependency (the thing I'm trying to do to simulate .INIT).  But the first
dependency isn't made first.  The last included file is made first.  Catch-22.

The first paragraph of section 3.1 suffers from serious omissions.  The
first thing make (possibly before reading the makefile) does is try to
make the makefile, then before processing the first rule it tries to
make the included files.
I think the documentation ought to discuss more thoroughly how include files
are handled.  My thought is to append "include .INIT" to the end
of the Makefile.  Not elegant but maybe it'll work.


	brian redman

Newsgroups: gnu.utils.bug
From: karl@owl.HQ.ILeaf.COM
Subject: /etc/rmt
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 19:06:44 GMT

tar 1.11.1 tries to install rmt as /etc/rmt.  I'd suggest this default
to something using $(exec_prefix).

Newsgroups: gnu.utils.bug
From: rsherme%diamond@relay.nswc.navy.mil (Russel Shermer (R43))
Subject: 2 more notes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 12:13:39 GMT

	Hello again,

On the SGI's:

Config problem #1:
ualarm.c the line
#include <time.h>
needs to be
#include <sys/time.h>
I suspect this to be true for most sysV machines.

Config problem #2:
the line
#include <alloca.h>
must appear as a header to all files
that call alloca().

	---Russ




Newsgroups: gnu.utils.bug
From: jloup@chorus.FR (Jean-loup Gailly)
Subject: Re: gzip bug - cannot unzip zipped files
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 17:26:31 GMT

Here is a patch to fix the bug that was reported in gzip 0.5:

   read error on bug.z: No such file or directory

The bug is only in gunzip. The .z files created by gzip 0.5 are
correct. I will release soon a new version 0.6 fixing this bug and a
few portability problems.

Thanks a lot for your help.

Jean-loup Gailly
jloup@chorus.fr

*** inflate.c~  Tue Dec 29 16:15:12 1992
--- inflate.c   Tue Dec 29 16:15:45 1992
***************
*** 921,926 ****
--- 921,934 ----
    } while (!e);


+   /* Undo too much lookahead. The next read will be byte aligned so we
+    * can discard unused bits in the last meaningful byte.
+    */
+   while (bk >= 8) {
+     bk -= 8;
+     inptr--;
+   }
+
    /* flush out slide */
    flush_output(wp);


Newsgroups: gnu.utils.bug
From: dkarr@sierra.COM (David Karr)
Subject: recursive dependencies
Organization: Sierra Geophysics,  Kirkland WA
Distribution: gnu
Date: Sun, 27 Dec 1992 22:08:09 GMT

(I would have written this in gnu.make.help or gnu.utils.help, but neither
of those existed.)

Is there any way to have Gmake figure out recursive dependencies?  In other
words, if I have two dependencies like this:

    source.o: source.cc
    source.cc: inc.h

and "inc.h" is changed, I would like it to figure out that it needs to
recompile "source.cc" to make "source.o".  So far, my experiments show that
this doesn't work.

--
David M. Karr
Sierra Geophysics, Inc.
ARPA: dkarr@sierra.com, UUNET: uunet!sgihbtn!dkarr
Phone: (206) 822-5200 (x343)

Newsgroups: gnu.utils.bug
From: rsherme%diamond@relay.nswc.navy.mil (Russel Shermer (R43))
Subject: Config bug in oleo-1.2 on SGIs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 11:46:39 GMT

	Hi,

I had to add some lines (a definite kludge) to sysdef.h.  (2nd
paragraph contains the added lines.  The lines 1st and 3rd delimit
position).  The problem is that when RETSIGTYPE is set to void, SIGRET
does not get set to "return" but gets set to "return 0" instead.  My
fix is not legit but merely a hack to get it to work for now.

	---Russ

>#ifndef RETSIGTYPE
>#define RETSIGTYPE void
>#define SIGRET  return
>#else
>#define SIGRET  return 0
>#endif /* RETSIGTYPE */

#ifdef RETSIGTYPE
#if (RETSIGTYPE == void)
#define SIGRET return
#endif
#endif

>#ifndef VOIDSTAR
>#define VOIDSTAR void *
>#endif


Newsgroups: gnu.utils.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: oleo 1.2: ualarm confusion
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 18:25:08 GMT

When configuring, oleo 1.2 checks twice for the existence of ualarm.
It shouldn't have to check more than once.

Looking at the source code, ualarm is always present (perhaps because it is
defined in ualarm.c), so HAVE_UALARM is a misnomer.  HAVE_UALARM means ``was
ualarm provided by the underlying system?'', not ``do we have ualarm?''.
This is confusing.  Perhaps the substituted function should have a different
name, since it isn't a complete replacement for ualarm.

	sh configure
	checking for gcc
	checking how to run the C preprocessor
	checking for bison
	checking for install
	checking for POSIXized ISC
	checking for System V
	checking for return type of signal handlers
	checking for ANSI C header files
	checking for X11/X.h
	checking for working alloca.h
	checking for alloca
	checking for _doprnt
	checking for random
	checking for ualarm <---
	checking for ualarm <---
	checking for setitimer

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Problem with cp -pf and hard links (bis)
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 1 Jan 1993 18:52:13 GMT

Here is a script, hopefully reproducible, demonstrating the problem I
recently described in a previous message.  Before trying it, execute
first the equivalent of (I'm using bash):

	cp() { /usr/local/gnubin/cp -i $*; }
	rm() { /usr/local/gnubin/rm -i $*; }

If I copy x3 over x1, x2 will be changed too (this is nice):

~) echo a > x1
~) ln x1 x2
~) echo b > x3
~) v x*
-rw-r-----   2 pinard   other           2 Jan  1 13:39 x1
-rw-r-----   2 pinard   other           2 Jan  1 13:39 x2
-rw-r-----   1 pinard   other           2 Jan  1 13:40 x3
~) cp -p x3 x1
/usr/local/gnubin/cp: overwrite `x1'? y
~) v x*
-rw-r-----   2 pinard   other           2 Jan  1 13:40 x1
-rw-r-----   2 pinard   other           2 Jan  1 13:40 x2
-rw-r-----   1 pinard   other           2 Jan  1 13:40 x3
~) cat x2
b


Clean up before retrying:

~) rm x*
/usr/local/gnubin/rm: remove `x1'? y
/usr/local/gnubin/rm: remove `x2'? y
/usr/local/gnubin/rm: remove `x3'? y


I have to revert to using -f for the following to work, the hardlink
relationship is broken.  Copying x3 over x1 does not change x2 (this
is sad):

~) echo a > x1
~) ln x1 x2
~) chmod 440 x1
~) echo b > x3
~) v x*
-r--r-----   2 pinard   other           2 Jan  1 13:41 x1
-r--r-----   2 pinard   other           2 Jan  1 13:41 x2
-rw-r-----   1 pinard   other           2 Jan  1 13:41 x3
~) cp -p x3 x1
/usr/local/gnubin/cp: overwrite `x1', overriding mode 0440? y
/usr/local/gnubin/cp: cannot create regular file `x1': Permission denied
~) cp -pf x3 x1
~) v x*
-rw-r-----   1 pinard   other           2 Jan  1 13:41 x1
-r--r-----   1 pinard   other           2 Jan  1 13:41 x2
-rw-r-----   1 pinard   other           2 Jan  1 13:41 x3
~) cat x2
a
~) cat x1
b
~) 

-- 
Franc,ois Pinard       ``Happy GNU Year!''      pinard@iro.umontreal.ca
(514) 588-4656                                   ...!uunet!iros1!pinard
About the League for Programming Freedom?  Email me or lpf@uunet.uu.net

Newsgroups: gnu.utils.bug
From: jik@aktis.COM (Jonathan I. Kamens)
Subject: GNU tar gnu.c doesn't check malloc return value
Organization: Gnus Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 08:48:04 GMT

For GNU tar version 1.11.1.

*** 1.1	1992/12/30 18:44:33
--- gnu.c	1992/12/30 18:47:04
***************
*** 98,111 ****
  {
  	struct dirname *dp;
  
! 	dp=(struct dirname *)malloc(sizeof(struct dirname));
! 	if(!dp)
! 		abort();
  	dp->next=dir_list;
  	dir_list=dp;
  	dp->dev=dev;
  	dp->ino=ino;
! 	dp->name=malloc(strlen(name)+1);
  	strcpy(dp->name,name);
  	dp->dir_text=text;
  	dp->allnew=0;
--- 98,109 ----
  {
  	struct dirname *dp;
  
! 	dp=(struct dirname *)ck_malloc(sizeof(struct dirname));
  	dp->next=dir_list;
  	dir_list=dp;
  	dp->dev=dev;
  	dp->ino=ino;
! 	dp->name=ck_malloc(strlen(name)+1);
  	strcpy(dp->name,name);
  	dp->dir_text=text;
  	dp->allnew=0;
***************
*** 421,432 ****
  				n_strs++;
  				p_buf+=tmp;
  			}
! 			vec=(char **)malloc(sizeof(char *)*(n_strs+1));
  			for(p_vec=vec,p_buf=buf;*p_buf;p_buf+=strlen(p_buf)+1)
  				*p_vec++= p_buf;
  			*p_vec= 0;
  			qsort((PTR)vec,n_strs,sizeof(char *),dirent_cmp);
! 			new_buf=(char *)malloc(p_buf-buf+2);
  			for(p_vec=vec,p_buf=new_buf;*p_vec;p_vec++) {
  				char *p_tmp;
  
--- 419,430 ----
  				n_strs++;
  				p_buf+=tmp;
  			}
! 			vec=(char **)ck_malloc(sizeof(char *)*(n_strs+1));
  			for(p_vec=vec,p_buf=buf;*p_buf;p_buf+=strlen(p_buf)+1)
  				*p_vec++= p_buf;
  			*p_vec= 0;
  			qsort((PTR)vec,n_strs,sizeof(char *),dirent_cmp);
! 			new_buf=(char *)ck_malloc(p_buf-buf+2);
  			for(p_vec=vec,p_buf=new_buf;*p_vec;p_vec++) {
  				char *p_tmp;
  

Newsgroups: gnu.utils.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: gzip-0.5
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 20:46:57 GMT

   Resent-Date: Tue, 29 Dec 92 23:20:41 CST
   Resent-Message-Id: <9212310309.AA06571@raisin-nut>
   Date: Tue, 29 Dec 92 23:20:41 CST
   From: dla@se05.wg2.waii.com (Doug Acker)
   Sender: gnulists@ai.mit.edu
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   Try compress an empty file ...


   i.e.   touch foo
	  gzip foo

   you get foo.z that is 20 bytes big .....


Perhaps it could be smaller than 20 bytes,
but it must be nonempty, since it needs to have
at least a magic number saying what compression format
is used.

compress sometimes refuses to compress a file if the output
is larger than the input.  This is very bad design.
It makes the program unpredictable, unreliable.
People can normally tell just by the file name that a file
is already compressed.

As for empty files, people are not likely to lose a lot of disk space
by compressing empty files.  It is not an important issue.


Newsgroups: gnu.utils.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Oleo -- a few well-intentioned criticisms
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 2 Jan 1993 18:50:56 GMT

    what's desperately needed is a set of keybindings
    that replicates the Lotus interface.

I wish we could do this, but (as you know, being an LPF member) it is
illegal.

I hope you won't decide to encourage business for Lotus because Lotus
has taken away our freedom.  In the long run, it's a mistake to reward
aggression.

As for the other issues, thanks for offering suggestions.

Upgrading the documentation is in the hands of the users, because we
have no one available to do it, and no funds to hire anyone now.  I
hope someone will volunteer (hint hint) to write this.
From: pinard@icule.UUCP (Francois Pinard)
Newsgroups: gnu.utils.bug
Subject: regex.c and CHAR_SET_SIZE
Date: 27 Dec 92 14:52:27 GMT
Reply-To: pinard@iro.umontreal.ca
Distribution: gnu
Organization: GNUs Not Usenet

In regex.c 0.11, CHAR_SET_SIZE is defined only if SYNTAX_TABLE is not
defined.  As a matter of convenience, why not simply:

#ifndef CHAR_SET_SIZE 256
#define CHAR_SET_SIZE 256
#endif

after the SYNTAX_TABLE if.  So one could redefine it if needed, but
not being forced to.  Even better, one could parallel an:

extern int char_set_size;

to:

extern char *re_syntax_table;

so the user could dynamically provide both the table and its size.

-- 
Franc,ois Pinard       ``Happy GNU Year!''      pinard@iro.umontreal.ca
(514) 588-4656                                   ...!uunet!iros1!pinard
About the League for Programming Freedom?  Email me or lpf@uunet.uu.net
Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: wdiff 0.04 & signal.h
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 31 Dec 1992 15:03:17 GMT

wdiff 0.04 doesn't compile on a 486 running ISC 2.2.1 with gcc 2.3.2,
because <signal.h> requires <sys/types.h>.  Here is the (trivial) fix.

Tue Dec 29 07:17:59 1992  Karl Berry  (karl@cs.umb.edu)

	* wdiff.c: Include <sys/types.h> before <signal.h>.

*** ./ORIG/wdiff.c	Wed Dec 23 21:10:28 1992
--- ./wdiff.c	Tue Dec 29 07:18:19 1992
***************
*** 65,70 ****
--- 65,71 ----
  #endif /* HAVE_TPUTS */
  
  #include <setjmp.h>
+ #include <sys/types.h>
  #include <signal.h>
  #ifndef RETSIGTYPE
  #define RETSIGTYPE void

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Bison version in produced parser, please
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 2 Jan 1993 03:18:31 GMT

Bison should output, in the generated parser, some identification of
the precise Bison release version producing it, would it be a C
comment.  Alternatively, the Bison precise release version could be
commented in the skeleton file.

It sometimes matters to know if a generated parser from a distribution
has some bison problem resolved, or not, when we know which precise
release solved it.  A comment costs nothing, and might be useful.

For reference, I'm using GNU Bison 1.19.

-- 
Franc,ois Pinard       ``Happy GNU Year!''      pinard@iro.umontreal.ca
(514) 588-4656                                   ...!uunet!iros1!pinard
About the League for Programming Freedom?  Email me or lpf@uunet.uu.net

Newsgroups: gnu.utils.bug
From: gnulists@ai.mit.edu
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 27 Dec 1992 17:45:17 GMT

tar 1.11.1 has an annoying habit of printing out a number instead of a name
if it can't find the directory to untar into...

Here's a patch: (I wish everything was this simple!)

leisner@annapurna$ !rcsdiff
rcsdiff -c tar.c
===================================================================
RCS file: tar.c,v
retrieving revision 1.1
diff -c -r1.1 tar.c
*** 1.1 1992/12/27 23:55:25
--- tar.c       1992/12/28 00:07:12
***************
*** 433,439 ****
  #if 0
                case 'C':
                        if(chdir(optarg)<0)
!                               msg_perror("Can't change directory to %d",optarg);
                        break;
  #endif
  
--- 433,439 ----
  #if 0
                case 'C':
                        if(chdir(optarg)<0)
!                               msg_perror("Can't change directory to %s",optarg);
                        break;
  #endif
  
***************
*** 1051,1057 ****
        if (nlp->fake)
          {
            if (nlp->change_dir && chdir (nlp->change_dir))
!             msg_perror ("Can't change to directory %d", nlp->change_dir);
            namelist = 0;
            return 1;
          }
--- 1051,1057 ----
        if (nlp->fake)
          {
            if (nlp->change_dir && chdir (nlp->change_dir))
!             msg_perror ("Can't change to directory %s", nlp->change_dir);
            namelist = 0;
            return 1;
          }


--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom

Newsgroups: gnu.utils.bug
From: vsh@etnibsd.UUCP (Steve Harris)
Subject: tar-1.11.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 24 Dec 1992 16:30:08 GMT

I just got tar-1.11.1 from uunet.  I have been using version 1.10, till
now.  Here is a bug report, a suggestion, and some enhancements I will
get to next year.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Bug report:

    tar -dM -L XXX

reports DATA errors on files that span multiple volumes.  Extraction
works fine, i.e., the extracted file matches exactly.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Suggestion:

    Since written documentation is lacking, help message should be
    as useful as possible.  I suggest you change it as follows:

tar.c
687c687
< -L, --tape-length LENGTH change tapes after writing LENGTH\n\
---
> -L, --tape-length N	change tapes after writing N*1024 bytes\n\


    (there probably are other changes that could be made, I'm sure
     I'll think of them as soon as I post this email ;-)


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Future contributions:

Options I will add when I have the time:

    --extract-here

	extract files into current directory (i.e., strip all
	characters up to and including the final '/' in the filename).

    --unlink

	silently unlink file before extracting from archive.


Here's an idea I haven't worked out completely:

    When doing -xv, print the name of each file as it is extracted, but
    delay printing the final newline until the extraction of the file
    is complete.  Thus, if I do: "tar -xv foo", and foo is a large file
    in the middle of a long archive, I will know when the extraction is
    complete and I can safely kill the tar process.  (Of course, this
    change will require extra work for error messages).


If you already have any of these implemented (or plan to), let me know
and I won't bother.

Happy Xmas!

-- 
.. Steve Harris - Eaton Corp. - Beverly, MA - vsh%etnibsd@uunet.uu.net

Newsgroups: gnu.utils.bug