HDTenEightyP/NetNews huggingface dataset:
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: Re: Bug report for make
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 16:23:36 GMT

This is not a bug.  You have misunderstood how Make works.  Variables and
functions in rule targets and dependencies are expanded when the makefile
is read.

> Makefile used (contains 1 line):
> l.m : % : $(basename %).c
> 
> Result obtained in a directory containing only the Makefile file:
> make: *** No way to make target `l.m.c'.  Stop.
> 
> Result expected:
> make: *** No way to make target `l.c'.  Stop.
> 
> Comments:
> why is the basename function not executed?
> If the Makefile is: 
> l.m : % : $(addsuffix i,%).c
> the result is:
> make: *** No way to make target `l.mi.c'.  Stop.
> That shows that it is possible to use a function in a static pattern rule.
> Why does not it work with basename?

In your second makefile, the function is expanded at read time and results in:

l.m: %: %i.c

In the first, `$(basename %)' becomes `%', so the rule is:

l.m: %: %.c

Newsgroups: gnu.utils.bug
From: wb@ifado.UUCP (Wilhelm B. Kloke)
Subject: Suggestion for locate & code
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 13:22:17 GMT

Hallo,
in the GNU-find-3.7 distribution I found a bug which makes these programs
less useful in byte-sex-mixed NFS-environment.
The programs contain 1 call of getw/putw which makes them dependent on the
machine endianness. If I try to make databases for all the NFS-mounted
filesystems, I need them twice (or even more). Therefore I suggest
to change those calls. In a first try I added
int getw(FILE *fp) { register short x;
        x=fgetc(fp)<<8; return x | fgetc(fp)&0xff; }
resp.
int putw(int c,FILE *fp) { fputc(c>>8,fp); fputc(c,fp); }

into the sources, which makes the database slightly shorter on 32-bit-word
machines.

I checked the redundancy of the resulting database by applying compress on
the file. This yielded a high compression rate. I looked for a reason for this
too. One possible solution may be to look for trigrams at the end. I have a
lot of files ending in t.f (Sources of NAG-library). This led to the result 
that the most often encountered bigrams were t. and .f which are mutually
exclusive, which results in a highly suboptimal selection of bigrams.
There are some other trigrams at the end which are likely to occur:
.pk (TeX-Fonts), .3X (X11-Online-Manuals), .cc (C+-Sources), .el (EMacS). 
This is just an observation, and not very important.
But I thought of a quick hack to change this.
One could reserve a quarter or half of the bigrams for those occurring
at the end of names. Then these trigrams would less likely be doubly
counted.

Newsgroups: gnu.utils.bug
From: hueni@optolab.unibe.ch ( (Hermann Hueni))
Subject: binutils-920602 ld for coff-m68k produces a strange result
Keywords: bfd, ld, coff, m68k
Reply-To: hueni@optolab.unibe.ch
Organization: Physiological Institute, University of Berne, Switzerland
Distribution: gnu
Date: Wed, 22 Jul 1992 10:22:07 GMT

I use gcc2.2.2/gas-1.92.3 for cross-compilation sparc->m68k..
I use ld from the binutils-920602 together with the newest bfd library
from gdb4.6 and confiured with --target=sun3.

Generating  srec output with ld works perfectly.
I can also generate a.out-sunos-big format files and look at them with size
and other tools form the binutils successfully.

	bash$ /usr/local/sun3/bin/size neuro6.aout 
	text       data      bss         dec         hex     filename
	180192  16384   1838900 2035476 1f0f14  neuro6.aout

Since our target system can only load coff format files, I tried to generate
coff-m68k. When I look at the generated file with size, I get:

	bash$ /usr/local/sun3/bin/size neuro6.coff 
	text    data    bss     dec       hex     filename
	0        11552   0        11552   2d20    neuro6.coff

Something must go wrong. I suppose, that the bfd part that implements coff-m68k
is buggy. When I investigate the file with objdump -x, I get the following;

	neuro6.coff:     file format coff-m68k
	neuro6.coff
	architecture: m68k:68020, flags 0x00000032:
	EXEC_P, HAS_SYMS, HAS_LOCALS
	start address 0x04040000
	SECTION 0 [.data]       : size 00002d20 vma 04020000 align 2**3
	 ALLOC, LOAD
	SECTION 1 []    : size 00000002 vma 00000404 align 2**3
	 ALLOC, LOAD
	bfd assertion fail ./coffcode.h:3059
	bfd assertion fail ./coffcode.h:3059
	bfd assertion fail ./coffcode.h:3059

The last message is repeated about 130 times. Thereafter, the symbol table gets dumped.
Here is the link script that I am using:

/* OUTPUT_FORMAT( "a.out-sunos-big" ) */
OUTPUT_FORMAT( "coff-m68k" )
OUTPUT_ARCH( m68k )
__dtof=0x ;
MEMORY
{
        ram: ORIGIN=0x4020000, LENGTH=0x3d0000
}
SECTIONS {
        .data 0x4020000 : { *(.data)}
        .text 0x4040000 : {*(.text) *(code)}
        .bss  0x4080000 : {*(.bss) [COMMON] }  
}


-----------------------------------------------------
Any suggestions what might be wrong ?

thanks,
hermann
hueni@optolab.unibe.ch

Newsgroups: gnu.utils.bug
From: dj@pelf.harvard.edu (Diab Jerius)
Subject: indent-1.4 doesn't recognize floating-suffices
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 10:44:23 GMT

program: indent
version: 1.4
cc:      gcc 2.1
system:  SunOS 4.1


indent options:
-bl -bli0 -nce -cs -psl -nfc1 -i2 -cli2 -di2 -nbc -bad -npcs -TFILE

given the following input:

  i = 0.0f;
  i = 0.0l;
  i = 0.0F;
  i = 0.0L;

indent produces:

    i = 0.0 f;
    i = 0.0l;
    i = 0.0 F;
    i = 0.0L;

it should recognize the floating suffices, but doesn't.

 -----------------------------------------------------------------------------
 diab jerius                                     harvard-smithsonian
 internet: jerius@cfa.harvard.edu              center for astrophysics
 voice: (617) 496-7575               60 garden st., m/s 81 cambridge, ma 02138

Newsgroups: gnu.utils.bug
From: bserr@andersen.UUCP (Robert Serr  507-0429, 312)
Subject: GNU make version 3.62:  VPATH
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 23 Jul 1992 00:18:53 GMT

To the bug fixer,
	I have found what I think is a bug in the vpath command in version 3.62 of GNU MAKE.  It doesn't work the way I would think it would after reading the documentation, but please inform me if it is supposed to work this way. 
	I have two directories, one containing source (/work) and one containing binaries (/bin).  They are on the same level (from work I do cd ../bin to get to /bin).  I have prog1.c in /work which is more recent than the copy of prog1.o in /bin.  My make file is also in /work.  I set the vpath using both of the commands listed in the make file below, and it behaves the same way.  When I run GNU MAKE, it will NOT recompile prog1.c like it should (since it is more recent than ../bin/prog1.o).  It will instead li
nk prog1.o.  
	I would think that since vpath is supposed to make files seem as thought they are in the same directory, that the time stamps of these files should be compared, and that the more recent file should be used.      
	I ran GNU MAKE -d to see what the thinking was.  It looks like once a dependent (.o file) has been found in the alternative directory (../bin), that GNU MAKE will only search for implicit dependencies starting from the alternative directory (../bin/prog1..c, ../bin/prog1.p etc.).  If the dependent (.o file) is in the current directory (.), then GNU MAKE will search for implicit dependencies in the alternative directory, as well as the current directory (prog1.c, prog1.p, ../bin/prog1.c, etc.).  I would th
ink that it should go both ways.  
	Here is the Makefile:

############################################################################

# I tried both of the following ways:
VPATH = ../bin
#vpath %.o ../bin

CFLAGS = -g

objects = main.o prog1.o prog2.o prog3.o prog4.o

dum: $(objects)
	cc -o dum $(CFLAGS) $^

main.o: main.h

# end of Makefile
#############################################################################

Would you please have a look at this and let me know as soon as possible if this is a bug, or if for some reason that it is supposed to be this way?  If it is supposed to be this way, is there a way around it?

	Thank you very much.

			Bob Serr - bserr@andersen.com

Newsgroups: gnu.utils.bug
From: jjc@jclark.COM (James Clark)
Subject: groff and man pages without page breaks?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 15:47:06 GMT

Please use bug-groff@prep.ai.mit.edu for questions about groff.

   GNU groff comes with all kinds of macro packages included, among them
   the -man macros.

   I would appreciate a hint how I can format -man input files without page
   breaks, i.e. as one continuous output text. Where do I have to change
   what and how for this purpose?

Add

   .ch an-header
   .ch an-footer
   .ch an-p-footer

to the beginning of the man page.

James Clark
jjc@jclark.com

Newsgroups: gnu.utils.bug
From: ian@airs.COM (Ian Lance Taylor)
Subject: Cross compiling check fails in AC_TEST_PROGRAM in autoconf 1.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 10:51:46 GMT

The cross compiling check in AC_TEST_PROGRAM in autoconf 1.0 is wrong,
in that if you are not cross-compiling it will assume that you are.
Here is a patch, which should be self-explanatory.

--- /disk4/ian/gnu/autoconf-1.0/acgeneral.m4	Mon Jul 20 01:09:47 1992
+++ acgeneral.m4	Sun Jul 26 14:43:19 1992
@@ -312,7 +312,7 @@
 )dnl
 dnl
 define(AC_TEST_PROGRAM,
-[AC_PROVIDE([$0])ifelse([$4], , , [AC_REQUIRE([AC_CROSS_CHECK])if $cross_compiling
+[AC_PROVIDE([$0])ifelse([$4], , , [AC_REQUIRE([AC_CROSS_CHECK])if test -n "$cross_compiling"
 then
   $4
 else

Sorry I never noticed this before.
-- 
Ian Taylor | ian@airs.com | First to identify quote wins free e-mail message:
``It takes a man months and months to reconcile himself to a new hat.  And
  just when you're preparing to send it to the jumble sale, he says, `That's
  rather a nice hat you've got on, where did you get it?' ''

Newsgroups: gnu.utils.bug
From: thomasm@mechti.w.open.DE (Thomas Mechtersheimer)
Subject: Re: FIND-3.7 PROBLEMS
Reply-To: thomasm@mechti.w.open.de (Thomas Mechtersheimer)
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 13:37:12 GMT

Hi !

ian@case.co.UK (Ian Macpherson) writes:

>	lib/idcache.c:	on the Sequent sys/types.h doesn't declare
>			uid_t or gid_t. As a temporary fix I defined
>			each of these as u_short within #ifdef sequent.

That is true for Esix 3.2D too . No uid_t or gid_t defined in any header file.
Also there is no u_short, so I defined them as int .

   Thomas

-- 
Thomas Mechtersheimer - Zum Hasenkampsplatz 1 - D-5620 Velbert 15 - Germany
e-mail:  thomasm@mechti.w.open.de

Newsgroups: gnu.utils.bug
From: tap@src.honeywell.com (Thomas A Peterson)
Subject: indent-1.4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 20:05:53 GMT

Program : indent
Version : 1.4
Compiler : gcc 2.1
Machine : sparc-sun-os411
Description:

  'mymemcpy' is defined to return 'void' and 'char *'. The make failed
  with the following error:

socrates: make
gcc -O -g   -c globs.c -o globs.o
globs.c:69: conflicting types for `mymemcpy'
sys.h:48: previous declaration of `mymemcpy'
make: *** [globs.o] Error 1
socrates: 

Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: Enhancement for gnu tar/NFS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 03:32:34 GMT

   Resent-Date: Tue, 21 Jul 92 11:07 EDT
   Date: Tue, 21 Jul 92 11:07 EDT
   From: neal@ctd.comsat.com (Neal Becker)
   Sender: gnulists@ai.mit.edu
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   If you are stuck with NFS/root access problems ( like on HPUX
   machines ) you may find this patch useful.  This patch introduces the
   same kind of kludge as the chdir option (-C) to do seteuid.  For some
   reason I've forgotten, I called this (-E).  I use this to read user's
   files using NFS.  Use it like this:

   tar .... -E user1 ~user1 -Euser2 ~user2 ...

   Thus, we backup user1's files *as* user1, ...etc.  Neat, huh?

I would advise people *not* to do this.  It is much better to either
fix broken NFS implementations, or to run tar on the NFS server.  The
latter option will also make your backups run MUCH faster.  The backup
stripts distributed with GNU tar do this for you.


Newsgroups: gnu.utils.bug
From: tarjeij@extern.uio.NO
Subject: gas v1.38 missing file
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 17:23:06 GMT

I've tried to compile gas v1.38 (from a decus tape) and it failed due to a
missing file. The file is "a_out.h" (for vms) which is included from the file
"struc-symbol.h". If a newer version of gas contains the missing file then
please disregard this message.

Greetings,

// Tarjei T. Jensen - if it ain't broken, fix it anyway!
//    tarjeij@ulrik.uio.no       || +47 4 563411
//   Support you local rescue centre: GET LOST!
// Working, but not speaking for the Norwegian Hydrographic Service.

Newsgroups: gnu.utils.bug
From: jwe@che.utexas.EDU (John Eaton)
Subject: Autoconf-1.0 and variable substitution.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 14:47:44 GMT

The autoconf manual states:

   To support `VPATH', each `Makefile.in' should contain two lines that
   look like:

     srcdir = @srcdir@
     VPATH = @srcdir@


This works great, but I have a need to set VPATH to something like

   VPATH = @srcdir@:@srcdir@/../foobar

but this doesn't work -- the second @srcdir@ isn't expanded because
autoconf only performs one substitution on each line.  I have been
using something like this

   srcdir = @srcdir@
   VPATH = $(srcdir):$(srcdir)/../foobar

but now I see that the autoconf manual also saysI

   Do not set `VPATH' to the value of another variable, for example
   `VPATH = $(srcdir)', because some versions of `make' do not do variable
   substitutions on the value of `VPATH'.


Is there any reason that autoconf should only perform one substitution
on each line?

--
DEC Fortran brings VAX FORTRAN quality to RISC | John W. Eaton 
ULTRIX and DEC OSF/1.   -- DEC catalog (1992). | jwe@che.utexas.edu



Newsgroups: gnu.utils.bug
From: johne@tplrd.tpl.oz.AU (John Eldred)
Subject: gmake variables bugged?
Organization: Telectronics Pacing Systems
Distribution: gnu
Date: Wed, 22 Jul 1992 06:21:59 GMT

Can anyone explain why recursively expanded variables are expanded in the
command part of a rule, but not in the target or dependency part, e.g.

x=      X
xxx:    $(x)
        echo $(x)

gmake (vers 3.59) says "No way to make target X", but

xxx:    $(x)
        echo $(x)
x=      X

echos 'X', i.e. x is expanded in the command, but not the dependency. Also,

x=      X
$(x):;  echo $(x)

echos 'X', but

$(x):;  echo $(x)
x=      X

gmake says "missing target name", i.e. x is expanded in the command, but not the
target.
-- 
+-----------------------+-----------------------------+----------------+
| John Eldred           | Telectronics Pacing Systems |                |
| Software Person       | 7 Sirius Rd Lane Cove 2066  | No disclaimer. |
| johne@tplrd.tpl.oz.au | NSW Australia               | No quote.      |
+-----------------------+-----------------------------+----------------+

Newsgroups: gnu.utils.bug
From: marke@ssd.fsi.COM (Mark Easter)
Subject: 3.62.16 Makefile.in bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 13:47:40 GMT

The following rule pulls errors due to the the $remote.c<.

remote.o: remote.c
 $(CC) $(CFLAGS) $(defines) $(REMOTE) -c -I$(srcdir) $remote.c<
 
_______________________________________________________________
                                                                    /|  -
Mark W. Easter            FlightSafety International               / | /|
Staff Engineer            Simulation Systems Division         -----------
Computer Systems Group    Broken Arrow, Oklahoma 74012    Flight   \ |   
marke@fsi.com             918-251-0500   Fax 251-5597        Safety \|SSD
_________________ "1st in FAA Phase II Certifications" ____________________

Newsgroups: gnu.utils.bug
From: robert@tcs.com (Robert Blumen)
Subject: gnu make bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 17:14:32 GMT

GNU Make version 3.62, by Richard Stallman and Roland McGrath.
running on:
SunOS Release 4.1.1 (GENERIC) #1: Thu Oct 11 10:25:14 PDT 1990

I have found what I believe to be a bug in gnu make.

Here is my makefile:

----------------------------------------------------------------------

% : %.example
	cp $< $@

----------------------------------------------------------------------

If the target file has a dot in its name, this rule does not work.  As far
as I can tell from the documentation, it should work.  This rule works with
SunOS make.

kohlrabi: integration > ls *.example
foo.example     foo.h.example
kohlrabi: integration > gmake -f mf foo
gmake -f mf foo
cp foo.example foo
kohlrabi: integration > gmake -f mf foo.h
gmake: *** No way to make target `foo.h'.  Stop.

// "make" is SunOS make
kohlrabi: integration > make -f mf foo.h
make -f mf foo.h
cp foo.h.example foo.h

I have discovered a workaround.   If I use the Makefile:

----------------------------------------------------------------------

foo.h : % : %.example
        cp $< $@

----------------------------------------------------------------------

then it works.

Robert

-----------------------------------------------------------------------------
Robert Blumen                          | robert@tcs.com
Senior Software Engineer               | 2121 Allston Way, Berkeley, CA 94704
Teknekron Communications Systems, Inc. | (510) 649-3759

Newsgroups: gnu.utils.bug
From: greg@bar.UUCP
Subject: Re: groff and man pages without page breaks?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 16:12:03 GMT

I am wondering if the original question is motivated by wanting an
output format suitable for viewing on a computer display instead of on
paper.  The designs of groff and of TeX seem unsuitable for this
purpose, and I do not know if either can be coerced into producing
suitable output.

In hopes of starting a discussion about how a formatter should work
for producing output to read on a display, here are some of my thoughts:

(1) Headers and footers should be put into the dvi output as specials
so that the display program can maintain them at the top and bottom of
the view window as the text is scrolled or paged.

(2) Other specials are needed to distinguish paragraphs from figures
and tables, and make it clear which ones can be filled and which must
be panned.

(3) Paragraph numbers should replace page numbers.  (Line numbers are
useless if the view program reformats paragraphs to fit in the view window.)

I do not know if dvi can be turned into a suitable medium for text
browsers or not, but even a partial job would be useful given the
large amount of text in roff or TeX form.

_Greg


J. Greg Davidson	Institute for Software Research and Development
+1 (619) 452-8059       6231 Branting Street  San Diego, CA  92122  USA
 
vis!greg@nosc.mil					ucsd----+--vis
vis!greg@ucsd.edu		 			nosc----|

Newsgroups: gnu.utils.bug
From: scotte@cdsac.UUCP (L. Scott Emmons)
Subject: Bug fixes for "elisp-manual-1.03" C programs.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 04:48:08 GMT

Greetings,

I've found a problem in two of the C files shipped in the
"elisp-manual-1.03" package when compiling under AIX. Here are the
diffs of the changes required to get the "makeinfo" program to compile
on the RS/6000:

--------------
| makeinfo.c |
--------------
36,39d35
< #if defined (_AIX)
< #include <time.h>
< #endif
< 
66,68d61
< #if defined (_AIX)
< #pragma alloca
< #else
70d62
< #endif

------------
| getopt.c |
------------
47,49d46
< #if defined (_AIX)
< #pragma alloca
< #else
51d47
< #endif


If you have any questions, please email me at:

	...!csusac.csus.edu!cdsac!scotte

Thank you very much!!!
-Scott
From: madler@vssad.enet.DEc.COM (Michael C. Adler)
Newsgroups: gnu.utils.bug
Subject: tar 1.10 bug
Date: 29 Jul 92 20:00:19 GMT
Distribution: gnu
Organization: GNUs Not Usenet

The following diff file for create.c in tar 1.10 fixes two bugs:

1.  Off by 1 error in deciding whether another extended header is needed
    when creating a sparse file caused the last sparse table entry not
    to be emitted.

2.  Long link pathnames were read into too short a buffer causing overwrite.


*** create.c.orig	Mon Jul  1 14:20:22 1991
--- create.c	Wed Jul 29 15:38:31 1992
***************
*** 26,31 ****
--- 26,32 ----
   */
  #include <sys/types.h>
  #include <sys/stat.h>
+ #include <errno.h>
  #include <stdio.h>
  
  #ifndef V7
***************
*** 513,519 ****
  /*			sum += i;
  			if (sum < upperbound)
  				goto extend;*/
! 			if (index_offset+i < upperbound) {
  				index_offset += i;
  				exhdr->ext_hdr.isextended++;
  				goto extend;
--- 514,520 ----
  /*			sum += i;
  			if (sum < upperbound)
  				goto extend;*/
! 			if (index_offset+i <= upperbound) {
  				index_offset += i;
  				exhdr->ext_hdr.isextended++;
  				goto extend;
***************
*** 592,613 ****
  	case S_IFLNK:			/* Symbolic link */
  	{
  		int size;
  
  		hstat.st_size = 0;		/* Force 0 size on symlink */
  		header = start_header(p, &hstat);
  		if (header == NULL) goto badfile;
! 		size = readlink(p, header->header.linkname, NAMSIZ);
  		if (size < 0) goto badperror;
! 		if (size == NAMSIZ) {
! 			char buf[MAXPATHLEN];
  
- 			readlink(p,buf,MAXPATHLEN);
  			/* next_mangle(header->header.linkname); */
  			add_symlink_mangle(buf,p,header->header.linkname);
  			msg("symbolic link %s too long: mangling to
%s",p, header->header.linkname);
  			/* size=strlen(header->header.linkname); */
! 		} else
! 			header->header.linkname[size] = '\0';
  		header->header.linkflag = LF_SYMLINK;
  		finish_header(header);		/* Nothing more to do to it */
  	}
--- 593,615 ----
  	case S_IFLNK:			/* Symbolic link */
  	{
  		int size;
+                 char buf[MAXPATHLEN+1];
  
  		hstat.st_size = 0;		/* Force 0 size on symlink */
  		header = start_header(p, &hstat);
  		if (header == NULL) goto badfile;
! 		size = readlink(p, buf, MAXPATHLEN);
  		if (size < 0) goto badperror;
!                 buf[size] = '\0';
! 		if (size >= NAMSIZ) {
  
  			/* next_mangle(header->header.linkname); */
  			add_symlink_mangle(buf,p,header->header.linkname);
  			msg("symbolic link %s too long: mangling to
%s",p, header->header.linkname);
  			/* size=strlen(header->header.linkname); */
! 		} else {
!                         strncpy(header->header.linkname,buf,NAMSIZ);
!                 }
  		header->header.linkflag = LF_SYMLINK;
  		finish_header(header);		/* Nothing more to do to it */
  	}
Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: autoconf: exit status
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 12:37:43 GMT

In Autoconf 1.0, if there are undefined macros in configure.in, the
autoconf script doesn't exit with bad status.

Newsgroups: gnu.utils.bug
From: rouilj@dl5000.bc.edu (John P. Rouillard)
Subject: bug with +info-file long ops in gnu-tar 1.10
Organization: Institute for Space Research, Boston College
Distribution: gnu
Date: Mon, 27 Jul 1992 00:22:19 GMT

Specifying "+info-file" on the command line for gny tar version 1.10
doesn't work.  However the short option, -F, does work.  The problem
is with the initialization of the options parsing structure in tar.c.

The following context diff should fix it.

BTW, does anybody have an up to date manual for gtar?

===================================================================
RCS file: /sources/cvsrepos/gtar/tar.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 tar.c
--- 1.1.1.1	1991/12/17 03:45:37
+++ tar.c	1992/07/26 22:31:16
@@ -186,7 +186,7 @@
 	{"incremental",		0,	0,			'G'},
 	{"listed-incremental",	1,	0,			'g'},
 	{"multi-volume",	0,	&f_multivol,		1},
-	{"info-script",		1,	&f_run_script_at_end,	1},
+	{"info-script",		1,	0,			'F'},
 	{"absolute-paths",	0,	&f_absolute_paths,	1},
 	{"interactive",		0,	&f_confirm,		1},
 	{"confirmation",	0,	&f_confirm,		1},

-- John

Newsgroups: gnu.utils.bug