HDTenEightyP/NetNews huggingface dataset:
From: pinard@icule.UUCP (Francois Pinard)
Subject: questions about configure
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 19:48:53 GMT

   I have multiple versions of the configure shell script, because
   most of the GNU software now includes it. Consequently, I am having
   difficulty determining which one is the "correct" or "current"
   version. Can you please tell me how I can find this out?

There are two families of GNU configurators.  The bigger one is used
for GNU C/C++, GDB, C library, etc. and, so far that I know, is not
yet completely packaged as a stand-alone product.  The smaller one is
getting used for almost everything else, get it from prep.ai.mit.edu
in pub/gnu as autoconf-1.0.tar.Z.  There is an on-going effort to
merge the two configurators, I cannot predict if and when this effort
will succeed.

   1) I want to use one configuration script for configuring all
   software packages.

Unless you have inordinately complex needs, Autoconf should suffice.

   2) There seems to be discrepencies between documentation (as noted
   above)

The Autoconf manual, distributed with the product, seems to be
exhaustive and accurate.

   3) I have added some new targets to config.sub that would be of
   more widespread interest.

Autoconf approach is not to have a fixed set of definitions for a
finite number of targets, but rather to dynamically figure out how to
adapt to any given target by checking how this target would behave.
If it happens that Autoconf does not take the correct decision, you
might contribute improving its behaviour by discussing the matters on
bug-gnu-utils@prep.ai.mit.edu.

   I am building GNU software for native use on a SPARCstation 2, and
   also as cross-development tools for the Motorola 68K architecture.
   I would like to have the native configuration separate from the
   cross configuration, so that files don't get overwritten each time
   I run configure

Autoconf is geared towards multiple installations in different
subdirectories and cross configurations; the former certainly works
nicely, I have no experience with the later; but who knows, Autoconf
might be your best bet.  Your true configuration sources are short
configure.in files, which autoconf expands, using GNU m4, into
configure scripts which you then include in your distributions.

-- 
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: mly@ai.mit.edu (Richard Mlynarik)
Subject: Installation feature request
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 23:24:40 GMT

I've been installing various GNUish programs at a site where the
"installation" target directory is normally mounted read-only (to
enable replication and to avoid some types of accidental lossage.)
This target directory ("/import/gnu/") is copied from a writable
master directory hierarchy ("/import-writable/gnu/") on a regular
basis.

This causes problems with many of the "configure"-generated makefiles
because it is assumed that the target directory for installing
programs ("/import-writable/gnu/") is the same as the string which is
built into some programs as a default directory for finding
executables or data files.

For example, GCC 2.2.2 has the problem that "libdir" and "libsubdir"
are used both to specify where to install things (install-command) and
as part of a string built into some executables (eg cccp.o, gcc.o)
Note that it doesn't completely work to specify libdir as a relative
directory ("../../") because that means that a relative directory name
will get built into the exectutables.

Many other GNU installations break similarly in this situation.

It would be nice if people would make the effort to provide two
separate makefile variables for the two different cases of specifying
* where to install executables and data and where programs should
  write shared data (eg find database)
* where to expect to find installed executables and read-only data
  (eg gcc include and compiler phases.)

Newsgroups: gnu.utils.bug
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: strip error message
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 01:06:06 GMT

Hi,

I'm using strip in the Linux version. When I call strip on a file with
permissions 555 (no write permissions), I get an error message of the form:

strip: XXX: Not owner

where XXX are some non-Ascii characters.
First, "Not owner" is not totally correct ("Missing write permission" would
be better), second the XXX should be the filename...

Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de

Newsgroups: gnu.utils.bug
From: cudcv@csv.warwick.ac.UK (Rob McMahon)
Subject: fileutils-3.3 - chown broken
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 25 Jul 1992 15:00:01 GMT

Chown does not work on a Sun4, running SunOS 4.1.2, with gcc-2.2.2.
parse_user_spec is expecting a pointer to a uid_t and a pointer to a gid_t,
but is being passed the addresses of two ints.  This patch fixes the problem:

===================================================================
RCS file: chown.c,v
retrieving revision 1.1
diff -c -r1.1 chown.c
*** 1.1	1992/07/25 12:06:18
--- chown.c	1992/07/25 12:07:11
***************
*** 96,103 ****
       int argc;
       char **argv;
  {
!   int user = -1;		/* New uid; -1 if not to be changed. */
!   int group = -1;		/* New gid; -1 if not to be changed. */
    int errors = 0;
    int optc;
    char *e;
--- 96,103 ----
       int argc;
       char **argv;
  {
!   uid_t user = -1;		/* New uid; -1 if not to be changed. */
!   gid_t group = -1;		/* New gid; -1 if not to be changed. */
    int errors = 0;
    int optc;
    char *e;
===================================================================

Cheers,

Rob

Newsgroups: gnu.utils.bug
From: kitw@magnus.acs.ohio-state.edu (Kit Wang)
Subject: tar 1.10 Memory fault - core dumped
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 15:33:20 GMT

We do backup by gnu-tar and pipe to dd. Some students here at OSU sometimes
creates some bad filenames and that cause tar core dumped and the backup
aborted. What is the max length of filename that tar allowed?
Do you have a patch for tar that skip the bad filename and go on to next file?
Thank you for your help.

-----------------------------------------------------------------------------
/acs/bottom/0/staff/gnu_stuff/tar-dist-1.10/tar-1.10/tar: Removing leading / fro
m absolute path names in the archive.
/acs/bottom/0/staff/gnu_stuff/tar-dist-1.10/tar-1.10/tar: Removing leading / fro
m absolute links
/acs/bottom/0/staff/gnu_stuff/tar-dist-1.10/tar-1.10/tar: acs/magnusug/1/rmalloy
/The purpose of this examination is for you to demonstrate your competency in :
is too long: mangling to fbackup.0729920+13247 records in
: 3933 Memory fault - core dumped0+13247 records out
------------------------------------------------------------------------------


Kit Wang
OSU/ACS
kitw@magnus.acs.ohio-state.edu

Newsgroups: gnu.utils.bug
From: gros@cosmos.imag.fr (Patrick Gros)
Subject: Problem with basename in make 3.62
Followup-To: gnu.utils.bug
Organization: Institut Imag, Grenoble, France
Distribution: gnu
Date: Mon, 20 Jul 1992 14:55:01 GMT

Problem with the function basename of make 3.62

I have the following problem: did I misunderstand the doc or is it a real bug?
Any suggestion appreciated.

Version number of make:
GNU Make version 3.62, by Richard Stallman and Roland McGrath.
Copyright (C) 1988-1991 Free Software Foundation, Inc.

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?

Patrick GROS
-- 
-------------------------------------------------------------------------
Patrick GROS, Irimag-Lifia, 46 Avenue Felix Viallet 38031 Grenoble FRANCE
Tel: (33) 76 57 46 63, Fax: (33) 76 57 46 02, e-mail : gros@lifia.imag.fr
-------------------------------------------------------------------------

Newsgroups: gnu.utils.bug
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: compress bugs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 00:45:50 GMT

Hi,

Two bugs of uncompress alias zcat (I'm using them in the Linux version):

- uncompress may crash when applied to a compressed file that underwent
  transmission errors.

- zcat may remove the file!
  I'm using a filesystem with filename length limited to 14 characters.
  So a file bigblablabla.tar.Z is called bigblablabla.t on this filesystem.
  When I execute
         zcat bigblablabla.t | tar -tf -
  and interrupt it with Ctrl-C,
  the file bigblablabla.t gets removed!
  I would understand that if I were using uncompress. But zcat (linked
  to uncompress) should NEVER remove a file!

I hope this bug report reaches the maintainers of GNU compress 4.0.1.

Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Autoconf: some missing `checking' comments
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 12:03:23 GMT

With Autoconf 1.0, I think there is no `checking ...' comment issued
for AC_UID_T, AC_SIZE_T, AC_PID_T and AC_RETSIGTYPE.

-- 
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!
From: meyering@cs.utexas.edu (Jim Meyering)
Newsgroups: gnu.utils.bug
Subject: determining utility version [Re: Some wierdness with gnu ls]
Date: 30 Jul 1992 16:54:31 -0500
Organization: U of TX at Austin CS Dept
Distribution: gnu
NNTP-Posting-Host: ai.cs.utexas.edu

There is a way to determine the version of the
GNU shell/file/text-utils, but it's not through an option.

If you have the `strings' command, this may work for you:

  strings - `which ls' |grep -iw version

The following shell function works for me using Bash.
    ver () { strings - "$@" | grep -iw version }

---
Jim Meyering             | Member of the League for Programming Freedom
meyering@cs.utexas.edu   | Contact me or league@prep.ai.mit.edu for more info.

In article <1992Jul29.163042.27106@spectrum.xerox.com> leisner.henr801c@xerox.com writes:
>Also, ls should have some type of version option.

>marty
>leisner.henr801c@xerox.com  
>Member of the League for Programming Freedom
-- 
Jim Meyering             | Member of the League for Programming Freedom
meyering@cs.utexas.edu   | Contact me or league@prep.ai.mit.edu for more info.
From: rommel@informatik.tu-muenchen.DE (Kai-Uwe Rommel)
Newsgroups: gnu.utils.bug
Subject: groff and man pages without page breaks?
Date: 23 Jul 92 23:53:28 GMT
Distribution: gnu
Organization: Technische Universitaet Muenchen, Germany

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?

Thanks,
Kai Uwe Rommel

/* Kai Uwe Rommel --- rommel@informatik.tu-muenchen.de */

DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be.                -Russell Williams
Newsgroups: gnu.utils.bug
From: ian@case.co.UK (Ian Macpherson)
Subject: FIND-3.7 PROBLEMS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 11:00:57 GMT

Hello,

	We've just got find-3.7 and have built it successfully on our
	SUN systems. However, on a Sequent Balance machine running
	DYNIX V3.0.14 it fails to compile as follows:

	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.

	Sorry for building find on such an old machine!

+-----------------------------------------------------------------------+
|Ian Macpherson								|
|Dowty Communications Ltd.		Phone:	+44 (923) 258229	|
|Caxton Way,				Fax:	+44 (923) 258890	|
|Watford,				Email:	ian@case.co.uk		|
|Herts. WD1 8XH.							|
|United Kingdom.							|
+-----------------------------------------------------------------------+

Newsgroups: gnu.utils.bug
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: stty sane
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 26 Jul 1992 00:55:52 GMT

Hi,

To the maintainer of GNU stty:

I'm using GNU stty in the Linux version. 'stty sane' does not always do the
best possible defaults: I have xterm running sh, and I execute 'stty sane'.
This changes
	ignbrk	to  -ignbrk
	-brkint to  brkint
	-iexten to  iexten
	-echoe  to  echoe
	-echok  to  echok
	-echoctl to echoctl
	-echoke to  echoke
and     min=1   to  min=0.
The first seven changes don't matter for me, but the last badly affects
my xterm: "ll | more" (which used to work before) outputs one screenful
of information and then ends with error message "Broken pipe".
min=0 lets more think that EOF was reached in input!

Could this behaviour be corrected?

Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de

Newsgroups: gnu.utils.bug
From: faccioli@icl220.cilea.it (Ezio Faccioli)
Subject: text utils configuration problems
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 20:51:05 GMT

./configure fails to recognize that my system has not a lot of things;
I edited the makefile and everything is all right, but, what is wrong
in my system? (my system is a FPS 521, running fpx4.3.2, a bsd4.3 or
4.2 derivative, I don't know - a mix? a job half done? boh!)

my understanding of the tests made by config is partial (at least...),
so that I'd like an explanation of the details of these tests, to see
if it's possible to fix them (possible for me, I mean) or I have to do
by hand the configuration of the one hundred makefiles in gnu
distribution...

if you'd like some detail, I am here.

Thank you for your kind attention, best regards,

			Giacomo Boffi
			Dept.Struct.Engn., Politecnico di Milano
			I - 20133 MILANO

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU find 3.7 installation report
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 12:19:31 GMT

This is an installation report for GNU find 3.7 on a 386/ix 2.0.2
system, using GNU C 1.40 under COFF-encapsulation.  There were quite
numerous compilation errors in lib/idcache.c.  I solved them by
applying the following patch and calling autoconf before configuring.
Besides this little thing, everything went perfectly.

--- 1.1	1992/07/30 11:55:53
+++ find-3.7/configure.in	1992/07/30 11:56:18
@@ -41,6 +41,7 @@
 
 AC_STDC_HEADERS
 AC_UNISTD_H
+AC_UID_T
 AC_USG
 AC_REPLACE_FUNCS(fnmatch memset stpcpy strdup strftime strspn strstr strtol)
 AC_HAVE_FUNCS(strerror)

-- 
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!
From: pds@lemming.webo.dg.com (Paul D. Smith)
Newsgroups: gnu.utils.bug
Subject: autoconf 1.0 ideas...
Date: 23 Jul 92 12:52:46 GMT
Distribution: gnu
Organization: GNUs Not Usenet

A few ideas for additional doodads in autoconf (I haven't gotten
around to adding them myself yet, just having obtained autoconf about
an hour ago, but thought I'd mention them to see if anyone has any
opinions...):

1)  It'd be nice if there were some configuration for building man
    pages instead of just copying them, so that SysV systems that have
    a /usr/catman instead of /usr/man can have man pages compiled
    correctly.

    I use something like this in my makefiles:

    mandir = /usr/local/man
    manext = 1

    #makeman = 
    #makeman = | eqn | tbl | nroff -man | col -x
    makeman = | groff -Tlatin1 -man -et | col -x

    #packman = :
    #packman = compress
    packman = pack

    install.man:
            -cat foo.man $(makeman) > $(mandir)/foo.$(manext);\
                $(packman) $(mandir)/foo.$(manext)

    Then on systems with /usr/man you use the empty version of
    $(makeman).  You could figure out whether or not to pack/compress
    the man page by looking to see if the normal man pages are packed
    (foo.1.z) or compressed (foo.1.Z).

2)  I'd like to see _sys_siglist[] and variants handled: I've seen the
    following variants:

        _sys_siglist[]
        sys_siglist[]
        const char *dg_strsignal()

    Perhaps the configuration could defined a macro, say STRSIGNAL(),
    which takes a signal number as an argument and returns a char*
    which is a text name for the signal, or something like
    "<unavailable>" if there is no siglist or the signal is not a
    member of the list.

                                                                paul
-----
 ------------------------------------------------------------------
| Paul D. Smith                          |    paul_smith@dg.com    |
| Data General Corp.                     | pds@lemming.webo.dg.com |
| Network Systems Development Division   |                         |
| Open Network Systems Development       |   "Pretty Damn S..."    |
 ------------------------------------------------------------------
Newsgroups: gnu.utils.bug
From: wb104@mbuf.bio.cam.ac.uk (Wayne Boucher)
Subject: bison: reader.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 15:40:15 GMT

Hello, I have just compiled Bison version 1.18.  There is a bug that was
discovered by cc (but not gcc) in the file reader.c.  The compiler noticed
that line 907 is never reached (in the procedure copy_guard).  This is
because of the spurious semi-colon at the end of the if statement on line 904.
Sorry if this has already been pointed out to you ten zillion times.
Wayne Boucher (wb104@mbuf.bio.cam.ac.uk)

Newsgroups: gnu.utils.bug
From: fpb@ittc.wec.COM (Frank P. Bresz)
Subject: RCS usage not in the RCS/ directory.
Organization: Westinghouse, ITTC, Pgh, PA.
Distribution: gnu
Date: Sun, 26 Jul 1992 13:14:42 GMT

GNU Make version 3.62, by Richard Stallman and Roland McGrath.

Hello,

	I am trying to get make to be able to pull RCS from an alternate
	directory using the following pattern rules.

% :: RCS/%_v
	test -f $@ || checkout $@

% :: /local/kkldev/dev/src/iss/$(DIRECTORY)/RCS/%_v
	test -f $@ || checkout $@

	Yes I know _v is non-standard but I have to work with a VAX/VMS
	system as my NFS server which is why I must do this in the first
	place, it (the VAX) doesn't support symlinks.  'checkout' is just a
	wrapper to 'co' to do some extra checking.

	This works fine and dandy as long as everything is in the current
	directory I define DIRECTORY using this.

CURDIR = $(shell pwd)

DIRECTORY = $(notdir $(CURDIR))
 
	Anyway here is my problem.  Many times things are located in
	directories other than the current directory in fact we keep all of
	the 'standard' makefiles in 1 directory namely ../makefiles from
	all of the source code.  When I have symlinks to RCS it seems to be
	able to pull everything out i.e. it notices that it doesn't have
	everything in the ../makefiles directory but that they are in RCS
	so it pulls them out for me (correctly).  But if I don't have the
	RCS symlink (and I can't always as I said above) I can not for the
	life of me figure out how to tell make to pull the code out.

	Please send email as I am not a current member of this list.

Frank P. Bresz  |PCD Simulators Department, Westinghouse Electric Corporation
fpb@ittc.wec.com|My opinions are mine, WEC pays big money for official opinions
uunet!ittc!fpb  |Member: League for Programming Freedom (LPF) | STOP Software |
+1 412 733 6749 |For more information on the 'LPF' send mail  |  Patents Now  |


Newsgroups: gnu.utils.bug
From: frew@postgres.berkeley.edu
Subject: bug in GNU find version 3.7 vs. ULTRIX CD-ROMs
Reply-To: Jim Frew <frew@postgres.berkeley.edu>
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 19:06:23 GMT

hardware: DECstation 5000/240
      OS: ULTRIX V4.2A

GNU find version 3.7 doesn't deal correctly with subdirectories on a
CD-ROM mounted as a "cdfs" filesystem.

Example:

	# mount -t cdfs -r /dev/cdrom /cdrom

	# /usr/bin/find /cdrom -type d -print	# ULTRIX
	/cdrom
	/cdrom/AVHRR
	/cdrom/AVHRR/IMAGES
	/cdrom/AVHRR/LABELS
	/cdrom/GEOM
	/cdrom/GEOM/IMAGES
	/cdrom/GEOM/LABELS
	/cdrom/MISC
	/cdrom/MISC/IMAGES
	/cdrom/MISC/LABELS
	/cdrom/NDVI
	/cdrom/NDVI/IMAGES
	/cdrom/NDVI/LABELS

	# find /cdrom -type d -print		# GNU
	/cdrom
	/cdrom/AVHRR
	/cdrom/GEOM
	/cdrom/MISC
	/cdrom/NDVI

	# /usr/bin/find /cdrom -type f -print	# ULTRIX
	/cdrom/AVHRR/IMAGES/P01CH1.DDR;1
	/cdrom/AVHRR/IMAGES/P01CH1.IMG;1
	/cdrom/AVHRR/IMAGES/P01CH2.DDR;1
	/cdrom/AVHRR/IMAGES/P01CH2.IMG;1
	/cdrom/AVHRR/IMAGES/P01CH3.DDR;1
	...
	/cdrom/NDVI/LABELS/P02NDVI.LBL;1
	/cdrom/NDVI/LABELS/P03NDVI.LBL;1
	/cdrom/NDVI/LABELS/P04NDVI.LBL;1
	/cdrom/NDVI/README.1ST;1
	/cdrom/README.1ST;1

	# gfind /cdrom -type f -print		# GNU
	/cdrom/README.1ST;1

#----------------------------+---------------------------+
# Jim Frew                   | University of California  |
# frew@postgres.berkeley.edu | Computer Science Division |
# (510) 642-0267             | 571 Evans Hall            |
# (510) 642-5615 (FAX)       | Berkeley, CA  94720       |
#----------------------------+---------------------------+

Newsgroups: gnu.utils.bug
From: jjc@jclark.COM (James Clark)
Subject: bison.simple should check __sparc as well as __sparc__
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 09:29:14 GMT

A parser generated by bison 1.18 won't compile with Lucid C++ on a
sparc.  The problem is that <alloca.h> does not get included because
Lucid defines __STDC__ and defines __sparc rather than __sparc__.
Here's a fix:

*** bison.simple.~1~	Sun Mar  8 06:22:19 1992
--- bison.simple	Mon Jul 27 10:11:23 1992
***************
*** 23,29 ****
  #ifdef __GNUC__
  #define alloca __builtin_alloca
  #else /* not GNU C.  */
! #if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__)
  #include <alloca.h>
  #else /* not sparc */
  #if defined (MSDOS) && !defined (__TURBOC__)
--- 23,29 ----
  #ifdef __GNUC__
  #define alloca __builtin_alloca
  #else /* not GNU C.  */
! #if (!defined (__STDC__) && defined (sparc)) || defined (__sparc__) || defined (__sparc)
  #include <alloca.h>
  #else /* not sparc */
  #if defined (MSDOS) && !defined (__TURBOC__)


James Clark
jjc@jclark.com

Newsgroups: gnu.utils.bug
From: frew@postgres.berkeley.edu
Subject: Re: GNU find version 3.7 vs. ULTRIX CD-ROMs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 16:14:07 GMT

> Date: Tue, 28 Jul 92 12:08:57 +0200
> From: x920031@rubb.rz.ruhr-uni-bochum.de (Jost Krieger)
> To: Jim Frew <frew@postgres.berkeley.edu>
> Subject: bug in GNU find version 3.7 vs. ULTRIX CD-ROMs
>
> CD-ROMS probably have a kind of MS-DOS-like filestructure. GNU find's
> optimization doesn't work (link counting).  You need to specify -noleaf in
> your find. (All this is pure conjecture.)
>
> Jost Krieger, Rechenzentrum der Ruhr-Universitaet Bochum
> x920031@rubb.rz.ruhr-uni-bochum.de
> g=Jost;s=Krieger;ou=ruba;ou=rz;pd=ruhr-uni-bochum;ad=dbp;c=de

That worked (I shoulda R'dTFM a little more diligently ...)  Thanks!

/Frew

#----------------------------+---------------------------+
# Jim Frew                   | University of California  |
# frew@postgres.berkeley.edu | Computer Science Division |
# (510) 642-0267             | 571 Evans Hall            |
# (510) 642-5615 (FAX)       | Berkeley, CA  94720       |
#----------------------------+---------------------------+

Newsgroups: gnu.utils.bug