HDTenEightyP/NetNews huggingface dataset:
From: eliot@dcs.qmw.ac.UK (Eliot Miranda;W211)
Newsgroups: gnu.utils.bug
Subject: Is there a COFF version of dld?
Summary: coff-compatible port of dld wanted
Keywords: dynamic linking dld coff
Date: 25 Aug 92 18:09:49 GMT
Distribution: gnu
Organization: Computer Science Dept, QMW, University of London


	I'm using Wildson Ho's excellent dld package to do dynamic linking
on SUNs.  I would also like to use dld on coff platforms.  Is anyone working
on a coff-compatible version?
--
Eliot Miranda			email:	eliot@dcs.qmw.ac.uk
Department of Computer Science	ARPA:	eliot%dcs.qmw.ac.uk@nsf.ac.uk
Queen Mary Westfield College	UUCP:	eliot@qmw-dcs.uucp
Mile End Road, LONDON E1 4NS	Tel:	071 975 5229 (+44 71 975 5229)
				Fax:	081 980 6533 (+44 81 980 6533)
Newsgroups: gnu.utils.bug
From: donn@carson.u.washington.edu (Donn Cave)
Subject: Re: more thoughts on fileutils
Organization: University of Washington
Distribution: gnu
Date: Thu, 3 Sep 1992 15:17:59 GMT

mib@gnu.ai.mit.edu (Michael I Bushnell) writes:

| Deciding what mv should do when the system call's semantics have
| changed is something that can be addressed on this list.  There will
| generally be two kinds of combination directory/files in the Hurd.
| The first is typified by transparent tar, in which the file is a tar
| archive and the directory is its contents.  The second is loosely
| called a "shadow", in which the directory is the union of some other
| directories, and the file is a description of the nature of this
| union.

| For the first, the directory semantics are incidental, and should not
| be relevant to the behavior of mv.  It was such a directory I had in
| mind when I said that "mv bar foo" and "mv bar foo/" should have
| different results.  For the second, the file semantics are incidental,
| and the directory rules should apply.  

I'm not following this - don't see why mv should care whether directory
semantics are "incidental".  When we go to the trouble of providing
directory semantics, it seems confusing to have them apply in some cases
and not in others.  It seems ironic that the example is called "transparent"
tar - perhaps "translucent" would be better, if the intent is to have it
look like a directory but require the user to know the difference.

	Donn Cave, University Computing Services, University of Washington
	donn@cac.washington.edu


Newsgroups: gnu.utils.bug
From: david@campfire.stl.mo.US (David J Camp)
Subject: more thoughts on fileutils
Reply-To: "David J Camp" <campfire!david@wupost.wustl.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 02:48:58 GMT

On 31 Aug 92 14:59:07, bug-gnu-utils-request@prep.ai.mit.edu wrote:
: In article <9208282057.AA12744@wookumz.gnu.ai.mit.edu>, mib@gnu.ai.mit.edu (Michael I Bushnell) writes:
: 
: > In GNU, nodes can be both directories and ordinary files.
: ...
: > Suppose "foo" is such a node.  In that case "mv bar foo" should
: > delete the existing foo (and the virtual hierarchy underneath it),
: > replacing it with bar.  "mv bar foo/" should move bar into the
: > directory foo, giving it the name foo/bar, and leaving the rest of
: > the virtual hierarchy under foo untouched.
: 
: This sounds really bad to me.  If foo is going to act like a
: directory, it should act like a directory, and one of the qualities of
: acting like a directory is that "mv bar foo" renames "bar" to
: "foo/bar".  If you do things any other way, then all sorts of typing
: idioms that people have are no longer going to work, shell scripts and
: programs are going to break, and so forth.

I suggest that mib write a distinct command called something other
than 'mv' that does what he wants it to do.  -David-

# david%campfire@wupost.wustl.edu    ^     David J. Camp                #
# wupost.wustl.edu!campfire!david  < * >   +1 314 382 0584              #
# campfire!david@wupost.wustl.edu    v     "God loves material things." #
#         I am a member of the League for Programming Freedom.          #

Newsgroups: gnu.utils.bug
From: leisner@eso.mc.xerox.COM (Marty Leisner 311/? x?)
Subject: shellutils 1.7
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Tue, 1 Sep 1992 15:04:41 GMT

I just got shellutils 1.7 up and running on a sparcstation (OS 4.1.1B, gcc 2.2.2)

There should be n easier way to get version information -- I tried 
grep shellutils /usr/local/bin/basename
and it dumped the symbol table to my screen.  At least, how about an RCS
keybword in each file so I can ident it?

Also, I just began to look texinfo documentation in Emacs.   I'm confused about whether
GNU wants man pages or texinfo docs (or both in some cases...)

I had problems making it...
for dir in lib src man; do echo making all in $dir; cd $dir; make bindir='/usr/gnu/bin' mandir='/us
r/gnu/man/man1' manext='1' binprefix='' manprefix='' LIBS='' AR='ar' RANLIB='ranlib' INSTALL_PROGRA
M='/usr/gnu/bin/install -c' INSTALL_DATA='/usr/gnu/bin/install -c -m 644' DEFS='-DHAVE_LIMITS_H=1 -
DHAVE_SYSLOG_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_FTIME=1 -DHAVE_UT_HOST=1 -DHAVE_C_LINE=1
 -DHAVE_VPRINTF=1 -DHAVE_ALLOCA_H=1 -DHAVE_TM_ZONE=1 -DDIRENT=1' CFLAGS='-g' LDFLAGS='-g' LIBS='' C
C='gcc -O' all; cd ..; done
making all in lib
make[1]: Entering directory `/a/rockwell/root/dk3g/gnu/src/shellutils-1.7/lib'
gcc -O -c -g  -DHAVE_LIMITS_H=1 -DHAVE_SYSLOG_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_FTIME=1
 -DHAVE_UT_HOST=1 -DHAVE_C_LINE=1 -DHAVE_VPRINTF=1 -DHAVE_ALLOCA_H=1 -DHAVE_TM_ZONE=1 -DDIRENT=1 -I
. strtoul.c
In file included from /usr/gnu/lib/gcc-lib/sun4/2.2.2/include/stdlib.h:10, from ./strtol.c:33, from
 strtoul.c:21:
/usr/include/sys/stdtypes.h:27: redefinition of `size_t'
/usr/gnu/lib/gcc-lib/sun4/2.2.2/include/stddef.h:82: `size_t' previously declared here
/usr/include/sys/stdtypes.h:28: redefinition of `ptrdiff_t'
/usr/gnu/lib/gcc-lib/sun4/2.2.2/include/stddef.h:45: `ptrdiff_t' previously declared here
/usr/include/sys/stdtypes.h:30: redefinition of `wchar_t'
/usr/gnu/lib/gcc-lib/sun4/2.2.2/include/stddef.h:120: `wchar_t' previously declared here
make[1]: *** [strtoul.o] Error 1
make[1]: Leaving directory `/a/rockwell/root/dk3g/gnu/src/shellutils

In lib/strtoul.c:

#include <strtol.c>

Shouldn't this be:

#include "strtol.c"

Fixing the above errors, I just took out
  #include <stdlib.h>
in strtol.c.  I didn't figure out a "righter" way.

Also GNU make has lots of nice features....what is the sense if noone 
uses them...
For example,, making rules like this cleaner:
clean:
        for dir in $(SUBDIRS); do echo making $@ in $$dir; cd $$dir; $(MAKE) $(MDEFINES) $@; cd ..;
 done


Marty    leisner.henr801c@xerox.com 
          Member of the League for Programming Freedom 
 	Give me source or waste my time..

Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: GNU fileutils v3.2.3 alter pathnames by removing trailing slashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 10:51:43 GMT

The solution is for readline completion to refrain from appending the
slash when complieting tto the name of a directory.  The next TAB
should put the slash in, and another TAB should complete names within
the directory (only succesful if there is only one file in the
directory).  

In other words, if I have directory foo and file foo/bar (and nothing
else in foo), the following happens:

type f o TAB
see `foo'
type TAB
see `foo/'
type TAB
see `foo/bar'

Alternatively, the second TAB could be unnecessary.  I don't think I
like that, however.

	-mib

Newsgroups: gnu.utils.bug
From: mattw@cssc-syd.tansu.COM.AU (Matthew Watson)
Subject: make 3.62 "bug"
Organization: Customised Software Solutions Centres, AOTC
Distribution: gnu
Date: Thu, 27 Aug 1992 13:00:48 GMT

I seem to have found a problem with GNU make 3.62. 

I am using the $(wildcard *.c ) function in initialisation of some variable at
the top of my make file, and in some commands. Also the $(wildcard *.h)
function is used in come commands.

Initially there are no *.c or *.h files in the current directory. Before
the commands are run, make is called  in some subdirectories and as a
result .c and .h files are copied into the current directory.

The command which uses the $(wildcard *.h) function works fine, getting
all the .h files, but the command which uses $(wildcard *.c ) thinks there
are no .c files present, which is not correct, but which was correct when
the variable was initialised up at the top.

I don't have the time to track down such a bug. Anyone else seen this sort
of thing?
-- 

-------------------------------------------------------------------------------
     -  Matthew Watson -  	   | MHSnet: mattw@cssc-syd.tansu.com.au
     Australian and Overseas	   |

Newsgroups: gnu.utils.bug
From: leisner@eso.mc.xerox.COM (Marty Leisner 311/? x?)
Subject: shellutils-1.7/su
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Tue, 1 Sep 1992 16:29:16 GMT

I'm not sure why a wheel group is considered fascist?  Perhaps define the behavior of su to:
	With a certain option, look for a user in the wheel group, and prompt for the logname
password.
This will let su look for a wheel group and user passwords, or just su normally...

This is an issue of whether to have passwords on computers...a modest level of security
is reasonable so people don't do stupid things (a little knowledge is very dangerous).
Of course, if you're malicious, security is just a nuisance...


"a

Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: more thoughts on fileutils
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 09:17:29 GMT

   In article <9208282057.AA12744@wookumz.gnu.ai.mit.edu>, mib@gnu.ai.mit.edu (Michael I Bushnell) writes:

   This sounds really bad to me.  If foo is going to act like a
   directory, it should act like a directory, and one of the qualities of
   acting like a directory is that "mv bar foo" renames "bar" to
   "foo/bar".  If you do things any other way, then all sorts of typing
   idioms that people have are no longer going to work, shell scripts and
   programs are going to break, and so forth.

It depends on one's model of the universe.  rename ("bar", "foo") is
*never* the same as rename ("bar", "foo/bar").  Take a look at the man
page for the system call, and you will see that (in Unix) if the
second argument to rename exists, and is a directory, then it must be
an empty directory and the first argument must be a directory.  In
the Hurd, these rules are dependent on the details of the filesystem.
The basic idea is to prevent single system calls from obliterating
entire directory trees.  

The mv shell program never issues rename system calls of this sort.
Instead, it interprets second arguments which are directories in a
peculiar fashion, which we all know and love.

Deciding what mv should do when the system call's semantics have
changed is something that can be addressed on this list.  There will
generally be two kinds of combination directory/files in the Hurd.
The first is typified by transparent tar, in which the file is a tar
archive and the directory is its contents.  The second is loosely
called a "shadow", in which the directory is the union of some other
directories, and the file is a description of the nature of this
union.

For the first, the directory semantics are incidental, and should not
be relevant to the behavior of mv.  It was such a directory I had in
mind when I said that "mv bar foo" and "mv bar foo/" should have
different results.  For the second, the file semantics are incidental,
and the directory rules should apply.  

	-mib

Newsgroups: gnu.utils.bug
From: metcalf@catfish.lcs.mit.edu (Chris Metcalf)
Subject: fileutils-3.3: hpux 6.5: small bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 05:17:02 GMT

In the current fileutils set on hpux 6.5, "lib/system.h" includes
<unistd.h>, which in turn includes <utime.h>.  When "lib/system.h"
later looks for a "utimbuf" declaration, it does it by hand, since
_POSIX_VERSION is not defined for hpux 6.5.  Unfortunately, the 
declarations clash, since <utime.h> uses time_t for the fields.

Chris Metcalf
MIT Lab Lab for Computer Science

*** 1.1	1992/09/02 12:19:06
--- fileutils-3.3/lib/system.h	1992/09/02 12:19:38
***************
*** 91,101 ****
--- 91,103 ----
  #ifdef _POSIX_VERSION
  #include <utime.h>
  #else /* not _POSIX_VERSION */
+ #ifndef _UTIME_INCLUDED
  struct utimbuf
  {
    long actime;
    long modtime;
  };
+ #endif /* ! _UTIME_INCLUDED */
  #endif /* _POSIX_VERSION */
  
  #if defined(USG) || defined(STDC_HEADERS)

Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: Re: `canned' command sequences no longer work in gmake-3.62
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Wed, 26 Aug 1992 07:15:10 GMT

Earlier today, I sent a bug report about `canned' command sequences
(defined with "define ... endef") not working with gmake-3.62.

I copied the code from gmake-3.60, into the appropriate place in
construct_command_line_internal() and everything works as before.

Patch follows:

*** ../make-3.62/job.c	Thu Oct 24 14:58:33 1991
--- job.c	Wed Aug 26 13:52:43 1992
***************
*** 586,593 ****
      /* Still executing the last line we started.  */
      recursive = child->file->cmds->lines_recurse[child->command_line - 1];

-   /* Find the end of this line.  Backslash-newlines don't mean the end.  */
-
    p = child->command_ptr;
    child->noerror = 0;
    while (*p != '\0')
--- 586,591 ----
***************
*** 1041,1046 ****
--- 1039,1045 ----
    register char *ap;
    char *end;
    int instring;
+   int backslash;
    char **new_argv = 0;

    /* See if it is safe to parse commands internally.  */
***************
*** 1165,1170 ****
--- 1164,1204 ----
        /* Free the old argument list we were working on.  */
        free (new_argv[0]);
        free (new_argv);
+     }
+
+   /* Find the end of this line.  Backslash-newlines don't mean the end. */
+   end = line;
+   while (*end != '\0')
+     {
+       p = index (end, '\n');
+       if (p == 0)
+ 	{
+ 	  end += strlen (end);
+ 	  break;
+ 	}
+
+       end = p;
+       backslash = 0;
+       while (*--p == '\\')
+ 	backslash = !backslash;
+
+       if (backslash)
+ 	{
+           ++end;
+           /* If there is a tab after a backslash-newline,
+              remove it, since it was most likely used to line
+              up the continued line with the previous one.  */
+           if (*end == '\t')
+             strcpy (end, end + 1);
+         }
+       else
+         break;
+     }
+
+   if (*end != '\0')
+     {
+       *end = '\0';
+       *restp = end;
      }

    if (shell == 0 || !strcmp (shell, default_shell))



Newsgroups: gnu.utils.bug
From: roten@cuba.gsfc.nasa.gov (Charles Roten)
Subject: Multivolume Gnu tar bogosity .. Heeeeeelp !!
Organization: /cuba_b/dirbe/roten/.organization
Distribution: gnu
Date: Tue, 1 Sep 1992 16:48:33 GMT

Gnu tar has a real problem when it 

1) creates a multivolume archive on 3 1/2" floppies on an Ultrix 
   workstation, and then

2) reads this archive on a Sun.  

When reading, 

    tar xvMf /dev/fd0c

reads the first floppy *perfectly*.  Then, as expected, I get the prompt 

    Prepare volume #2 and hit return  

But when I pop the second floppy in, I *always* get the error  

    tar: this volume is out of sequence  

This happens even with two-volume archives, where the floppy disk cases 
are different *colors*, so as to make the order *completely* unambiguous.  

Can someone tell me what is going on ?  Please ?!?  

--
Charles Roten | Hughes-STX, Incorporated | 
  roten@cuba.gsfc.nasa.gov               | 'Use the Source, Luke!'
  7601 Ora-Glen Dr., Greenbelt, MD 20706 | 
  301-513-7805 (w),  301-317-0872 (h)    |            Obi-Wan Stallman

Newsgroups: gnu.utils.bug
From: Bob_Sidebotham@transarc.com
Subject: dependency chaining bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 1 Sep 1992 09:25:09 GMT

There's a bug in the way that dependencies of the form -l<lib> work. In
the following makefile, "baz" and "bar" are made in a similar manner,
except that baz is made implicitly with a dependency list of "baz.o
-lfoo", while bar is made with a dependency list of "bar.o libfoo.a". If
the file "foo.h" is touched, the object file and library will not be
remade if you type "make baz", but will be remade if you type "make bar".

To try this out, put this makefile in a clean directory, and type
"make". It will create all the necessary files. Then type "make baz" and
"make bar". You should see the following results:

[make-bug] make -v
GNU Make version 3.62, by Richard Stallman and Roland McGrath.
Copyright (C) 1988-1991 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

echo "main() {}" > bar.c
cc    -c bar.c -o bar.o
echo "/* a library component */" > foo.c
echo "/* a header file */" > foo.h
cc    -c foo.c -o foo.o
ar rv libfoo.a foo.o
ar: creating an archive file libfoo.a
a - foo.o
cc -L.  bar.o libfoo.a   -o bar
echo "main() {}" > baz.c
cc    -c baz.c -o baz.o
cc -L.  baz.o -lfoo   -o baz
[make-bug] touch foo.h
[make-bug] make baz
make: `baz' is up to date.
[make-bug] make bar
cc    -c foo.c -o foo.o
ar rv libfoo.a foo.o
r - foo.o
cc -L.  bar.o libfoo.a   -o bar

Here's the makefile:

------------------CUT HERE-----------------
vpath		.
LDFLAGS=	-L.

all:		bar baz

foo.c:
		echo "/* a library component */" > foo.c

foo.h:
		echo "/* a header file */" > foo.h

bar.c:
		echo "main() {}" > bar.c

baz.c:
		echo "main() {}" > baz.c

foo.o:		foo.c foo.h

libfoo.a:	foo.o
		ar rv libfoo.a foo.o

bar:		bar.o libfoo.a

baz:		baz.o -lfoo

clean:
		$(RM) foo.c foo.h bar.c bar.o baz.c baz.o foo.o libfoo.a bar baz
--------------------END Makefile---------------

Thanks,

Bob Sidebotham bob@transarc.com
Transarc Corporation 412-338-4367



Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: using conditionals inside define/enddef with gmake
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Wed, 26 Aug 1992 07:43:54 GMT

It would be useful to be able to use conditionals for slight
variations needed between different architectures.  The following
patch allows you to do so.

*** ../make-3.62/read.c	Thu Oct 10 13:20:54 1991
--- read.c	Thu Jul 23 18:00:04 1992
***************
*** 73,80 ****

  static struct conditionals toplevel_conditionals;
  static struct conditionals *conditionals = &toplevel_conditionals;
-

  /* Default directories to search for include files in  */

  static char *default_include_directories[] =
--- 73,80 ----

  static struct conditionals toplevel_conditionals;
  static struct conditionals *conditionals = &toplevel_conditionals;

+
  /* Default directories to search for include files in  */

  static char *default_include_directories[] =
***************
*** 605,610 ****
--- 605,611 ----
    char *definition = (char *) xmalloc (100);
    register unsigned int idx = 0;
    register char *p;
+   int ignoring = 0;

    initbuffer (&lb);
    while (!feof (infile))
***************
*** 613,618 ****
--- 614,640 ----
        nlines = readline (&lb, infile, filename);
        p = next_token (lb.buffer);

+
+ #define	word1eq(s, l) 	((p[l] == '\0' || isblank (p[l])) && \
+ 			 !strncmp (s, p, l))
+
+       if (word1eq ("ifdef", 5) || word1eq ("ifndef", 6)
+ 	  || word1eq ("ifeq", 4) || word1eq ("ifneq", 5)
+ 	  || word1eq ("else", 4) || word1eq ("endif", 5))
+ 	{
+ 	  int i = conditional_line (p, filename, lineno);
+ 	  if (i >= 0)
+ 	    {
+ 	      ignoring = i;
+ 	      continue;
+ 	    }
+ 	  else
+ 	    makefile_fatal (filename, lineno,
+ 			    "invalid syntax in conditional");
+ 	}
+       if (ignoring)
+ 	continue;
+
        if ((p[5] == '\0' || isblank (p[5])) && !strncmp (p, "endef", 5))
  	{
  	  p += 5;
***************
*** 647,655 ****
  	  definition[idx++] = '\n';
  	}
      }

!   /* No `endef'!!  */
!   makefile_fatal (filename, lineno, "missing `endef', unterminated `define'");
    return 0;
  }
  
--- 669,681 ----
  	  definition[idx++] = '\n';
  	}
      }
+ #undef word1eq

!   /* No `endif' or `endef'  */
!   if (ignoring)
!     makefile_fatal (filename, lineno, "missing `endif'");
!   else
!     makefile_fatal (filename, lineno, "missing `endef', unterminated `define'");
    return 0;
  }
  
***************
*** 1005,1011 ****
  		d->name = savestring (buffer, o - buffer);
  	      }
  	  }
!
        if (!two_colon)
  	{
  	  /* Single-colon.  Combine these dependencies
--- 1031,1037 ----
  		d->name = savestring (buffer, o - buffer);
  	      }
  	  }
!
        if (!two_colon)
  	{
  	  /* Single-colon.  Combine these dependencies
***************
*** 1354,1360 ****
  	  else
  	    break;
  	}
!
        if (!backslash)
  	{
  	  p[-1] = '\0';
--- 1380,1386 ----
  	  else
  	    break;
  	}
!
        if (!backslash)
  	{
  	  p[-1] = '\0';
From: ramabs2@rpi.edu (Shiva Ramabadran)
Newsgroups: gnu.utils.bug
Subject: Re: GNU regex routines.(for xxgdb) on AIX
Date: 28 Aug 92 14:45:29 GMT
Followup-To: gnu.utils.bug
Distribution: gnu
Organization: Rensselaer Polytechnic Institute

In article <y-qyrwk@rpi.edu> I write:

 }
 } Has anyone been able to use these on an Rs/6000 ? 
 }
 } Has anyone got xxgdb working on an Rs/6000 ? 
 } 

Problem solved. The answer should be 'yes' to both questions. 

I found that the default definition for SIGN_EXTEND_CHAR would not
work for AIX. Redefining SIGN_EXTEND_CHAR for this special case did
the trick.


-Shiva
-=-
ITS Systems Programmer
Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Version 1.7 of the GNU shell programming utilities
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 1 Sep 1992 03:22:24 GMT

   While not (currently) a user of Gnu, I have to wonder why the
   programming utilities echo and xargs aren't in the same package as
   tee and test?

`echo' is a GNU bash builtin, but to my knowledge, does not exist yet
as a separate program.  For `xargs', it is provided withing GNU find
distribution.

If I remember correctly, xargs was added to the GNU find distribution
when options where added to find for working more securely with xargs.

-- 
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