HDTenEightyP/NetNews huggingface dataset:
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: autoconf 1.1: tzname decl
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 12:56:08 GMT

Autoconf 1.1 on a 486 running Interactive Unix 2.2.1.  (Someone else
recently reported this problem for another system.)

In AC_TIMEZONE, the declaration of `tzname' is a problem. The decl in
AC_TIMEZONE is `extern char **tzname'.  This conflicts with the system
declaration

   extern char      *tzname[2];

and so Autoconf thinks the system doesn't have tzname.  This leads to
`date' dumping core when it tries to call tzname as a function, or
something like that.  (I didn't investigate it fully, since it seemed to
me the right fix was to make Autoconf think the system had tzname[] if
in fact it does.)

Anyway, since the declaration above is the one recommended by POSIX (for
some reason), I think we should support it.  I fixed it below simply by
removing the declaration from the test file to compile.

A more difficult but perhaps better alternative would be to see if
tzname is in fact declared in <time.h>, and, if not, put in the default
`extern char **tzname;'.  I don't know if there are in fact systems
which have tzname but do not declare it.

Sun Sep  6 10:33:07 1992  Karl Berry  (karl@hayley)

        * AC_TIMEZONE: do not declare tzname, as it might conflict with
          <time.h>.

*** acspecific.m4	Mon Aug 24 16:26:51 1992
--- /usr/local/gnu/lib/acspecific.m4	Sun Sep  6 10:15:36 1992
***************
*** 483,491 ****
  [struct tm tm; tm.tm_zone;], AC_DEFINE(HAVE_TM_ZONE), no_tm_zone=1)
  if test -n "$no_tm_zone"; then
  AC_COMPILE_CHECK(tzname, [#include <time.h>
! #ifndef tzname /* For SGI.  */
! extern char **tzname;
! #endif], [atoi(*tzname);], AC_DEFINE(HAVE_TZNAME))
  fi
  ])dnl
  dnl
--- 483,489 ----
  [struct tm tm; tm.tm_zone;], AC_DEFINE(HAVE_TM_ZONE), no_tm_zone=1)
  if test -n "$no_tm_zone"; then
  AC_COMPILE_CHECK(tzname, [#include <time.h>
! ], [atoi(*tzname);], AC_DEFINE(HAVE_TZNAME))
  fi
  ])dnl
  dnl

Newsgroups: gnu.utils.bug
From: jwz@lucid.com (Jamie Zawinski)
Subject: GNU Finger security question
Organization: Lucid, Inc., Menlo Park, CA
Distribution: gnu
Date: Tue, 8 Sep 1992 22:35:35 GMT

Can someone tell me whether any security testing has been done of GNU Finger,
specifically, is it subject to the same kinds of holes that the Morris worm
exploited in BSD finger?  I would *like* to modify our network firewall to
allow finger requests through, but not unless I have some assurance that
doing so is reasonably safe.

	-- Jamie
From: ezk@ground.cs.columbia.edu (Erez "HWank1" Zadok)
Newsgroups: gnu.utils.bug
Subject: Is ~/.fingerrc a big security hole in GNU finger 1.35?
Date: 7 Sep 92 04:12:24 GMT
Distribution: gnu
Organization: GNUs Not Usenet

THE SITUATION:

Installing GNU finger 1.35 with the SUPPORT_FINGERRC option will include
code to execute a user's ~/.fingerrc file, if it exists and it executable.


THE PROBLEM:

Isn't this a *BIG* security hole?  Yes I know, I can simply undefine this
macro and avoid the whole problem.  Anyway, I tried a few simple things to
see if I can break this feature to gain unauthorized access and other
privileges.  I was (happily) unable to.  This is not to say that it is safe
to use.  Someone else might find a way to break in.

My real problem is that in all of the README and doc files, not even once
was it mentioned that this might be a security hole.  You *know* that will
be the first thing people will complain, so why didn't you say something
about that?  Why didn't you say how this feature works exactly (I have
looked at the src.)  IMHO you aught to dispell some fears that will arise by
mentioning how safe or unsafe is it to use.  The supplied documents bluntly
avoided that issue.

Having said that, I want to thank you for adding this feature.  It is better
than the fifo hack that was posted a while ago to the net.  This is one neat
feature I always wished for.


MY SETUP:

- GNU finger 1.35
- Sun-4's: everything from 4/25 to 4/630.
- Compiler used: gcc 2.2.2
- OS version SunOS 4.1.2
- network configuration: class B, subnets, ciscos, "the usual" stuff.  Not
  really relevant to this bug.  We nfs-automount many directories.
- Patches: none.

Erez Zadok.
Mobile Computing Laboratory.
Columbia University Department of Computer Science.
---
A wank's morning starts one machine   | Arpa:   ezk@cs.columbia.edu
clock cycle after midnight.           | Usenet: ...!rutgers!columbia!cs!ezk
 -HebrewWank #1 (US meaning, not UK!) | Bitnet: erzus@cuvmb.BITNET
Newsgroups: gnu.utils.bug
From: rjc@devo.unify.COM
Subject: *fatal* bug in gas-1.38.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 6 Sep 1992 22:23:00 GMT

Software:  gcc-2.2.2 / gas-1.38.1
Hardware:  Sequent Symmetry (DYNIX 3.0.12)  (i386-sequent-bsd)

gcc-2.x is generating ".align 2" assembler statements apparently
before an assembler label in the text segment.  gas-1.38.1 is losing
by incorrectly emitting 0x00s for these statements instead of "nop"s!

The fatal result is that the resulting executable generated with these
tools will segfault on one of these incorrect instructions.

Someone has to have seen this before, who has a quick patch for gas?

-- 
Ronald Cole           +----------------------+  internet: rjc@unify.com
Software Engineer II  | This space for rent. |  uucp:     uunet!unify!rjc
Unify Corporation     +----------------------+  voice:    +1 916 928 6238
          "THE BILL OF RIGHTS --- Void where prohibited by law"

Newsgroups: gnu.utils.bug
From: kburton@iowa.UUCP (Kevin Burton)
Subject: Groff installation fails with gld 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 19:17:10 GMT

MACHINE: Sun SPARCstation 1
OS: SunOS 4.1.1
COMPILER: gcc 2.2.2(with groff gcc.patch), gas 1.38.1, gld 2.0/1.94

With gld 2.0 the configure script for groff 1.06 will fail

DESCRIPTION OF INCORRECT BEHAVIOUR:
When I type ./configure using gld 2.0 I get the message:

gcc -O is not installed correctly: static constructors and destructors do not work

When I revert back to gld 1.94-beta the problem goes away. The offending code
is the following:

extern "C" {
  void exit(int);
  void _exit(int);
}
int i;
struct A {
  char dummy;
  A() { i = 1; }
  ~A() { if (i == 1) _exit(0); }
};
A a;
main() { exit(1); }

It seems that the destructor is not getting called before or during the exit
cleanup process due to some linking problem.

Thanks.

-
Kevin Burton
Noran Instruments				voice: (608) 831-6511 x317
2551 West Beltline Highway, Room 532		  FAX: (608) 836-7224
Middleton, WI 53562				email: kburton@noran.com

Newsgroups: gnu.utils.bug
From: scv2f@honi4.acc.virginia.edu (Sotiris C. Vassilopoulos)
Subject: tar 1.11 bug
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sat, 12 Sep 1992 02:23:19 GMT

Hi,

The message :
	For more infomration, type  tar +help
should become
	for more information, type tar --help

Thanks for all the free software, you have written

- Sotiris

Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: tar-1.11 instructs user to use +help, rather than --help
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Thu, 10 Sep 1992 06:31:03 GMT

When a user invokes tar-1.11 with bad command line arguments, it
instructs the user to use +help, rather than --help.

Patch follows:

*** OLD/tar.c	Thu Sep 10 13:23:37 1992
--- tar.c	Thu Sep 10 13:23:58 1992
***************
*** 280,286 ****
  		break;
  	case CMD_NONE:
  		msg("you must specify exactly one of the r, c, t, x, or d options\n");
!  		fprintf(stderr,"For more information, type ``%s +help''.\n",tar);
  		exit(EX_ARGSBAD);
  	}
  	if (f_volno_file)
--- 280,286 ----
  		break;
  	case CMD_NONE:
  		msg("you must specify exactly one of the r, c, t, x, or d options\n");
!  		fprintf(stderr,"For more information, type ``%s --help''.\n",tar);
  		exit(EX_ARGSBAD);
  	}
  	if (f_volno_file)
***************
*** 616,622 ****

  		case '?':
  		badopt:
! 			msg("Unknown option.  Use '%s +help' for a complete list of options.", tar);
  			exit(EX_ARGSBAD);

  		}
--- 616,622 ----

  		case '?':
  		badopt:
! 			msg("Unknown option.  Use '%s --help' for a complete list of options.", tar);
  			exit(EX_ARGSBAD);

  		}

Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: tar-1.11 and AIX 3.2
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Thu, 10 Sep 1992 11:35:45 GMT

Fixed in enclosed patch:
1. Both <sys/time.h> and <time.h> need to be included for getdate.y

2. rindex and index are defined in <string.h>, so #undef them before
   redefining them.

Not fixed in patch:
1. complains about number of arguments of macro rindex()

2. won't link with provided malloc -- unresolved symbol etext --
   works with system malloc.

*** OLD/getdate.y	Thu Sep 10 17:40:56 1992
--- getdate.y	Thu Sep 10 17:44:26 1992
***************
*** 50,59 ****
--- 50,65 ----
  #else
  #include <sys/timeb.h>
  #endif	/* defined(USG) && !defined(HAVE_FTIME) */
+
  #if	defined(BSD4_2) || defined(BSD4_1C)
  #include <sys/time.h>
  #else
+ #if	defined(_AIX)
+ #include <sys/time.h>
  #include <time.h>
+ #else
+ #include <time.h>
+ #endif	/* defined(_AIX) */
  #endif	/* defined(BSD4_2) */
  #endif	/* defined(vms) */

*** OLD/port.h	Thu Sep 10 17:45:34 1992
--- port.h	Thu Sep 10 17:46:37 1992
***************
*** 98,104 ****
--- 98,110 ----
  #if !defined(__MSDOS__) && !defined(STDC_HEADERS)
  #include <memory.h>
  #endif
+ #ifdef index
+ #undef index
+ #endif
  #define index strchr
+ #ifdef rindex
+ #undef rindex
+ #endif
  #define rindex strrchr
  #define bcopy(s, d, n) memcpy(d, s, n)
  #define bzero(s, n) memset(s, 0, n)

Newsgroups: gnu.utils.bug
From: ezk@chestnut.cs.columbia.edu (Erez "HWank1" Zadok)
Subject: GNU Finger 1.35 .fingerrc problem with restricted shell
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 03:04:55 GMT

Our serverhost is one which some users are not allowed to login.  Those
users are allowed to login to all other hosts in our domain.  We do this by
setting up NIS netgroups.  On the restricted host we have at the end of
/etc/passwd:

	+::0:0:::/bin/restricted

which prints a message telling them they cannot login to this restricted
host, and exits.  On all of the other machines we have

	+::0:0:::

which lets those users a local login.

If such a restricted user on that host has a .fingerrc file, all they get
when anyone fingers them is the output from /bin/restricted, because that is
the shell that is exec-ed in the maybe_exec_as_user() function.  I had to
hack it so that if they have a restricted shell, but are valid uses on our
system, and have a .fingerrc file, finger will at least execute /bin/sh for
their .fingerrc.

Erez.

Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: shellutils 1.7: getugroups, su
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 12:55:29 GMT

Compiling the shell utilities 1.7 on a 486 running Interactive Unix 2.2.1.

I get a warning compiling lib/getugroups.c, since getgrent is
undeclared.  Since this is not a POSIX function, I don't understand why
it is declare in the !_POSIX_VERSION part of the conditional.  Perhaps
it should just be declared unconditionally.

(As an aside, it also seems bizarre to me that there are #ifdef's for
`sun' and `ultrix' in the course of defining GETGROUPS_T.  Seems like
the hardware has absolutely nothing to do with whether gid_t is present.)

Also, in src/Makefile.in, I don't understand why `su' is not simply
included as part of `PROGS', rather than as a separate target that
always gets made.

I also had one serious problem, date always dumping core, but as that
turned out to be a problem in Autoconf, I'm reporting it separately.

Here are diffs.

Sun Sep  6 10:19:52 1992  Karl Berry  (karl@hayley)

        * src/Makefile.in (PROGS): include `su' here.
        (all): instead of separately here.

        * getugroups.c (getgrent) [_POSIX_VERSION]: declare this.
        (getgrent) [!_POSIX_VERSION]: don't declare it.

*** lib/ORIG/getugroups.c	Fri Jul 24 17:10:38 1992
--- lib/getugroups.c	Sun Sep  6 09:45:47 1992
***************
*** 30,37 ****
  #else /* sun or ultrix */
  #define GETGROUPS_T int
  #endif /* not sun and not ultrix */
- #else /* not _POSIX_VERSION */
  struct group *getgrent ();
  #define GETGROUPS_T int
  #endif /* _POSIX_VERSION */
  
--- 30,37 ----
  #else /* sun or ultrix */
  #define GETGROUPS_T int
  #endif /* not sun and not ultrix */
  struct group *getgrent ();
+ #else /* not _POSIX_VERSION */
  #define GETGROUPS_T int
  #endif /* _POSIX_VERSION */
  
*** src/ORIG/Makefile.in	Tue Aug 25 19:30:11 1992
--- src/Makefile.in	Sun Sep  6 09:59:34 1992
***************
*** 28,37 ****
  false.sh true.sh
  
  PROGS = basename date dirname env expr false groups id logname \
! pathchk printenv printf sleep tee test true tty who whoami yes \
  @PROGS@
  
! all: $(PROGS) su
  .PHONY: all
  
  .c.o:
--- 28,37 ----
  false.sh true.sh
  
  PROGS = basename date dirname env expr false groups id logname \
! pathchk printenv printf sleep su tee test true tty who whoami yes \
  @PROGS@
  
! all: $(PROGS)
  .PHONY: all
  
  .c.o:

Newsgroups: gnu.utils.bug
From: am@ime.usp.br
Subject: finger 1.35
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 08:31:41 GMT

After frustrated attempts of installing the old gnu finger, I was glad
at the announcement of 1.34.  I got it straight out of prep, and after
installing it, I got the notice on 1.35, so I got it and installed it
here. 

The most noticeable buggy behavior of the old version is still present
here.  That is, finger keeps stale data, not refreshing its data and
status databases.  So, when users logout, finger keeps reporting them
logged in.

The system here:

A small network of assorted Sun sparcstations, all running SunOS
4.1.1.   Finger was compiled with gcc 2.2.2, and the only editing of
the original files was in setting up MAILDIR.  In particular, the
installation directories have the same names as in the distribution.
Ooops, actually there was another change.  Since I didn't want to
screw up the running finger, I did the folowing:
a) created a new service - gfinger, on port 2004.
b) edited each inetd.conf, adding the lines from
   support/inetd.conf-add, with finger substituted by cfinger.
c) on the serverhost (mafalda.ime.usp.br AKA ime.usp.br), I also
   commented out the old finger record, and added the one from
   support/inetd.conf-add.
d) gfinger was compiled with BASENAME_IS_SERVICE defined.

A large part of the filesystems are shared through a standard use of
NFS, NIS and the automounter.  This includes home directories, the
mail directory and /usr/local. 
This means that all workstations use the same finger executables, out
of /usr/local/bin and /usr/local/etc.  /usr/local/etc/fingerdir is a
symlink to an NFS mounted directory, which is in a local disk on the
serverhost. 

Looks like all data I can think of relevance is here.  Call me for
more, if you need.

 
..................................................................
Arnaldo Mandel                    \    am@ime.usp.br  (1st choice)
Computer Science Dep.		   \   amandel@cce.usp.br    (2nd)
Universidade de S\~{a}o Paulo	   /   mac@fpspux.fapesp.br
S\~{a}o Paulo - SP - Brazil	  /            (if all else fails)   


Newsgroups: gnu.utils.bug
From: mtranle%rigel@icmv.UUCP (Minh Tran-Le)
Subject: GNU finger 1.35 bug in lookup_tty in lib/tty.c
Reply-To: icmv!tranle%caliph@uunet.uu.net
Organization: IntelliCorp Inc.
Distribution: gnu
Date: Mon, 7 Sep 1992 21:17:13 GMT

The code for the function lookup_tty.c in lib/tty.c return a pointer
to stack allocated buffer.  That buffer should declared static.

Here is the change need to the file lib/tty.c.

Minh Tran-Le.
---------------------------------------------------------------------------
*** tty.c-	Thu Aug 20 09:55:04 1992
--- tty.c	Mon Sep  7 14:09:36 1992
***************
*** 86,90 ****
    char *fingerdir, *ttylocfile, *path_concat ();
    FILE *stream;
!   char buffer[256];
  
    stream = fopen (TTYLOCFILE, "r");
--- 91,95 ----
    char *fingerdir, *ttylocfile, *path_concat ();
    FILE *stream;
!   static char buffer[256];
  
    stream = fopen (TTYLOCFILE, "r");

-- 
Minh Tran Le.

ARPANET: tranle@intellicorp.arpa
UUCP:    ...sun!icmv!mtranle

Xref: sparky gnu.utils.bug:1534 gnu.announce:119
From: shigeya@dink.foretune.co.jp (Shigeya Suzuki)
Subject: installation problem in finger-1.35
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 5 Sep 1992 12:49:50 GMT

version: finger Version 1.35
hardware: SPARCstation2
os: SunOS 4.1.1
cc: gcc 2.2.2

The generation of "target/.targetdir" file, etc. is still wrong.

Since SunOS's sed does not support '+' in regular expression, the file
contains ", and causes serious installation error.

I think removing + does not harm. (at least in our site)

Shigeya Suzuki
Foretune Co., Ltd.


--- prdefine-	Sat Sep  5 01:55:12 1992
+++ prdefine	Sat Sep  5 21:36:48 1992
@@ -9,5 +9,5 @@
 echo "#include \"$INCFILE\"" >$TMP
 echo __finger_tag__ $DEF >>$TMP
 
-cc -E $TMP | fgrep __finger_tag__ | sed -e 's/[\" ]+//g' | sed -e 's/[ ]*__finger_tag__[ ]*//g'
+cc -E $TMP | fgrep __finger_tag__ | sed -e 's/[\" ]//g' | sed -e 's/[ ]*__finger_tag__[ ]*//g'
 rm -f $TMP

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: Sat, 5 Sep 1992 13:46:09 GMT

Using GNU textutils 1.3, I noticed that `wc -c FILE' or `wc -c *'
physically reads the file(s).  Would not it be better to just stat the
file(s) and produce the output quickly in those cases?

-- 
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: uddeborg@sisug.sisu.SE (Goeran Uddeborg)
Subject: finger 1.35
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 17:33:08 GMT

The function lookup_tty in tty.c in finger 1.35 returns a pointer to the
character vector buffer, which has auto storage.  A trivial fix:

*** tty.c~      Thu Aug 20 18:55:04 1992
--- tty.c       Mon Sep  7 14:36:36 1992
***************
*** 85,91 ****
  {
    char *fingerdir, *ttylocfile, *path_concat ();
    FILE *stream;
!   char buffer[256];
  
    stream = fopen (TTYLOCFILE, "r");
  
--- 85,91 ----
  {
    char *fingerdir, *ttylocfile, *path_concat ();
    FILE *stream;
!   static char buffer[256];
  
    stream = fopen (TTYLOCFILE, "r");
  

Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: autoconf 1.1: unix variants
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 12:56:29 GMT

The Autoconf 1.1 manual, `UNIX Variants' node, says:

    `AC_AIX'
         If on AIX, define `_ALL_SOURCE'.  Allows the use of some BSD
         functions.  Should be called before any macros that run the C
         compiler.

    `AC_DYNIX_SEQ'
         If on DYNIX/ptx (Sequent UNIX), add `-lseq' to `make' variable
         `LIBS'.  Allows use of some BSD system calls and `getmntent'.

It would be nice to know *which* BSD functions/system calls these
libraries provide.  Should essentially everybody's configure.in call
these, or what?

Perhaps a grab-all macro AC_UNIX_VARIANTS could be provided to invoke
the UNIX variant checks which everyone should be using.  Should include
at least AC_ISC_POSIX (I know personally) and AC_MINIX (judging from its
description).

Newsgroups: gnu.utils.bug
From: norbert@mozart.informatik.rwth-aachen.de (Norbert Kiesel)
Subject: tar 1.11 -O
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 14:56:08 GMT

Hello,

I would like tar *not* to create directories if called with the -O
option (i.e. output to stdout). This would allow previewing an
tar-file even with PWD on read-only file-systems (and one doesn't need
a 'rm -rf' afterwards).


		so long

			Norbert


*******************************************************************************
* Norbert Kiesel	Institut f. Informatik III     NN       NN    KK   KK *
* RWTH Aachen           Ahornstr. 55  		       NNN      NN    KK  KK  *
* West Germany		D-5100 Aachen 		       NN N     NN    KK KK   *
*                       +49 241 80-7266		       NN  N    NN    KKKK    *
* 		                 		       NN   N   NN    KKKK    *
* EUNET:    norbert@rwthi3.uucp       		       NN    N  NN    KK KK   *
* USENET:   ...!mcvax!unido!rwthi3!norbert	       NN     N NN    KK  KK  *
* INTERNET: norbert@rwthi3.informatik.rwth-aachen.de   NN      NNN    KK   KK *
*******************************************************************************

Newsgroups: gnu.utils.bug
From: bob@prepress.com (Robert Crowe)
Subject: problem with tar-1.11 and -v option.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 00:42:00 GMT

I just finished installing tar-1.11 on our SGI's (4D/25,Indigos;
IRIX-4.01), and I ran into a problem.  When specifying the -v option
with the -c option, the program core dumps. I traced the problem to
the fact that current_file_name never gets set when going through the 
create code.  My fix was ass follows:

======= Diff Starts here ===========
*** create.c	Wed Sep  9 17:21:37 1992
--- create.c.~2~	Wed Sep  9 17:13:31 1992
***************
*** 1273,1279 ****
  		head = header;
  		/* hstat is already set up */
  		head_standard = f_standard;
! 		current_file_name = header->header.arch_name; /* Added by bob. */
  		print_header();
  	}
  
--- 1273,1279 ----
  		head = header;
  		/* hstat is already set up */
  		head_standard = f_standard;
! 		current_file_name = name; /* Added by bob. */
  		print_header();
  	}
  
============ Diff ends here =============

There may be a better place to set current_file_name; If so please
post it and I will gladly apply that instead.

The actual place where it was dumping core was in quote_copy_string,
called from ~ line 536 in list.c:

        if (f_verbose <= 1) {
                /* Just the fax, mam. */
                char *name;

                name=quote_copy_string(current_file_name);  <This is the Call>
                if(name==0)
                        name=current_file_name;
 

Other than that, everything seems to work fine. Granted I have not
tested extensively yet. 

Thanks, the new features seem like they will come in real handy.

Bob.


P.S.  The makefile wants to build an info file ( which I love to have... ),
      But the .texi file seems to be missing in the distribution I
      grabbed (tar-1.11.tar.Z). Is it available elsewhere?


============================================================
Bob Crowe                      Voice:   (619) 931-2695
Pre-Press Technologies.        Email:    bob@prepress.com
2443 Impala dr.		       FAX:     (619) 931-2698
Carlsbad, Ca 92008.

Newsgroups: gnu.utils.bug
From: lockhart@eecom.gatech.edu (John B. Lockhart)
Subject: GNU TAR
Organization: Computer Engineering Group, Georgia Tech, Atlanta, GA 30332-0250
Distribution: gnu
Date: Mon, 14 Sep 1992 18:37:15 GMT

I tried compiling the new version of GNU Tar (1.11) out-of-box on two different
SPARCstations here (no unusual setups).  After ./configure-ing, and running
make, the compilation failed:

bison -y  getdate.y
conflicts:  9 shift/reduce
gcc -O -g  -target sun4 -c -o getdate.o y.tab.c
getdate.y: In function `get_date':
getdate.y:858: storage size of `tv' isn't known
getdate.y:859: storage size of `tz' isn't known
*** Error code 1
make: Fatal error: Command failed for target `getdate.o'

This looks like an #include/#define problem.

--John

-- 
::|  Never get into a foxhole with anyone braver than yourself.             |::
::|                                              --Murphy's Laws of Combat  |::
::::::::::| John B. Lockhart |::::::::::| lockhart@eecom.gatech.edu |::::::::::