HDTenEightyP/NetNews huggingface dataset:
From: scott@sctc.com (Scott Hammond)
Subject: possible bug in gas-1.38 (m68k configuration)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 13 Nov 1992 01:34:11 GMT

Configuration:  gas-1.38(.1?) m68k.h->m-generic.h
                assember is used for cross-assembly
                host: sun4, sunos4.1.2
                gas run with no options.

It appears there is a bug in gas.  In this hand coded routine, the
'movw' and 'jmp' instructions show the wrong address for 'jtab' in the
disassembly.

||| This does not work, in the disassembly following, the references to
||| jtab do not refer to the correct address.
        .text
fun:
        bfextu  sp@(20){#0:#4},d0
        movw    pc@(jtab,d0:w:2),d0
        jmp     pc@(jtab,d0:w)

jtab:
        .word   badframe-jtab
        .word   threeword-jtab
        .word   fourword-jtab
        .word   fpcp-jtab
        .word   busfault-jtab
        .word   badframe-jtab

badframe:
        illegal
threeword:
        rtr
fourword:
        illegal
fpcp:
        illegal
busfault:
        illegal

Disassembly of section .text:
00000000 (jtab-)0016 bfextu sp@(20),0,4,d0
00000006 (jtab-)0010 movew 0x10[d0.w*2],d0      ||| 0x10 should be 0x16
0000000e (jtab-)0008 jmp 0x10[d0.w]             ||| 0x10 should be 0x16
00000016 (jtab+)0000 orb #14,a4
0000001a (jtab+)0004 orb #18,a0@
0000001e (jtab+)0008 orb #12,a4@
00000022 (badframe+)0000 illegal
00000024 (threeword+)0000 rtr
00000026 (fourword+)0000 illegal
00000028 (fpcp+)0000 illegal
0000002a (busfault+)0000 illegal

||| Noting that the addresses were off by 6 bytes the following 
||| is an evil workaround
        .text
fun:
        bfextu  sp@(20){#0:#4},d0
        movw    pc@(jtab2,d0:w:2),d0
        jmp     pc@(jtab2,d0:w)

jtab:
        .word   badframe-jtab
        .word   threeword-jtab
        .word   fourword-jtab
jtab2:
        .word   fpcp-jtab
        .word   busfault-jtab
        .word   badframe-jtab

badframe:
        illegal
threeword:
        rtr
fourword:
        illegal
fpcp:
        illegal
busfault:
        illegal

Newsgroups: gnu.utils.bug
From: jeg@ced.berkeley.edu (James Ganong)
Subject: gnu tar 1.11.1 bug report this fix
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 06:55:16 GMT

this may be a duplicate of a note i sent a minute ago,
but i think it did not make it out, so i am resending.

using gnu tar-1.11.1 i see the following problem on an decstation 5000/25,
but not on an sgi.  it erroneously thinks that directories has been renamed. 

% mkdir d
% mkdir d/d
% ./tar --verbose --create --file /tmp/foo --listed-incremental r d
./tar: Directory d/d is new
d/
d/d/
% !.
./tar --verbose --create --file /tmp/foo --listed-incremental r d
./tar: directory d/d has been renamed.
d/
d/d/

*** gnu.c.orig	Wed Nov  4 22:13:54 1992
--- gnu.c	Wed Nov  4 22:28:28 1992
***************
*** 160,166 ****
  		if(strp[-1]=='\n')
  			strp[-1]='\0';
  		strp=buf;
! 		dev=atol(strp);
  		while(isdigit(*strp))
  			strp++;
  		ino=atol(strp);
--- 160,166 ----
  		if(strp[-1]=='\n')
  			strp[-1]='\0';
  		strp=buf;
! 		dev=strtoul(strp,(char **) NULL, 10);
  		while(isdigit(*strp))
  			strp++;
  		ino=atol(strp);

Newsgroups: gnu.utils.bug
From: korn@med-in.uni-sb.DE (korn)
Subject: problen with fileutils-3.4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 10:24:10 GMT

Hi

I am working on a
	SINIX-F ukh840 V5.24 N14 MX550 
Machine (says uname -a).

I had a Problem in installing fileutils-3.4.

In file system.h (and also in backupfile.c, savedir.c) in directory lib
there is defined

	#ifdef direct
	#undef direct
	#endif
	#define direct dirent

in /usr/include/dirent.h on my machine is defined

	#define dirent direct
	...
	struct direct{ /* definition of struct direct */
	...
	}

a make resulted in

	backupfile.c:141 [error] infinite expansion of direct


So i changed 

	#ifdef direct
	#undef direct
	#endif
	#define direct dirent

to

	#ifndef sinix
	#	undef direct
	#	endif
	#	define direct dirent
	#endif

to outcomment the hack
and could build fileutils-3.4.

Bye
Heinfried Korn
korn@med-in.uni-sb.de


Newsgroups: gnu.utils.bug
From: bas@phys.uva.NL (Bas de Bakker)
Subject: GNU tar 1.11.1 bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 12:22:24 GMT

I tried to install GNU tar 1.11.1 on an IBM RS6000 running AIX 3.2.0.
The following seems to be wrong:

In buffer.c, on line 1133, there is a switch(WTERMSIG(status)). It is
obvious from the code that follows that the code assumes a 0 for
WTERMSIG(status) when there was no signal. On this system, however,
the macro returns a -1 in that case.

Hope this helps, I'll gladly supply more information if needed.

Bas de Bakker.

Newsgroups: gnu.utils.bug
From: bothner@cygnus.com
Subject: Re: Install binutils 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 04:15:34 GMT

> On binutils 2.0, (on sunos 4.1.2), in opcodes there is a rule under
> install:
>         $(INSTALL_DATA) libbfd.a $(libdir)/libbfd.a
>         $(RANLIB) $(libdir)/libbfd.a
>
> Shouldn't this be libopcodes?

Yes.  The current opcodes/Makefile.in has:

install:
	-parent=`echo $(libdir)|sed -e 's@/[^/]*$$@@'`; \
	if [ -d $$parent ] ; then true ; else mkdir $$parent ; fi
	-if [ -d $(libdir) ] ; then true ; else mkdir $(libdir) ; fi
	$(INSTALL_DATA) $(TARGETLIB) $(libdir)/libopcodes.a
	$(RANLIB) $(libdir)/libopcodes.a

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.utils.bug
From: uddeborg@sisug.sisu.SE (Goeran Uddeborg)
Newsgroups: gnu.utils.bug
Subject: finger 1.37 makefile
Date: 12 Nov 92 17:44:04 GMT
Distribution: gnu
Organization: GNUs Not Usenet

The makefile in the lib subdirectory does not pass the CC variable on
to the make in the subdirectory site.

Suggested fix:
--- Makefile.in.org     Thu Oct 22 20:22:12 1992
+++ Makefile.in Thu Nov 12 16:42:47 1992
@@ -64,7 +64,7 @@
        $(RANLIB) libfinger.a
 
 $(SITE_OBJECTS): $(SITE_SOURCES)
-       (cd site; $(MAKE) all)
+       (cd site; $(MAKE) CC="$(CC)" all)
 
 $(SITE_SOURCES): $(srcdir)/../config.h $(INCLUDES)/fingerpaths.h
 
Newsgroups: gnu.utils.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: mtools
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Thu, 5 Nov 1992 16:31:06 GMT

I'm a user of mtools on a sparcstation (mtools 2.0.7 was recently released).

I had an older version of mtools which I got running with shared libraries.  
(Primarily to learn how sun shared libraries worked).

It seems all the mtools programs should be links to one main program, and
all the global declarations need to be segregated into one place...

I also wonder if zip should be included into the gnu distribution (if it can be).

What I want to be able to do is pipe from/to mtools/zip so I can easily
write/read zip files from floppy disks... (without having to make copies
everywhere).


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

Newsgroups: gnu.utils.bug
From: lord+@andrew.cmu.edu (Tom Lord)
Subject: Oleo-1.0 maintainer
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 8 Nov 1992 07:30:33 GMT

As a few people have noted, the BUGS file oleo-1.0 doesn't contain a
mail address for reporting bugs, as it should.  Bugs may be sent to
oleo-bugs@prep.ai.mit.edu, though I also read bug-gnu-utils.

Bug fix releases of oleo will be occuring every 2-3 weeks.  I'll be
sure this address is in future releases.  Sorry for the confusion.

Thanks for the report.

-t
Newsgroups: gnu.utils.bug
From: nessus@mit.edu (Douglas Alan)
Subject: gtar bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 10:14:51 GMT

I reported this bug a while back to gnu.utils.bug, but Michael
Bushnell told me recently that postings to gnu.utils.bug might not
make it to the right place, so here it is again, just in case.

BUG REPORT:

Program: GNU tar.  Version: 1.10.  Architecture: DEC MIPS Ultrix 4.2a
Problem: I used GNU tar to copy a large filesystem (800 megabytes)
from one machine to another, like so:

     # cd /u2; gtar olcf - . | rsh fire "(cd /u2; gtar xfp -)"

I used the "-o" option because FIRE is an NFS server and does not have
a copy of the password file used on MEDIA-LAB (the source machine),
nor does it run YP; therefore, it would not know what to do with the
user names used in a new format GNU tar file.  (An NFS server doesn't
need to know user names -- only the uid's are significant.)  The files
all made it over to FIRE fine, but there were some problems with
permissions and ownership.  Every copied directory on FIRE was copied
without preserving the permissions of the directory: every directory
made by gtar on FIRE ended up in mode 777.  Furthermore, not all of
the ownership information made it through the copy.  Most of the files
now on FIRE ended up with the correct ownership, but sprinkled
throughout the filesystem in an apparently random manner were files
left owned by root.  (These files were not owned by root on
MEDIA-LAB.)

SUGGESTION:

It should be possible to have an archive store uid's rather than user
names without going into old archive format mode.  A user may want to
copy files to a system without a password file yet still gain the
advantages provided by the new archive format.

|>ouglas /\lan
   MIT Media Lab
   Systems Programming Group
   <nessus@mit.edu>

Newsgroups: gnu.utils.bug
From: jwe@che.utexas.EDU (John Eaton)
Subject: Oleo-1.0 prints incorrect version
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 00:09:13 GMT

When oleo-1.0 starts up, it prints

  Oleo version 0.03.2, Copyright (C) 1990 Free Software Foundation, Inc.

instead of

  Oleo version 1.0, Copyright (C) 1990 Free Software Foundation, Inc.

Probably because there are two places that where the version number
must be changed in io_term.c.

--
John W. Eaton      | 4.3BSD is not perfect.  -- Leffler, et al. (1989).
jwe@che.utexas.edu |

Newsgroups: gnu.utils.bug
From: jrs@world.std.com (Rick Sladkey)
Subject: GNU time-1.4 misreports times
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 22:51:18 GMT

GNU time-1.4 misreports times when the fractional seconds are less
than 0.10 by omitting the leading zero in the tenths place.  For
example: 0.09 seconds is reported as 0.9 seconds.
-----
--- orig/time-1.4/time.c	Wed Oct 28 14:21:05 1992
+++ time-1.4/time.c	Sat Nov  7 03:30:26 1992
@@ -388,11 +388,11 @@
 	      fprintf (fp, "%ld", rup->ru_minflt);
 	      break;
 	    case 'S':		/* System time.  */
-	      fprintf (fp, "%ld.%ld",
+	      fprintf (fp, "%ld.%02ld",
 		       rup->ru_stime.tv_sec, rup->ru_stime.tv_usec / 10000);
 	      break;
 	    case 'U':		/* User time.  */
-	      fprintf (fp, "%ld.%ld",
+	      fprintf (fp, "%ld.%02ld",
 		       rup->ru_utime.tv_sec, rup->ru_utime.tv_usec / 10000);
 	      break;
 	    case 'W':		/* Times swapped out.  */
@@ -409,7 +409,7 @@
 	      fprintf (fp, "%ld", rup->ru_nivcsw);
 	      break;
 	    case 'e':		/* Elapsed real time in seconds.  */
-	      fprintf (fp, "%ld.%ld", tv->tv_sec, tv->tv_usec / 10000);
+	      fprintf (fp, "%ld.%02ld", tv->tv_sec, tv->tv_usec / 10000);
 	      break;
 	    case 'k':		/* Signals delivered.  */
 	      fprintf (fp, "%ld", rup->ru_nsignals);

Newsgroups: gnu.utils.bug
From: uddeborg@sisug.sisu.SE (Goeran Uddeborg)
Subject: finger 1.37 special targets
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 18:02:54 GMT

I tried to make a new special target, with different behaviour for
long and short fingering.  I then discovered that I always got the
short answer, independent of the flags given.  I traced this down to
in.fingerd.c where a check is made to look for special target scripts
with an s- or x- prefix.  This attempt is made irrespectively of the
value of the is_long_finger flag, and before the special code for long
fingers are executed.  I solved the problem by moving the test later
in the code, but I'm not sure if may I have introduced some other
problem with this fix.  Anyway, this is how I made it:

--- in.fingerd.c.org	Tue Oct 27 04:14:19 1992
+++ in.fingerd.c	Thu Nov 12 16:34:33 1992
@@ -371,10 +371,6 @@
       return;
     }
 
-  if (maybe_special_target (user, stream, 's')
-      || maybe_special_target (user, stream, 'x'))
-    return;
-
   /* Is this a local finger?  If so, just call the local client finger
      daemon to get packets, and print them out. */
   if (xstricmp (user, ".local") == 0)
@@ -453,6 +449,10 @@
 
       return;
     }
+
+  if (maybe_special_target (user, stream, 's')
+      || maybe_special_target (user, stream, 'x'))
+    return;
 
   /* If the user wants to know about free machines then look the information
      up in the database kept on the availability of hosts.  Print statistics

Newsgroups: gnu.utils.bug
From: nico@bredex.DE
Subject: bugs or enhancements for regex-0.11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 15:37:54 GMT

Hi folks,
using codecenter i got some notes that may interest
you:

Using:  regex.c, test/iregex.c, test/upcase.c

general problems:

  regex.c:   line 4814:  2nd param "preg" not used
		solution: use /*ARGSUSED*/

  iregex.c:  line 38:  char pat[500] = "";  not allowed
		solution:  char pat[500];
			   ...
			   pat[0] = '\0';

	     line 52:  strlen() not defined
		solution:  #include <string.h>

	     line 37:  char c;  not used


run-time problems:

  PATTERN:  ab*
  STRING:   qqq

  regex.c:   line 2030 STORE_NUMBER(loc+1,arg);
			"losing info due to sign extension"
			arg: -9
		solution: i'm not sure, but there might
			  a cast to (unsigned) senseful

  iregex.c (or regex.c ?):
	     line 65, 69: calls print_regs() but
			  regs.num_regs is NOT set.
		solution: test return value of re_match()
			  and re_search()

		OR is it a bug ??
		Should re_match() and re_search() set
		regs.num_regs to 0 ???
		(please document it !!!)


This infos may be lowest priority but anyway i thought
they could help.
Would be glad to get a reply.

--------
Nico
                                 address: BREDEX GmbH
email:   nico@bredex.de                   Nicolai Josuttis
                                          Kastanienallee 2a 
phone:   +49 531 75480                    D-3300 Braunschweig
fax:     +49 531 796358                   Germany
--------

Newsgroups: gnu.utils.bug
From: chrisf@jna.COM.AU (Chris Ford)
Subject: GnuMake - file names
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 18:09:48 GMT

Some additional information regarding the mapping of ./file.c to file.c.

$ diff ~/gnu/make/hpux-3.58/read.c ~/gnu/make/hpux-3.62/read.c
1237,1240d1278
<       /* Remove leading `./' sequences.  */
<       while (p - q > 2 && q[0] == '.' && q[1] == '/')
<       q += 2;
< 

Is there a good reason that these lines have been removed from v3.62 ?

--
Regards,

Chris Ford
JNA Telecommunications
voice:  +61 2 417 6177
fax:    +61 2 417 8026
e-mail: chrisf@jna.com.au
post:   16 Smith St, Chatswood, NSW 2067, Australia.

----------------------------------------------------------------------------JNA


Newsgroups: gnu.utils.bug
From: evillarr@denali.csc.calpoly.edu (Emilia E. Villarreal)
Subject: GNU Bison version 1.18 --- documentation; plea for explanation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 4 Nov 1992 15:22:32 GMT

Hi.  I'm using GNU Bison version 1.18, and I'd like to know about the
use of the bison.hairy parser.

1.  Is this actually working or is it waiting for version 2?
2.  Is there any documentation available for the %semantic_parser and
    %guard keywords?  If so, how can I get it?

This is actually a re-request---I mailed in the initial approach last
Sunday night, Nov. 1.  But I haven't heard anything back, so I don't
know if my last request failed somehow to reach you.

Any information will be greatly appreciated.

Thanks,
Millie

Emilia E. Villarreal
evillarr@denali.calpoly.edu


Newsgroups: gnu.utils.bug
From: andy@scp.caltech.edu (Andy Fyfe)
Subject: gnutar 1.11.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 23:19:49 GMT

The following causes gnutar to dump core
	% gnutar -V test -v -c -f /tmp/files.tar *

The problem, according to gdb, is print_header is calling quote_copy_string
with the parameter current_file_name, which is NULL.  Attempting to access
the string causes the core dump.

The combination of -V and -v is necessary.

Gnutar is compiled on a sun4, sunos 4.1.2.

Andy Fyfe					andy@cs.caltech.edu

Newsgroups: gnu.utils.bug
From: leisner@eso.mc.xerox.COM ( Marty Leisner)
Subject: Problem with ls (fileutils 3.4)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 12 Nov 1992 01:56:36 GMT

I'm running on SunOS 4.1.2 on sparcs...

Trying to do ls -l on an automounter directory gave wierd results...
The system ls doesn't have these problems...

Using ls -l with the distributed ls I get:
ls -l /usr/AnswerBook
lrwxrwxrwx   1 root     wheel          15 Nov 11 20:48 /usr/AnswerBook -> /files4/AnswerB

when I should get:
leisner@annapurna$ ./ls -l /usr/AnswerBook
lrwxrwxrwx   1 root     wheel          15 Nov 11 20:46 /usr/AnswerBook -> /files4/AnswerBook

Working with the code, I saw a comment in get_link_name():
  /* Some automounters give incorrect st_size for mount points.
     I can't think of a good workaround for it, though.  *

This is true but very strange...
The workaround I came up with quickly was:
*** 1.1 1992/11/12 01:22:41
--- ls.c        1992/11/12 01:45:22
***************
*** 1017,1023 ****
  #ifdef _AIX
    register int bufsiz = PATH_MAX; /* st_size is wrong. */
  #else
!   register int bufsiz = f->stat.st_size;
  #endif
    register int linksize;
  
--- 1017,1025 ----
  #ifdef _AIX
    register int bufsiz = PATH_MAX; /* st_size is wrong. */
  #else
!   register int bufsiz = f->stat.st_size*2; /* these is a kludge trying to work around
!                                           * the automounter problem -- ml
!                                           */
  #endif
    register int linksize;
  


Essentially, make bufsiz bigger...it works in this case...

For symbolic links, it will waste some space...  I can't wait for a rational
OS with source....


Marty    leisner.henr801c@xerox.com 
 	 leisner@eso.mc.xerox.com 
          Member of the League for Programming Freedom 
 The Feynman Problem Solving Algorithm:
 1) Write down the problem
 2) Think very hard
 3) Write down the answer     -- Murray Gell-mann
From: leef@ruuci7.chem.ruu.nl (Bas Leeflang)
Newsgroups: gnu.utils.bug
Subject: screen_problems
Date: 6 Nov 92 08:23:08 GMT
Article-I.D.: RUUCI7.9211060823.AA12903
Distribution: gnu
Organization: GNUs Not Usenet

Hi,

I have some problems installing screen (3.2b) on a SG Iris.
We have a series of workstation using NIS (YP) and have disk mounted with NFS.

I ran ./configure and was able to make the executable. When  I invoke 'screen'
as root it work ok. However, when I use it as an ordinary user I get:

getpwuid() can't identify your account!

What can I do to resolve this and be able to realy use this nice program?

Bas Leeflang
Newsgroups: gnu.utils.bug
From: zoo@cygnus.com (david d `zoo' zuhn)
Subject: oleo-1.0 release problems
Organization: Cygnus Support -- +1 415 903 1400
Distribution: gnu
Date: Fri, 6 Nov 1992 18:30:52 GMT

This is regarding the oleo-1.0 release on prep.ai.mit.edu.

The BUGS file doesn't say who/where to send bug reports to.

The following patches were needed to get it to build and install on a sun4
running SunOS 4.

I haven't tried using it yet, but I got it to compile and install.

  david d 'zoo' zuhn |    There is great disorder under the heavens,
    cygnus support   |         and the situation is excellent.
    zoo@cygnus.com   |    



---------- slice 'n' dice --------------------------------------- file: odiffs
diff -ur oleo-1.0/Makefile.in oleo-1.0-zoo/Makefile.in
--- oleo-1.0/Makefile.in	Sun Nov  1 15:31:52 1992
+++ oleo-1.0-zoo/Makefile.in	Fri Nov  6 10:24:27 1992
@@ -35,6 +35,8 @@
 
 CC = @CC@
 BISON = @YACC@
+INSTALL = @INSTALL@
+INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 ETAGS = etags -tw
 CTAGS = ctags -tw
@@ -65,9 +67,9 @@
 	ANNOUNCE COPYING USING BUGS
 all: oleo
 install: all
-	$(INSTALL_PROGRAM) oleo $(@instdir)/oleo
+	$(INSTALL_PROGRAM) oleo $(bindir)/oleo
 uninstall:
-	rm $(@instdir)/oleo
+	rm $(bindir)/oleo
 clean:
 	rm -f $(all_objs) parse.tab.c core oleo
 distclean:
diff -ur oleo-1.0/io_utils.h oleo-1.0-zoo/io_utils.h
--- oleo-1.0/io_utils.h	Sun Nov  1 14:26:23 1992
+++ oleo-1.0-zoo/io_utils.h	Fri Nov  6 09:52:04 1992
@@ -24,7 +24,7 @@
 #ifdef __STDC__
 extern void clear_spreadsheet ();
 extern char *print_cell (CELL *);
-extern char *cell_value_string (int r, int c);
+extern char *cell_value_string (CELLREF r, CELLREF c);
 extern char *col_to_str (CELLREF);
 extern char *flt_to_str (double);
 char *backslash_a_string (char *, int);
Only in oleo-1.0: parse.tab.c
diff -ur oleo-1.0/utils.c oleo-1.0-zoo/utils.c
--- oleo-1.0/utils.c	Sun Nov  1 15:00:28 1992
+++ oleo-1.0-zoo/utils.c	Fri Nov  6 10:09:03 1992
@@ -609,44 +609,6 @@
 
 #endif
 
-/*
- * stricmp - compare string s1 to s2, ignoring case
- */
-
-int
-stricmp (s1, s2)
-     CONST char *s1;
-     CONST char *s2;
-{
-  register CONST char *scan1;
-  register CONST char *scan2;
-  register char chr1, chr2;
-
-  scan1 = s1;
-  scan2 = s2;
-  do
-    {
-      chr1 = isupper (*scan1) ? tolower (*scan1) : *scan1;
-      chr2 = isupper (*scan2) ? tolower (*scan2) : *scan2;
-      scan1++;
-      scan2++;
-    }
-  while (chr1 && chr1 == chr2);
-
-  /*
-	 * The following case analysis is necessary so that characters
-	 * which look negative collate low against normal characters but
-	 * high against the end-of-string NUL.
-	 */
-  if (chr1 == '\0' && chr2 == '\0')
-    return 0;
-  else if (chr1 == '\0')
-    return -1;
-  else if (chr2 == '\0')
-    return 1;
-  else
-    return chr1 - chr2;
-}
 
 /* strincmp - compare first N chars of strings S1 and S2 */
 int

Newsgroups: gnu.utils.bug
From: jeg@ced.berkeley.edu (James Ganong)
Subject: suggestion for confusing messages from tar-1.11.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 21:13:41 GMT

i think the messages that tar spits out with -v and -g are confusing.
here is my suggestion


the following part of gnu.c looks to see if it has seen a directory's
name before, and if its inode as changed.


                                if(dp=get_dir(namebuf)) {
                                        if(   dp->dev!=hs.st_dev
                                           || dp->ino!=hs.st_ino) {
                                                if(f_verbose)
                                                        msg("directory %s has be
en renamed.",namebuf);
                                                dp->allnew=1;
                                                dp->dev=hs.st_dev;
                                                dp->ino=hs.st_ino;
                                        }
                                        dp->dir_text="";
                                } else {
                                        if(f_verbose)
                                                msg("Directory %s is new",namebu

% mkdir e/e
% ./tar -cvf /dev/null -g r e
./tar: Directory e/e is	new
e/
e/e/
% mv e/e e/f
% ./tar -cvf /dev/null -g r e
./tar: Directory e/f is	new
e/
e/f/
% mkdir e/e
% rmdir e/f
% mv e/e e/f
% !.
./tar -cvf /dev/null -g	r e
./tar: directory e/f has been renamed.
e/
e/f/

I think that instead of "directory %s has been renamed" it should say
"directory %s is a new directory reusing an old directory name"

and instead of "Directory %s is new" it should say
"Directory %s is a new directory name"

Newsgroups: gnu.utils.bug