HDTenEightyP/NetNews huggingface dataset:
From: brian@ilinx.wimsey.bc.CA
Subject: gnutar with large files
Organization: InterLinx Support Services Inc.
Distribution: gnu
Date: Fri, 11 Sep 1992 23:24:46 GMT

I am using gnutar to do multi-volume backups.  I have been
experiencing some wierd things that I think have something
to do with the size of a file crossing a volume.

The file size is ~114 MB.  The backup (cvMf) seems to go well,
but listing (tvMf), or comparing (dvMf) the backup yields a
message regarding the volumes being out of sequence.

If I try to list (tvf) the second volume, I get...

M--------- 0/0 24281600 Dec 31 16:00 1969 vd0/bbx/fil0/IGGD0--Continued at 
byte 90314240--
-rw-rw-r-- sysadmin/HOACCTG 98764 Sep 10 10:11 1992 vd0/bbx/fil0/IGGE0
-rw-rw-r-- sysadmin/HOACCTG 1778752 Sep  9 12:52 1992 vd0/bbx/fil0/IGGH0
-rw-rw-r-- sysadmin/HOACCTG  586440 Sep 10 10:11 1992 vd0/bbx/fil0/IGGJ0
-rw-rw-r-- sysadmin/HOACCTG   45880 Apr 27 12:16 1992 vd0/bbx/fil0/IGGB920
-rw-rw-r-- sysadmin/HOACCTG     512 Mar 13 19:09 1992 vd0/bbx/fil0/IGGB930
-rw-rw-r-- sysadmin/HOACCTG 9122752 Sep  9 11:49 1992 vd0/bbx/fil0/IGGM910
...
 
and the end of the first volume lists like

...
-rw-rw-r-- kevirv/HOACCTG     83257 Sep 10 08:43 1992 vd0/bbx/fil0/IGFH0
-rw-rw-r-- patliv/HOACCTG    821504 Sep 10 10:21 1992 vd0/bbx/fil0/IGFR0
-rw-rw-r-- sysadmin/HOACCTG 9122752 Sep 10 10:11 1992 vd0/bbx/fil0/IGGM920
-rw-rw-r-- sysadmin/HOACCTG 5046784 Sep 10 10:11 1992 vd0/bbx/fil0/IGGM930
-rw-rw-r-- sysadmin/HOACCTG   45880 Jan 10 08:49 1992 vd0/bbx/fil0/IGGB910
-rw-rw-r-- sysadmin/HOACCTG 114595840 Sep 10 10:11 1992 vd0/bbx/fil0/IGGD0

so I do know that the file continues properly.

what could be going on here ??

brian
-- 
Brian J. Murrell                                        brian@ilinx.wimsey.bc.ca
InterLinx Support Services, Inc.                        uunet!van-bc!ilinx!brian
North Vancouver, B.C.
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD

Newsgroups: gnu.utils.bug
From: rhill%core1@kssib.ksc.nasa.gov (Russ Hill)
Subject: GNU tar
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 4 Sep 1992 12:59:00 GMT

GNU tar 1.10

makefile changes for CX/UX harris nighthawk machine


#CX/UX
CC=cc
DEFS= -DUSG -DHAVE_SIZE_T -DNEED_TZSET
LOCAL_SRC =  getdate.y rtape_lib.c
LOCAL_OBJ =  getdate.$O rtape_lib.$O
LDFLAGS =
LIBS =
LINT =
LINTFLAGS =
DEF_AR_FILE = \"/dev/rmt/0m\"
DEFBLOCKING = 20
O = o



Russ

Russ Hill                           Unix Analyst - CADCO
Harris Space Systems Corporation    ROCK1-505  (407) 633-3950
295 Barnes Blvd                     Rockledge, Fl 32955

"That boy is as sharp as a sack of wet mice."
			-- Foghorn Leghorn


Newsgroups: gnu.utils.bug
From: ezk@chestnut.cs.columbia.edu (Erez "HWank1" Zadok)
Subject: Two more GNU finger 1.35 .fingerrc problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 09:48:11 GMT

Apparently when I finger anyone who has a .fingerrc file, my .env gets
executed no matter what, and then the script does.  I even unset the value
of my ENV variable (in ksh) and thought that had something to do with it.
But that did not help.  What did help was when I removed my .env file.

Finger should exec() the .fingerrc script and nothing more.  In the top of
my .kshrc I put

	#!/bin/ksh -p

using the -p to explicitly ask for .env files not to be executed.  Your code
probably executes a shell on behalf of the fingered user, and then the
user's .fingerrc.

Another problem I have is that whenever I finger someone who has a .fingerrc
file (in -l mode), only the output from executing the .fingerrc file is
shown, and nothing more.  If the user did not have a .fingerrc file, I would
get the default long listing (in long mode): user name, id, shell, mail
status, .plan and .project.

I think that what you need to do is supply a few more options (compile time
or run time.)  These will allow me to always get the long "standard"
information no matter what, even if the user has a .fingerrc file.  Another
option would be to execute the .fingerrc instead, in addition to "standard"
information, or non at all.  The last option, one to turn off execution of
.fingerrc, controlled by the client, will be very popular among people with
tight computer security in mind.

Erez Zadok.
---
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
From: halvers@sol.CRd.ge.COM (peter c halverson)
Newsgroups: gnu.utils.bug
Subject: segmentation in imageto (?)
Date: 11 Sep 92 19:28:10 GMT
Reply-To: Pete Halverson <halverson@crd.ge.com>
Distribution: gnu
Organization: GNUs Not Usenet

[more a question than a bug report, because it's not clear whether imageto
is expected to handle the following...]

Is imageto supposed to be able to separate glyphs that overlap in one
dimension?  I know it can't handle 2D overlap (where images actually
touch), but an image like

                 XXXX  YYYYYYY
                 XXXX      YYY
                 XXXXXXXXX YYY
                 XXXXXXXXX YYY
                 XXXX      YYY
                 XXXX  YYYYYYY

is yielding glyphs

                 XXXX
                 XXXX
                 XXXXXXXXX
                 XXXXXXXXX
                 XXXX
                 XXXX

and

                 YYYYYYY
                     YYY
                 XXX YYY
                 XXX YYY
                     YYY
                 YYYYYYY

namely the "left" glyph is correct, but the "right" glyph includes those
portions of the former which are contain in the latter's bounding box.  Am
I doing something wrong, or is this a known deficiency in imageto?  If the
latter, I would think it would be a real pain to deal with italic/slanted
faces, which probably overlap BB's a lot...

I'm also getting some (related?) oddities for the two double quote glyphs.
It's kind of hard to describe in ASCII (I can try and isolate the bits in
question if you want to see them), but IMG data something like

               xx     xx
              xx     yx
             xxx    zyx
             xxxxx  zyxxx
             xxxxxx zyxxxx
              xxxx   yxxx

is being converted by imageto into a GF char looking like

               xx     xx
              xx      x     y
             xxx      x    zy
             xxxxx    xxx  zy
             xxxxxx   xxxx zy
              xxxx    xxx   y

i.e. part of the left side of the rightmost segment is getting moved to the
right side.  The rightdblquote is similarly afflicted, but no others.  I've
noticed that when running -verbose, imageto outputs a plus-sign ("+") in
front of just these two id's; no others.  What's the meaning of the plus
sign?  Are these two segmentation problems related?

thanks for any help you can offer,
Pete
Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: missing curly braces in tar-1.11.
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Thu, 10 Sep 1992 04:44:48 GMT

Curly braces are missing around a two statement if clause in both
gnu.c and tar.c.

*** OLD/gnu.c	Wed Sep  9 18:24:15 1992
--- gnu.c	Wed Sep  9 18:24:45 1992
***************
*** 126,134 ****
  	time(&this_time);
  	if(gnu_dumpfile[0]!='/') {
  #if defined(__MSDOS__) || defined(USG) || defined(_POSIX_VERSION)
! 			if(!getcwd(path,PATH_MAX))
  				msg("Couldn't get current directory.");
  				exit(EX_SYSTEM);
  #else
  			char *getwd();

--- 126,135 ----
  	time(&this_time);
  	if(gnu_dumpfile[0]!='/') {
  #if defined(__MSDOS__) || defined(USG) || defined(_POSIX_VERSION)
! 			if(!getcwd(path,PATH_MAX)) {
  				msg("Couldn't get current directory.");
  				exit(EX_SYSTEM);
+ 			}
  #else
  			char *getwd();

*** OLD/tar.c	Wed Sep  9 18:24:15 1992
--- tar.c	Wed Sep  9 18:24:30 1992
***************
*** 973,981 ****
  		if(chdir_name[0]!='/') {
  			char *path = ck_malloc(PATH_MAX);
  #if defined(__MSDOS__) || defined(USG) || defined(_POSIX_VERSION)
! 			if(!getcwd(path,PATH_MAX))
  				msg("Couldn't get current directory.");
  				exit(EX_SYSTEM);
  #else
  			char *getwd();

--- 973,982 ----
  		if(chdir_name[0]!='/') {
  			char *path = ck_malloc(PATH_MAX);
  #if defined(__MSDOS__) || defined(USG) || defined(_POSIX_VERSION)
! 			if(!getcwd(path,PATH_MAX)) {
  				msg("Couldn't get current directory.");
  				exit(EX_SYSTEM);
+ 			}
  #else
  			char *getwd();



Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU tar 1.11 installation report
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 14:38:13 GMT

This is an installation report for GNU tar 1.11, using GNU C 1.40
under COFF encapsulation, on a 386/ix 2.0.2 system (waiting for Hurd
to be ready :-).  The installation went fairly well, save for the
following minor points or comments.

* "DEF_AR_FILE=/dev/rfd1 sh configure" did not work as expected.  The
configure script should use the environment variable DEF_AR_FILE if
it exists without overriding it.

* Similarily, DEFBLOCKING should be moved from the environment into
the created Makefile through the configure process.  I know I can
still ask "make DEFBLOCKING=30" of course.  It just would be nicer is
DEFBLOCKING was configurable in from the environment, instead of
having a fixed value of 20 from Makefile.in.

* Making after configure yields, at link time:

----->
port.c:66 (port.o): Definition of symbol _valloc (multiply defined)
malloc.c:718 (malloc.o): Definition of symbol _valloc (multiply defined)
-----<

First, configure tests for the presence of valloc and triggers the
compilation of valloc inside port.o.  Then, configure further decides
to include malloc.o, which provides valloc.

* Trying tar by a mere "./tar" yields:

----->
./tar: you must specify exactly one of the r, c, t, x, or d options

For more information, type ``./tar +help''.
-----<

The +help reference should be changed to --help.

* Trying "./tar --help" gives a list of option in which the comments
are poorly aligned.  It should be done better and more consistently.

* Since Info files were not provided, they should not be installed.

-- 
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: tap@src.honeywell.com (Thomas A Peterson)
Subject: finger 1.35: installation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 5 Sep 1992 16:44:41 GMT

Hardware - OS : sparc-sun-sunos411
Description :	
  'make server' fails because the generated src/.fingerdir file
  contains double quotes. Why not just use FingerDir from config.h
  also as was done with EtcDir and BinDir?

socrates: make server
(cd lib; make  libfinger.a)
make[1]: `libfinger.a' is up to date.
(cd src/; make  server)
../support/prdefine FINGERDIR ../include/fingerpaths.h >.fingerdir
../support/prdefine EtcDir ../config.h >.etcdir
../support/prdefine BinDir ../config.h >.bindir
if [ ! -r `cat .etcdir` ]; then mkdir `cat .etcdir`; fi
if [ ! -r `cat .fingerdir` ]; then mkdir `cat .fingerdir`; fi
mkdir: cannot make directory `"/usr/local/gnu/lib/fingerdir"': No such file or directory
make[1]: *** [install] Error 1 (ignored)
cp finger `cat .bindir`; chmod a+rx `cat .bindir`/finger
cp fingerd `cat .bindir`; chmod a+rx `cat .bindir`/fingerd
cp in.fingerd `cat .etcdir`; chmod a+rx `cat .etcdir`/in.fingerd
cp: cannot create regular file `/usr/etc/local/in.fingerd': Read-only file system
cp in.cfingerd `cat .etcdir`; chmod a+rx `cat .etcdir`/in.cfingerd
cp: cannot create regular file `/usr/etc/local/in.cfingerd': Read-only file system
(cd ../lib/site; make install)
make[2]: Nothing to be done for `install'.
(cd targets; make  server)
../support/prdefine TARGETDIR ../include/fingerpaths.h >.targetdir
if [ ! -r `cat .targetdir` ] ; then mkdir `cat .targetdir`; fi
mkdir: cannot make directory `"/usr/local/gnu/lib/fingerdir/targets"': No such file or directory
make[1]: *** [install] Error 1 (ignored)
cp [slx]-* `cat .targetdir`
cp: when copying multiple files, last argument must be a directory
Usage: cp [options] source dest
       cp [options] source... directory
Options:
       [-abdfilprsuvxPR] [-S backup-suffix] [-V {numbered,existing,simple}]
       [--backup] [--no-dereference] [--force] [--interactive]
       [--one-file-system] [--preserve] [--recursive] [--update] [--verbose]
       [--suffix=backup-suffix] [--version-control={numbered,existing,simple}]
       [--archive] [--path] [--link] [--symbolic-link]
make[1]: *** [install] Error 2
make: *** [server] Error 1
From: pinard@icule.UUCP (Francois Pinard)
Newsgroups: gnu.utils.bug
Subject: GNU tar 1.11 tries
Date: 10 Sep 92 15:01:07 GMT
Reply-To: pinard@iro.umontreal.ca
Distribution: gnu
Organization: GNUs Not Usenet

This report applies to GNU tar 1.11, installed with GNU C 1.40 under
COFF encapsulation on a 386/ix 2.0.2 system (waiting for Hurd to be
ready :-).

It seems that "tar cv..." tries to print NULL's.  Knowing that

	printf ("%s", NULL);

produces the recognizable L^A^C pattern on this machine, here are some
examples (in which I edited C-a into ^A and C-c into ^C):

$ tar cfvV /dev/null "GNU tar 1.11"
L\001\003
tar: can't add file L^A^C : No such file or directory
$ tar cvf /dev/null tar.tar.Z
L\001\003
$ tar cvf /dev/null .
L\001\003
L\001\003
L\001\003
L\001\003
L\001\003
L\001\003
L\001\003
L\001\003
[...]

-- 
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: adc@tardis.msu.EDU (Alan D. Cabrera)
Subject: Compiling Bison
Reply-To: adc@tardis.msu.edu
Organization: Michigan State University
Distribution: gnu
Date: Thu, 10 Sep 1992 19:30:32 GMT

I'm compiling Bison 1.18 with gcc 2.2.2 on my SPARCstation 2 running
4.1.1 and I get:

gcc  -O -g -DSTDC_HEADERS=1 -DSTRERROR_MISSING=1  -target sun4 -c  getopt1.c
In file included from getopt1.c:30:
/usr/include/stdlib.h:18: conflicting types for `abort'
<built-in>:0: previous declaration of `abort'
/usr/include/stdlib.h:26: conflicting types for `exit'
<built-in>:0: previous declaration of `exit'
*** Error code 1
make: Fatal error: Command failed for target `getopt1.o'
tardis{adc}107% 

---
Alan Cabrera				internet:  adc@tardis.cl.msu.edu
Computer Laboratory			phone:     (517) 353-3027
Michigan State University		fax:       (517) 353-9847
514 Computer Center			bitnet:    CABRERA@MSU
East Lansing, MI 48824


Newsgroups: gnu.utils.bug
From: jla@gnu.ai.mit.edu (Joseph Arceneaux)
Subject: index-1.6 stdin bug? & question
Reply-To: jla@ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 16:02:47 GMT

   From: burley@cygnus.com (Craig Burley)
   Date: Wed, 9 Sep 92 16:39:28 EDT

   First, a bugfix, without which indent-1.6 can't reliably read from standard
   input:

This bug has been fixed, along with several others.  Unfortunately, I
do not know when I can make a new release, as Lucid, Inc is severing
my net connection and I don't yet know when I will get another
established.  Hopefully this won't be very long.

   Second, a question, as a new user of indent:

   I get the impression that indent doesn't care at all about the _incoming_
   whitespace, i.e. that it doesn't learn anything about the program by looking
   at the nature of whitespace.  Is this a correct impression?  (I'm thinking
   in terms of the "design" of indent; based on the docs, which I
   admit I haven't 
   read in great detail, it looks like it changes whitespace, but doesn't
   try and interpret incoming whitespace per se.)

I don't think there is a document describing the "design" of indent.
In any event, the "design" is pretty inelegant, and it has been hacked
maliciously over the years.

It is true that indent pays little attention to incoming whitespace.
However, conerning subtle differences in output between various
elements of a chain like:

  indent -st foo.c | indent | indent | indent | ...

I have devoted some effort to ensuring that the output of all elements
is exactly the same.  If it is not, there is a bug.  Note that this
example is not the same as the one you provided:

       bash$ indent < foo.c | indent -T bool -T ffelexToken | indent > bar.c

   produces a file named bar.c that is different in subtle ways from the
   file named baz.c produced by

       bash$ indent < foo.c > baz.c

Identifying typenames with -T *can* change the indentation of your
code, and this is intended.

If you think indent is doing this incorrectly, or there is some other,
related bug, then please send me a minimal example of such code.

Joe

----
Joseph Arceneaux
Free Software Foundation
jla@ai.mit.edu                PO Box 460633
+1 415 285 9088               San Francisco, CA 94146

Help abolish software patents -- send mail for details.

Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: file name globbing with tar-1.11
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Thu, 10 Sep 1992 10:17:21 GMT

fnmatch(), used by most of the other gnu utilities for file name
globbing, allows both `!' and `^' to negate character classes.

wildmat(), used by tar-1.11, only allowed `!' until now:


*** OLD/wildmat.c	Thu Sep 10 17:03:38 1992
--- wildmat.c	Thu Sep 10 17:04:32 1992
***************
*** 104,110 ****
  		return(*++p ? Star(s, p) : TRUE);
  	    case '[':
  		/* [!....] means inverse character class. */
! 		if (reverse = p[1] == '!')
  		    p++;
  		for (last = 0400, matched = FALSE; *++p && *p != ']'; last = *p)
  		    /* This next line requires a good C compiler. */
--- 104,110 ----
  		return(*++p ? Star(s, p) : TRUE);
  	    case '[':
  		/* [!....] means inverse character class. */
! 		if (reverse = (p[1] == '!' || p[1] == '^'))
  		    p++;
  		for (last = 0400, matched = FALSE; *++p && *p != ']'; last = *p)
  		    /* This next line requires a good C compiler. */

Newsgroups: gnu.utils.bug
From: etnkna@hisoy.etn.ericsson.SE (Aksnes Knut-Havard)
Subject: Bug in config script for binutils-2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 09:27:00 GMT

make install barfs after configuring and building for sun4, i am using
sunos4.1.2. End of output from `make -w install' follows.

make -w install
.
.
.
make[1]: Entering directory `/div/src/binutils-2.0/binutils'
parent=`echo /usr/local/bin|sed -e 's@/[^/]*$@@'`; if [ -d $parent ] ; then true ; else mkdir $parent ; fi
if [ -d /usr/local/bin ] ; then true ; else mkdir /usr/local/bin ; fi
for i in size objdump nm ar strip ranlib ; do install -c $i /usr/local/bin/`t=''; echo $i | sed -e "" $t` ; done
if [ -d /usr/local/lib ] ; then true ; else mkdir /usr/local/lib ; fi
rm -f /usr/local/lib/nm
cd /usr/local/lib; ln -s /usr/local/bin/nm nm
parent=`echo /usr/local/man/man1|sed -e 's@/[^/]*$@@'`; if [ -d $parent ] ; then true ; else mkdir $parent ; fi
if [ -d /usr/local/man/man1 ] ; then true ; else mkdir /usr/local/man/man1 ; fi
for i in ar nm objdump ranlib size strip ; do install -c ./$i.1 /usr/local/man/man1/`t=''; echo $i | sed -e "" $t`.1 ; done
make[1]: Leaving directory `/div/src/binutils-2.0/binutils'
make[1]: Entering directory `/div/src/binutils-2.0/opcodes'
parent=`echo /usr/local/lib|sed -e 's@/[^/]*$@@'`; if [ -d $parent ] ; then true ; else mkdir $parent ; fi
if [ -d /usr/local/lib ] ; then true ; else mkdir /usr/local/lib ; fi
install -c libbfd.a /usr/local/lib/libbfd.a
install: libbfd.a: No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/div/src/binutils-2.0/opcodes'
make: *** [install-opcodes] Error 1
make: Leaving directory `/div/src/binutils-2.0'

-------------------------------------------------------------------------------
Name:	Knut-Hevard Aksnes (ECMA 94) or		Knut-Haavard Aksnes (ASCII)
Ericsson signature: HI/ETN/U/IT KNA		Phone: +47 41 19481
Email: etnkna@hisoy.etn.ericsson.se (internet)  ETN.ETNKNA (memo)


Newsgroups: gnu.utils.bug
From: david@jake.eeap.cwru.edu (David Nerenberg)
Subject: glibc-1.04 make problem -- I'm stuck
Organization: Case Western Reserve University
Distribution: gnu
Date: Fri, 11 Sep 1992 16:11:49 GMT

I am trying to compile glibc-1.04 with very little success.  I am trying
on both Sun3's under sunos 4.1 and Sun4's under sunos 4.1.1, both with
the same error.  Here is what I have been doing:

In the same directory as the source:
  configure m68k-sun-sunos4.1  --with-gnu-as --with-gnu-ld
(I have tried without gld and without gas)

In all cases, configure reports what configurations it is going to use
and reports sucessful completion:

Configuring the GNU C Library for `m68k-sun-sunos4.1'.
Using system-dependent files from directories:
m68k/fpu unix/bsd/sun/sunos4 unix/bsd/sun/m68k unix/bsd/sun unix/bsd m68k

Ok, so I check Makeconfig, and create a configparms (I have also tried 
without a configparms file existing to the same avail).

Next, I type a gmake:

Makeconfig:72: extraneous text after `include'
gmake: sysdeps/..: Is a directory.  Stop.

Line 72 reads:  include $(common-objpfx)config.make
common-objpfx is defined on line 64 as:  common-objpfx = sysdeps/..      
				# This is a kludge.  make wizards might grok.

OK, so as a work around, I change like 72 to read:  include config.make

I than try gmake again and get:

gmake: fopen: sysd-dirs: No such file or directory
gmake: fopen: sysdirs: No such file or directory
gmake: fopen: sysd-Makefile: No such file or directory
Makerules:201: multiple target patterns.  Stop.

lines 200-205 read:

+libobjs := $(patsubst %,$(libc.a)(%),$(notdir $(objects)))
ifdef +libobjs
$(+libobjs): $(libc.a)(%): $(objpfx)%;
endif
libobjs: $(+libobjs)
lib-noranlib: libobjs ar-it

I don't understand exactly what this is doing, and where I have gone wrong.
Can anyone enlighten me as to my error or how to fix the problem so we can
get this fixed in the next release?

						Thanks,
						    Dave

-- 
david@elwood.eeap.cwru.edu             David Nerenberg
73107,177 CompuServe                   Electrical Engineering & Applied Physics
NY:  H-516-751-6344                    Case Western Reserve University
     W-516-751-8111                    W-216-368-2982   H-216-754-2085

Newsgroups: gnu.utils.bug
From: scott@igc.apc.org (Scott Weikart)
Subject: Re: HAVE_TZNAME problem with shellutils
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 23:28:18 GMT

>Under DG/UX 5.4 on a Data General Aviion, shellutils-1.7 compiles and runs,
>out of the box, except for one small problem: date(1) coredumps.  I traced
>this problem to an omission in the autoconfigured Makefile.
>
> DG/UX has tzname, but the automatically configured Makefile didn't contain
> -DHAVE_TZNAME.  This caused a problem with lib/strftime.c

The same thing happened with ISC 3.0, gcc-2.2.2 .

Scott Weikart			Community Data Processing (CdP): 415-322-9069
Internet: scott@igc.org		Bitnet: scott%igc.org@stanford
UUCP Mail Net: uunet!cdp!scott

Newsgroups: gnu.utils.bug
From: tap@src.honeywell.com (Thomas A Peterson)
Subject: finger 1.35 : Installation problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 5 Sep 1992 17:05:21 GMT

Hardware - OS : sparc-sun-sunos411

Description:
  support/prdefine fails to remove the double quotes from the
  remaining string. The '+' in the sed script causes it to do nothing. 

cc -E $TMP | fgrep __finger_tag__ | sed -e 's/[\" ]+//g' | sed -e 's/[ ]*__finger_tag__[ ]*//g'

Should be replaced with:

cc -E $TMP | fgrep __finger_tag__ | sed -e 's/[\" ]//g' | sed -e 's/[ ]*__finger_tag__[ ]*//g'

Newsgroups: gnu.utils.bug