HDTenEightyP/NetNews huggingface dataset:
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: more thoughts on fileutils
   
   (1) Dubious departure defusers (2) Periodical eggplant tensions (3)
   Anachronistic hydraulic treaties
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 07:30:51 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-

This is *not* about utilities, per se.  In GNU there will be nodes
which are both directories and files.  Don't presume otherwise.  This
will be true regardless of what sort of mv command you want to use.  

Most importantly, don't assume what people "want" in this environment,
because there are uses of this idea that you (and I) have never
considered.  Most important is to make everything *possible* and then
*convenient*.  The original brokenness of mv that started this
discussion, for example, removed the possibility of atomically
checking to see if something is a directory and completing the rename
if it is.  This is functionality that was *removed* from mv.  I'm
requesting, or perhaps demanding, that the functionality I'm building
in to the operating system be made available to users using ordinary
shell utilities.




Newsgroups: gnu.utils.bug
From: kirkwood%UTM301@utmc.utc.COM (Dan Kirkwood)
Subject: mistake in indent 1.6 info page
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 08:12:57 GMT

This might clear up a little bit of confusion....
Is this the correct way to send a correction??

Dan Kirkwood	United Technologies Microelectronics Center
		e-mail:	kirkwood@utmc.utc.com
                phone:	(719) 594-8156
		fax:	(719) 594-8032
-------------------------------------------------------------------------------


*** indent.texinfo      Wed Aug 26 10:11:21 1992
--- indent.texinfo~     Fri Jul  3 13:43:15 1992
***************
*** 909,915 ****

  @kindex -lps
  @kindex --leave-preprocessor-space
! ANSI C allows white space to be placed on preprocessor command lines
  between the character @samp{#} and the command name.  By default,
  @code{indent} removes this space, but specifying the @samp{-lps} option
  directs @code{indent} to leave this space unmodified.
--- 909,915 ----

  @kindex -lps
  @kindex --leave-preprocessor-space
! ASCII C allows white space to be placed on preprocessor command lines
  between the character @samp{#} and the command name.  By default,
  @code{indent} removes this space, but specifying the @samp{-lps} option
  directs @code{indent} to leave this space unmodified.

Newsgroups: gnu.utils.bug
From: metcalf@catfish.lcs.mit.edu (Chris Metcalf)
Subject: shellutils-1.7: hpux 6.5: configure bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 09:02:11 GMT

The configure in shellutils tries to figure out if tzname is defined by
#including <time.h> and declaring char **tzname.  Unfortunately, HPUX 6.5
declares char *tzname[], the definitions clash, the test compile fails
(under cc or gcc 2.2.2), and you don't get HAVE_TZNAME.  As a result,
the compilation of strftime either fails (for cc), or suceeds with a
warning for gcc.  The gcc-built "date" then dumps core whenever you
try to run it...  

I'm not sure what the best patch is, unfortunately; perhaps just testing
both char **tzname and char *tzname[] when checking HAVE_TZNAME.

I used:

diff -r1.1 configure
608c608
< #ifndef tzname /* For SGI.  */
---
> #if !defined(tzname) && !defined(hpux) /* For SGI (or hpux).  */

But this is probably a crock, since other hpuxen may define tzname
but not declare it in <time.h>.

Chris Metcalf
MIT LCS

Newsgroups: gnu.utils.bug
From: mikep@mailhost.adaclabs.COM (Mike Pechner)
Subject: What is the latest patch level?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 28 Aug 1992 23:22:38 GMT

I have 
	#define PATCHLEVEL "12u7"

Any later than this?

Newsgroups: gnu.utils.bug
From: gnu@toad.com
Subject: Re: Idea for tar
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 25 Aug 1992 12:14:04 GMT

Hugh Daniel <hugh@toad.com> suggested:
>   I have had the problem that I sometimes type "tar -zcf foo.tar.Z"
> insted of "tar -zxf foo.tar.Z".  With gnutar this puts the current
> directory tree in the file, thus trashing my file.
>   This seems like a new behavior to me, I would much prefer it that if
> I don't give any files to put in the archine if does *NOTHING*.
>   Is there a reason why this could not be done?
> 		||ugh

This *is* a new behaviour (assuming "." if no files are specified).
I think it is a mistake.

The old tar program would create an empty archive (with just an EOF
record in it), if you asked it to create an archive with no files
specified.

I believe that that is the proper thing to do.  Utilities should not
do surprising things in edge-cases.  A program that is asked to archive
two files, one file, or zero files, should act basically the same.
There should be no `singularity' around the zero point.

This would still not solve Hugh's problem, since it would wipe out his
file and replace it with an empty file, rather than replacing it with
the contents of his current directory.  All I can recommend there is
to make your tar archives read-only ("take out the write ring") to avoid
disasters.

(It should be easy for Hugh to put a shell script "tar" on his path,
that checks for this case and produces an error instead of running the
real "tar".)

	John Gilmore

Newsgroups: gnu.utils.bug
From: flynn@nematic.kent.edu (Mark Flynn)
Subject: tar 1.10 documentation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 1 Sep 1992 16:55:46 GMT

I have just installed gnutar and it works great. This is what they have at
wuarchive.wustl.edu, so I guess it's pretty up to date. Anyways, I have
two questions (not bugs: sorry)

1) Is the new doc close to being done?

2) I know that I'm not supposed to send bug reports about the old documentation,
but I would really like to have something. And the first line in tar.texinfo
is:

\input texinfo ....

This presumably defines various macros, but wasn't included with the
distribution. Is this avialable?

Thanks.

Mark Flynn
Liquid Crystal Institute
Kent State University
flynn@nematic.kent.edu


Newsgroups: gnu.utils.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Indent 1.6 ported to MacOS with THINK_C
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 20:08:17 GMT

Please don't develop software for the Macintosh.  Apple has attacked
the freedom of all programmers, with some success in the EC (which
Switzerland would like to join), and they may yet succeed in the US.
Developing software for Apple machines promotes sales of Apple
machines, which rewards Apple for hurting you and the rest of us.

Programmers who care about their freedom are trying to defend it by
(among other things) boycotting Apple.  The FSF participates in this
boycott, so it doesn't support Macintosh systems in any way.  (Thus,
we won't install or distribute changes to make indent work on the
Macintosh.)  I hope you will take the long view and do likewise.

For more information, contact the League for Programming Freedom
at league@prep.ai.mit.edu.
From: karl@claude.cs.umb.edu (Karl Berry)
Newsgroups: gnu.utils.bug
Subject: altering pathnames
Date: 28 Aug 92 04:13:18 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I don't understand the argument that we don't know what
/ means to the kernel.  / means what we all know it means.

I don't think it's fruitful for the GNU file utilities
to worry about running under non-Unix-like operating systems.
Or is this not what you're thinking about?

Thomas, you seem to be worried about some abstract principle.
I agree with the principle (in principle); in practice,
I want the programs to work in the most convenient way,
i.e., completion appending a / automatically, and
the fileutils stripping off the / automatically.

Is there a practical problem that my suggested solution
(of only stripping the / when the path is a directory)
does not solve?

karl@cs.umb.edu
Newsgroups: gnu.utils.bug
From: hxl@chopin.UUCP (Charlie Xiaoli Huang)
Subject: following up on indent 1.6 (forced newline in typedef)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 18:23:02 GMT

Following up on my previous message on a forced newline 
at end of typedef, I'm convinced it is a bug. The reason
is inconsistent behavior as follows:

	original:

	typedef struct foo {
	int bar;
	} foo_t;

will become

	typedef struct foo {
		int bar;
	} 
	foo_t;

whereas 

	original

	typedef struct foo {
	int bar;
	struct fubar x;
	} foo_t;

will become

	typedef struct foo {
		iunt bar;
		struct fubar x;
	} foo_t;

As you can see, the inserted newline before type name "foo_t"
is insterted if the last member of the struct is NOT a struct.

I've attempted to track down where in indent.c the decision 
was made to set the force_nl var in this case, and made the 
fix as follows:

*** indent.c    Thu Sep  3 11:02:27 1992
--- indent.c.orig       Wed Aug 19 15:32:29 1992
***************
*** 997,1006 ****
          prefix_blankline_requested = 0;
          parse (rbrace);       /* let parser know about this */
          if ((parser_state_tos->last_rw != rw_struct_like
-              && parser_state_tos->last_rw != rw_decl  /* hxl@epic.com added
-                                                          so that things like
-                                                          typedef struct won't have 
-                                                          a forced newline */
               && (parser_state_tos->p_stack[parser_state_tos->tos] == stmtl
                  || (parser_state_tos->p_stack[parser_state_tos->tos]
                      == ifhead)))
--- 997,1002 ----

It seems to work all right FOR MY CODE. 

Please let me know what you think.

Thanks,

hxl

Newsgroups: gnu.utils.bug
From: marc@cam.org (Marc Boucher)
Subject: utmp file name in shellutils-1.7 who
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 18:14:21 GMT

Hello;

On recent BSD releases, the utmp file's name is defined in <utmp.h> as
_PATH_UTMP, not UTMP_FILE. This breaks shellutils-1.7/src/who.c which assumes
"/etc/utmp" (incorrect, now "/var/run/utmp" without compatiblity symlink on
386BSD at least) if the latter isn't defined.

The following context diff implements the right thing.

thanks.
-- 
^@-------~~--**----/ --- - Marc Boucher
marc@CAM.ORG \----?	":
/-----_--  -    ----_|| +1 514 466 8932 - &-


*** /tmp/,RCSt1001025	Sat Aug 29 11:02:06 1992
--- who.c	Sat Aug 29 11:00:22 1992
***************
*** 43,49 ****
--- 43,53 ----
  #include "system.h"
  
  #ifndef UTMP_FILE
+ #ifdef _PATH_UTMP
+ #define UTMP_FILE _PATH_UTMP
+ #else
  #define UTMP_FILE "/etc/utmp"
+ #endif
  #endif
  
  #ifndef MAXHOSTNAMELEN

Newsgroups: gnu.utils.bug
From: friedman@gnu.ai.mit.edu (Noah Friedman)
Subject: Re:  shellutils-1.7/su
Reply-To: friedman@gnu.ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 05:48:24 GMT

I consider group wheel a nuisance.  Until unix systems no longer have an
8-group limit before things start breaking, the last thing I need is yet
another gratuitous group to be in.  It's a scarce resource.

However, the feature for su you describe is exactly what some hosts in the
Laboratory for Computer Science at MIT have, and it works pretty well.  To
clarify, su should still let anyone su if they know the canonical root
password---being in group wheel should just be a convenience which means
you can use your own password and not have to remember two separate ones.

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

Newsgroups: gnu.utils.bug
From: cyrus@convex.com (Tait Cyrus)
Subject: shellutils-1.6: date bug with unknown FORMAT
Organization: Engineering, CONVEX Computer Corp., Colorado Springs, CO., USA
Distribution: gnu
Date: Wed, 26 Aug 1992 15:26:56 GMT

shellutils-1.6/src/date.c has a bug in that if you pass an invalid format to
it, like "date +%O", then date will go into an infinite loop allocating memory
forever.  Below is a possible fix.  Another fix would be to limit the max
size of 'out' in routine 'show_date' to some "reasonable" value, say like 10k
and if the limit was reached, assume an invalid format.

*** date.c.ORG	Wed Aug 26 09:22:38 1992
--- date.c	Wed Aug 26 09:23:54 1992
***************
*** 175,180 ****
--- 175,181 ----
        printf ("%20.20s", asctime (tm));
        format = "%Z %Y";
      }
+   if( check_format( format, tm ) ) return;
    do
      {
        out_length += 200;
***************
*** 183,188 ****
--- 184,216 ----
    while (strftime (out, out_length, format, tm) == 0);
    printf ("%s\n", out);
    free (out);
+ }
+ 
+ /*
+  * Validate each part of the format.  Assume that no single part will produce
+  * more than TMP_BUF_SIZE characters of output.
+  */
+ #define TMP_BUF_SIZE 100
+ 
+ check_format( format, tm )
+   char *format;
+   struct tm *tm;
+ {
+   char buf[TMP_BUF_SIZE];
+   char op[3];
+ 
+   while( *format ) {
+     op[0] = *format++;
+     if( *format ) op[1] = *format++;
+     else op[1] = 0;
+     op[2] = 0;
+     if( strftime( buf, TMP_BUF_SIZE, op, tm ) == 0 )
+       {
+       printf("Unknown option '%s'\n", op );
+       return(1);
+       }
+     }
+   return(0);
  }
  
  void
-- 
W. Tait Cyrus                   Software Engineer
Convex Computer Corporation     cyrus@convex.com
2075 Research Parkway Suite B   719-594-4900 ext 41
Colorado Springs, CO 80920

Newsgroups: gnu.utils.bug
From: golbone@milton.u.washington.edu (Sima Hashemifar)
Subject: help with gld configure
Organization: University of Washington, Seattle
Distribution: gnu
Date: Sun, 30 Aug 1992 07:34:39 GMT

Hi netters,
I need help with gld. I have configured bfd and necessary friends in
binutils-1.94.beta. The build went without a hitch but it does not work(yet).
I would like to use my cough libraries without conversion, but I also would
like to use gas unmodified, i.e. have gas generate 'a.out' format as usual
but have ld combine a.out and cough objects to create the runnable image.
I used "configure -gas i386v -target i386-coff-sysv"
	when I configured the build.
Whereas all the utilities in binutils subdirectory could work with the
two formats of interest, ld refuses to recognise gas output files.
		Help! What am I doing wrong?
Now that I have your attention, If it is worth the effort,
how do I tell configure to remove all non-intel targets from the build?
I am asking because one of the bin utils identified a gas(a386)
generated object file as a vax binary, funny.
Thank you.

NB:
I do not want to use robotussin because i plan to build gnu equivalence of
the system libraries, replacing the system libraries with better ones as I 
go along, for instance: replace malloc with gmalloc, stdio with sfio etc.
I do not think it is worth the effort, especially since gcc generates
good assmbler files for the system as, which in turn generates good cough
for the system liker and all is happy.
Any rumors regarding HURD?


Newsgroups: gnu.utils.bug
From: mkc@centerline.com
Subject: bug in gnu-make
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 19:54:04 GMT

Gnu make version make-3.62.

On HP700s (untested on other machines)

When I tried to invoke gmake with a Makefile that has a rule of the
form:

> target: $(SOME_MAKE_VARIABLE)

For some reason this triggers a call to glob() with the pattern
parameter "/".  When glob is called with this pattern, an
infinite loop results as glob calls itself with the same pattern.

The parsing of pattern into filename and dirname results in
filename = "", and dirname = "/", and then this code is reached:

>  if (filename[0] == '\0')
>    /* "pattern/".  Expand "pattern", appending slashes.  */
>    return glob(dirname, flags | GLOB_MARK, errfunc, pglob);


I believe changing this to be:

>  if (filename[0] == '\0' && strcmp(dirname, "/"))

fixes the problem.

It seems that glob/glob.c is shared with other Gnu programs.


Mark Culotta

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

        Mark Culotta                  |       mkc@centerline.com or
        Software Engineer             |       uunet!centerline!mkc
        CenterLine Software Inc.      |
        10 Fawcett St.                |       (617) 498-3311 (voice)
        Cambridge, MA 02138-1110      |       (617) 868-6655 (FAX)

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


Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: Re:  GNU fileutils v3.2.3 alter pathnames by removing trailing slashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 02:47:15 GMT

Mike, I must disagree about not having completion append
/'s where possible.  That just means *I* to type the /.
(Or another tab, almost as bad.)

If you actually like to type the second TAB to get a /,
then that's fine, it could be some user option.  But I don't
think it's right for either of us to force our personal
typing styles on the other.

By the way, more programs than bash complete -- there are 
all the zillion completion packages running around
for Emacs.

I still don't see the problem with having mv etc. simply
check if the purported directory with the trailing slash
actually *is* a directory before it removes it.  It seems
to me that makes the original poster happy, because he gets
error messages when he erroneously types
mv foo bar/
where bar is not a directory; it makes me happy, because the
slashes that the completion functions continue to work
properly with the GNU file utilities; and it requires no
new options, environment variables, or other such things.

karl@cs.umb.edu

Newsgroups: gnu.utils.bug
From: steve@unidata.ucar.edu (Steve Emmerson)
Subject: autoconf 1.1: bug defining `const' to empty string
Organization: UCAR/Unidata
Distribution: gnu
Date: Thu, 3 Sep 1992 04:02:38 GMT

Greetings,

PROBLEM STATEMENT:

    autoconf version 1.1 does not correctly define the keyword `const' to
    be the empty string in environments that do not support `const'.

REPEAT BY:

    The following was executed on a DECstaton 3100 running ULTRIX 4.2:

	% cat configure.in
	AC_INIT(configure.in)
	AC_CONFIG_HEADER(config.h)
	AC_CONST
	AC_OUTPUT(Makefile)
	% cat config.h.in
	#undef const
	#define const const
	% autoconf --version
	Autoconf version 1.1
	% CC=cc ./configure
	checking for working const
	creating config.status
	creating Makefile
	creating config.h
	% cat config.h
	/* config.h.  Generated automatically by configure.  */
	#undef const
	#define const const
	%

    In the specified environment, the last two lines in file `config.h'
    should have been

	# define const
	# define const

    That this is so can be seen from the relevant lines in file
    `config.status':

	% sed -n 15,16p config.status
	DEFS='#define const 
	'
	%

POSSIBLE FIX:

    Apply the following patch to file `acgeneral.m4':

	% diff -c acgeneral.m4.dist acgeneral.m4
	*** acgeneral.m4.dist   Sun Aug 23 19:15:02 1992
	--- acgeneral.m4        Thu Sep  3 09:00:51 1992
	***************
	*** 476,492 ****
	  BEGIN { filenum = 1 }
	  filenum == 1 && <<$>>1 == "#define" \
	  { defs[<<$>>2] = <<$>>3
	    for (i = 4; i <= NF; i++)
	      defs[<<$>>2] = defs[<<$>>2] " " <<$>>i
	  }
	  /END_OF_DEFS/ { filenum = 2; next }
	  filenum == 2 && <<$>>1 == "#define" && \
	! defs[<<$>>2] != "" {
	    <<$>>3 = defs[<<$>>2]
	    print; next
	  }
	  filenum == 2 && <<$>>1 == "#undef" && \
	! defs[<<$>>2] != "" {
	    <<$>>1 = "#define"
	    <<$>>2 = <<$>>2 " " defs[<<$>>2]
	    print; next
	--- 476,493 ----
	  BEGIN { filenum = 1 }
	  filenum == 1 && <<$>>1 == "#define" \
	  { defs[<<$>>2] = <<$>>3
	+   hasdef[<<$>>2] = 1
	    for (i = 4; i <= NF; i++)
	      defs[<<$>>2] = defs[<<$>>2] " " <<$>>i
	  }
	  /END_OF_DEFS/ { filenum = 2; next }
	  filenum == 2 && <<$>>1 == "#define" && \
	! hasdef[<<$>>2] == 1 {
	    <<$>>3 = defs[<<$>>2]
	    print; next
	  }
	  filenum == 2 && <<$>>1 == "#undef" && \
	! hasdef[<<$>>2] == 1 {
	    <<$>>1 = "#define"
	    <<$>>2 = <<$>>2 " " defs[<<$>>2]
	    print; next

Regards,
Steve Emmerson   <steve@unidata.ucar.edu>

Newsgroups: gnu.utils.bug
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: Re: GNU fileutils v3.2.3 alter pathnames by removing trailing slashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 21:49:28 GMT

|I still don't see the problem with having mv etc. simply
|check if the purported directory with the trailing slash
|actually *is* a directory before it removes it. It seems
|to me that makes the original poster happy, because he gets
|error messages when he erroneously types
|mv foo bar/
|where bar is not a directory; it makes me happy, because the
|slashes that the completion functions continue to work
|properly with the GNU file utilities; and it requires no
|new options, environment variables, or other such things.

It's the principle that's wrong. I don't expect file utilities to go
around munging path names.

You don't know what those "/" (or paths) might mean to the kernel, to a
remote or user-defined file system, or to the user, so I think it just 
isn't safe to remove them.

If you do want to have this option, I think it should be an option
that users should have to configure explicitly, e.g., by setting
the environment variable "GNU_MUNGE_PATHNAMES"; I suspect that
all that would be required would the the addition of

{char *s; if(!((s=getenv("GNU_MUNGE_PATHNAMES"))&&atoi(s))) return;}

in one or two strategic places.

					Thomas.

Newsgroups: gnu.utils.bug
From: schrod@iti.INformatik.TH-darmstadt.DE (Joachim Schrod)
Subject: Re: GNU regex routines.(for xxgdb) on AIX
Organization: TU Darmstadt
Distribution: gnu
Date: Fri, 28 Aug 1992 14:52:42 GMT

In article <y-qyrwk@rpi.edu>, ramabs2@rpi.edu (Shiva Ramabadran) writes:
> 
> 	I'm running into problems using them on an Rs/6000 running
> AIX 3.1  (or 3.2 for that matter.) Specifically, I'm trying to 
> compile xxgdb on an rs/6000 and running into problems with Regexp 
> parsing using these routines. 
> 
> 	It SEGV's attempting recognize the most simple of regexp's 
> like  '[ ]*'. 

Have you applied the patch Torsten Ohl posted a few months ago?

Basically, the regexp package do not work when alloca() is used to
get the space for the nodes. Then storage is accessed (with a read
operation) which is never allocated; that can cause a SEGV like in
your case. There is a #define at the very top to discard the usage of
alloca(), use this.

Oh yes, a good tool for analyzing such errors is the debugging malloc
library (posted in c.s.r and available from all good archives).

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany

Newsgroups: gnu.utils.bug