HDTenEightyP/NetNews huggingface dataset:
From: leisner@trianguli.wrc.xerox.COM (Marty Leisner 311/? x?)
Subject: backup in cp, mv
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Wed, 12 Aug 1992 20:19:18 GMT

I really don't understand the GNU cp/mv backup strategy...

I ran mv with the -b option and saw no difference...

Can someone fill me in on how to get it to work...(I'd rather not read the source).

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

Newsgroups: gnu.utils.bug
From: cproto@marsh.cs.curtin.edu.au (Computer Protocol)
Subject: version control with RCS or CVS
Summary: version control with RCS or CVS
Keywords: RCS CVS
Organization: Curtin University of Technology
Distribution: gnu
Date: Wed, 12 Aug 1992 12:06:16 GMT

I'm trying to use RCS or CVS to keep track of changes made to 386bsd.
My problem is the amount of diskspace wasted. Using NSE under SunOS I
don't have the same problem. All source files of a project are under
NSE control but are mapped into a work area using the translucent
file system. This gives read access to all files associated with that
particular project so that you can do a make or browse through files.
Once you check out a file a writeable copy is created in your work
environment. This means that only during the time a file is checked
out you require additional diskspace. Once you checked a changed file
back in it becomes read only (mapped via the translucent file system),
the space for the copy is freed but you still can do a make on it or 
browse through it without having to check the file out.

The question is - can I achieve the same thing with RCS or CVS.
Otherwise is there a public domain version of the TFS ?

Regards - Tibor Sashegyi (cproto@abel.cs.curtin.edu.au)


Newsgroups: gnu.utils.bug
From: rha@hoqub.ATt.COM
Subject: Bug in fileutils-3.3 cp
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 15:25:00 GMT

cp -P seems to fail when the destination directory names have certain lengths.
The filename length of the file being copied doesn't seem to have any effect.
However, the length of the destination directory that fails is increased by
one if the file is given as a relative path. 

The following examples will fail.  You need to be root and in the root
directory. The destination directories must exist.  You should also be able
to create your own test cases such that you don't require root privileges.

I have not checked if destination directory lengths > 12 characters can cause
errors.

/bin/cp -P /usr/bin/clear /aa			/* 3 chars */
/bin/cp -P /usr/bin/clear aaa			/* 3 chars */
/bin/cp -P usr/bin/clear  aaa1			/* 4 = 3+1 for relative path */
/bin/cp -P usr/bin/clear  /aaa			/* 4 chars */
/bin/cp -P /usr/bin/clear bbbbbbb		/* 7 chars */
/bin/cp -P usr/bin/clear  bbbbbbb1		/* 8 chars */
/bin/cp -P /usr/bin/clear ccccccccccc		/* 11 chars */
/bin/cp -P usr/bin/clear  ccccccccccc1		/* 12 chars */
/bin/cp -P /usr/bin/clear aaa/bbbbbbb		/* 11 chars */
/bin/cp -P usr/bin/clear  aaa/bbbbbbb1		/* 12 chars */ 

This is the output of the 2nd and 3rd examples:

/bin/cp: cannot create regular file `aaa//usr/bin/clear': No such file or directory
/bin/cp: cannot create regular file `aaa1/usr/bin/clear': No such file or directory

Richard Almquist
rha@cbnewsi.att.com

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: linebuffer.[hc] specification
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 14:52:48 GMT

I most probably took GNU linebuffer.[hc] from the /lib directory of
some GNU *util distribution, but I do not remember which.  Hopefully,
there is a master copy somewhere for the GNU staff.

Both initbuffer() and freebuffer() receive, for their argument, an
already allocated `struct linebuffer'.  freebuffer() frees it.  So,
despite perfectly legal to pass a statically allocated variable to
initbuffer(), it is not legal to do so for freebuffer().  I feel it
would be more consistent if initbuffer() and freebuffer() could always
be used in pair.  One approach could be that freebuffer() does not
free its argument.  Another could be that initbuffer() has no argument
and returns a freshly allocated `struct linebuffer' structure.

-- 
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: pinard@icule.UUCP (Francois Pinard)
Subject: less bug - international characters not standing out
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 21:42:17 GMT

In less, sequences like `character-backspace-character' should be
displayed standing out, whenever both characters are the same.
However, if `character' has a value greater than 127, the character is
not standing out on the display, even if all its surrounding is.
After recompiling less with -funsigned-char, everything goes fine.
So, this bug is related to some unexpected character sign extension.

For reference, this is less-177.tar.Z, as fetched on prep.ai.mit.edu
on 91-04-19, and installed on a 386/ix 2.0.2 system, using GNU C 1.40
under coff-encapsulation.

-- 
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: roten@cuba.gsfc.nasa.gov (Charles Roten)
Subject: No texinfo.tex with gnu tar 1.10 !!
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 13:37:24 GMT

The 'Subject' line says all, except the fact that the texinfo.tex with the 
most recent texinfo package does not work with tar.texinfo when TeX is 
used to try to make a dvi file.   

Without a working texinfo.tex, its a little hard to make a hardcopy of the 
manual for gnu tar!  

Charles Roten | Hughes-STX, Inc. | net:   roten@cuba.gsfc.nasa.gov
                                   phone: 301-513-7805 (w),  301-317-0872 (h) 

Newsgroups: gnu.utils.bug
From: djm@eng.umd.edu (David J. MacKenzie)
Subject: Re: GNU fileutils v3.2.3 alter pathnames by removing trailing slashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 17:55:32 GMT

> The file utilities (cp, mv, etc) eliminate some errors by always removing
> trailing slashes from file names.

> My guess is that somebody tried using the GNU fileutils under "bash"
> with filename completion, and had some minor problem because bash
> inserts a / at the end of a path if the last part of the name is a
> directory.

As you guessed, the behavior is intentional.  The problem is that the
Unix rename system call -- and maybe others, I don't remember anymore
-- returns an "Invalid argument" error if an argument ends in "/",
presumably because that really means "/.", which you're not allowed to
rename.

Not just bash -- filename completion in tcsh, ksh, bash, and zsh adds
a "/" after directory names.  I and many others use filename
completion quite often and it got to be very annoying to have to
remember to constantly back up and delete the slashes.

So I made mv ignore slashes; then I made the other utilities do so
also, for consistency (and because the output, for example of du, or
cp, mv, or ln -v, looks nicer without the excess slashes).  I've never
encountered problems from the slightly reduced error checking.  Maybe
I don't make the right kind of typos.

>  (Some part of the fileutils probably assumed that there
> would be no trailing slashes in names.)
> The Unix kernel properly handles names containing multiple leading,
> internal, and trailing slashes.

As noted above, this is not quite the case, at least in the DWIM sense.

> The fix is not indiscriminate bashing of trailing slashes, as
> currently implemented.  The fix is to remove the generic truncation of
> trailing slashes, then to fix whatever minor bugs prevent the use of
> pathnames containing trailing slashes.

Fix everyone's shells, or everyone's kernels?  I don't offhand see a
better solution than what the GNU utilities currently do.  But
specific suggestions are welcome.

Newsgroups: gnu.utils.bug
From: iigsa01@convex.zdv.uni-tuebingen.de (Andreas Schilling)
Subject: indent -sob
Organization: Comp. Center (ZDV) U of Tuebingen, FRG
Distribution: gnu
Date: Thu, 13 Aug 1992 14:44:27 GMT

indent -sob doesn't seem to work; or maybe I don't know, what is
an optional blank line? No blank lines are removed from the source
file.

A.S.
--
|            Andreas  Schilling            |     Universitaet Tuebingen     |
| andreas@gris.informatik.uni-tuebingen.de |   Wilhelm-Schickard-Institut   |
|          tel.: +49 7071 29 5463          |   Auf der Morgenstelle 10/C9   |
|          fax.: +49 7071 29 5400          | D-7400 Tuebingen, West Germany |

Newsgroups: gnu.utils.bug
From: johnm@ksr.COM (John Martin)
Subject: Bug in make -t
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 16:03:57 GMT

GNU make 3.62 has a discrepancy between the documentation and the
action of the -t switch.  The info file says:

   The `-n', `-t', and `-q' options do not affect command lines that
begin with `+' characters or contain the strings `$(MAKE)' or
`${MAKE}'.  Note that only the line containing the `+' character or
the strings `$(MAKE)' or `${MAKE}' is run regardless of these options.
 Other lines in the same rule are not run unless they too begin with
`+' or contain `$(MAKE)' or `${MAKE}'.

But what make did was to execute the entire rule if any of its lines
sets the recursive flag.  E.g.:

	% gnumake -rtf -
	all:
	        rm -rf all
	        $(MAKE) -$(MAKEFLAGS) foo
	rm -rf all
	gnumake -rt foo
	gnumake[1]: *** No way to make target `foo'.  Stop.
	gnumake: *** [all] Error 1

According to the documentation, the rm command should not have been
executed.

The patches I made to get the behavior to match the documentation,
which seems preferable to documenting the current actual behavior,
are:

In remake.c:

*** 758,765 ****
      {
        chop_commands (file->cmds);
  
!       if (touch_flag && !file->cmds->any_recurse)
        {
          if (file->phony)
            file->update_status = 0;
          else
--- 758,767 ----
      {
        chop_commands (file->cmds);
  
!       if (touch_flag)
        {
+         if (file->cmds->any_recurse)
+           execute_file_commands( file);
          if (file->phony)
            file->update_status = 0;
          else

In job.c:

*** 631,637 ****
  
    /* Print out the command.  */
  
!   if (just_print_flag || (!noprint && !silent_flag))
      puts (p);
  
    if (argv == 0)
--- 631,637 ----
  
    /* Print out the command.  */
  
!   if (just_print_flag || (!noprint && !silent_flag && !(touch_flag && !recursive)))
      puts (p);
  
    if (argv == 0)
***************
*** 643,649 ****
  
    /* If -n was given, recurse to get the next line in the sequence.  */
  
!   if (just_print_flag && !recursive)
      {
        free (argv[0]);
        free ((char *) argv);
--- 643,649 ----
  
    /* If -n was given, recurse to get the next line in the sequence.  */
  
!   if ((just_print_flag || touch_flag) && !recursive)
      {
        free (argv[0]);
        free ((char *) argv);


---
John H. Martin, johnm@ksr.com, ksr!johnm@uunet.uu.net  <The Usual Disclaimer>
    The most wonderful things are brought about in many instances by
  means the most absurd and ridiculous, in the most ridiculous modes, 
  and apparently by the most contemptible instruments. -- Edmund Burke


Newsgroups: gnu.utils.bug
From: asmith@synoptics.com (Andrew Smith)
Subject: gld 1.97 (beta) BFD linker
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 18:19:51 GMT

Someone sent me this in reply to a request for info about GNU ld 1.97 - does 
anyone else know where I can find this source? What is the "archie" database?


> I wish I had saved that message - I'll forward this one on to
> gnu@prep.ai.mit.edu, who steered me to it in the first place. I
> think there's a posting of it in the archie (?) database.


Andrew Smith
Distributed Network Systems 
SynOptics Communications Inc.

Newsgroups: gnu.utils.bug
From: peter@robots.ox.ac.uk
Subject: Bug in shellutils-1.6/printf
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 20:53:26 GMT

Here is the bug report:

bash$ printf \07
HOME=/users3/peterbash$		# beeps then prints first env variable in envp
bash$ printf \07cello		# beeps then no output, treats c as \c

Thanks,
	Pete.

Sorry if it's already been fixed, but here's my patch:

---------8<---------------------8<-----------------------

*** printf.c.orig	Wed Aug 12 21:04:16 1992
--- printf.c	Wed Aug 12 21:37:56 1992
***************
*** 197,202 ****
--- 197,203 ----
        if (esc_length == 0)
  	error (1, 0, "missing hexadecimal number in escape");
        putchar (esc_value);
+       --p;
      }
    else if (*p == '0')
      {
***************
*** 205,214 ****
  	   ++esc_length, ++p)
  	esc_value = esc_value * 8 + octtobin (*p);
        putchar (esc_value);
      }
!   else if (!index ("\"\\abcfnrtv", *p))
!     error (1, 0, "\\%c: invalid escape", *p);
!   print_esc_char (*p);
    return p - escstart;
  }
  
--- 206,219 ----
  	   ++esc_length, ++p)
  	esc_value = esc_value * 8 + octtobin (*p);
        putchar (esc_value);
+       --p;
      }
!   else if (index ("\"\\abcfnrtv", *p))
!       print_esc_char (*p);
!   else
!       error (1, 0, "\\%c: invalid escape", *p);
! 
!   /* return position of end of esc-sequence relative to start */
    return p - escstart;
  }
  

Newsgroups: gnu.utils.bug
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: Re: Autoconf and duplicated function tests
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 08:18:07 GMT

> 	#ifdef USG
> 	#include <string.h>
> 	#else
> 	#include <strings.h>
> 	#endif
> 	#ifndef HAVE_STRSTR
> 	const char *strstr ();
> 	#endif
> 
> If the system already offers strstr, <string.h> or <strings.h> will
> declare it, and my own definition will fatally conflict.

That is only because your declaration is wrong.  The correct declaration,
"char *strstr ();" should not conflict with a correct prototype in
<string.h>.

Newsgroups: gnu.utils.bug
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: serious bug in mv (and possibly other utilities)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 15:28:04 GMT

GNU "mv" (binutils-beta-1.94) fails to interpret trailing slashes
correctly.  It has been a long-standing convention that a trailing
slash in a filename indicates that the filename refers to a directory.
This makes certain idioms much safer.  For example:

arolla$ > 1
arolla$ > 2
arolla$ /bin/mv 1 2/
mv: 1: rename: Not a directory
arolla$ 

Unlike SunOS "mv", GNU "mv" simply destroys file "2" despite the
trailing slash:

arolla$ > 1
arolla$ > 2
arolla$ mv 1 2/
arolla$ ll 1
ls: 1: No such file or directory
arolla$ ll 2
-rw-rw-r--   1 tmb      idiap           0 Aug 12 13:22 2

Since this behavior is extremely dangerous, I have remove GNU "mv" and
"cp" from our machines for the time being...

					Thomas.

Newsgroups: gnu.utils.bug
From: mycroft@gnu.ai.mit.edu
Subject: chown -R and symlinks
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 15:39:18 GMT

I don't believe `chown -R' should chase symlinks, at least by default.
This is dangerous.  It should probably avoid trying to modify symlinks
at all.


Newsgroups: gnu.utils.bug
From: cliff@trifid.astro.ucla.edu
Subject: problems with tar-1.10
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 01:18:31 GMT

 I have recently been having problems using tar-1.10 on my DECstation 5000/200s.
 I originally installed this version of tar-1.10 about 6 months ago and it
 appeared to work fine until recently.  The problem I'm having has to do with
 writing several tar files to the same DAT tape.  I like to use  mt fsf  to
 skip forward on the tape to the file I'm interested in reading or to the
 end of tape to write another tar file.  I'm finding that I can only skip
 about 2 files at a time if I try to skip more than that I get this error:
		/dev/nrmt0h fsf 5 failed: I/O error

 After skipping 3 files, I don't consistently get an error with mt but I do
 get an error with gtar (this is what I renamed tar-1.10 to):
	gtar -tvf gstars:/dev/nrmt0h
	gtar: read error on gstars:/dev/nrmt0h : No space left on device

 I know that this not the end of the tape because I can rewind it and use
 gtar to read every file starting from the beginning of the tape until I
 get to the last file at the end of the tape.  I'm not sure this is a
 problem with gtar since I get that error message when I use the mt command
 to skip forward on the tape.  Have you ever heard anything like this????
 It might have something to do with the mt command -- or more likely it is
 an error on the tape.  Is it possible that I can read across this error
 with gtar but not skip across it with mt?  Also problem doesn't seem to
 be linked to a specific tar file so I'm really puzzled.  Do you have
 any suggestions?  By the way, all of the files on this tape were written
 with tar-1.10 and I'm using the version of rmt that came with it since
 the DEC version didn't allow me to dump my Sun filesystems to the DAT drive
 on my DECstation.

 Thanks

 cliff

 cliff@trifid.astro.ucla.edu


Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Autoconf AC_INLINE documentation
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 18:38:30 GMT

This relates to GNU Autoconf 1.0 documentation.  It might be right, I
am not sure and just want to check.  In (Compiler Characteristics)
node, it is written:

   `AC_INLINE'
	If the C compiler is a version of GCC that supports the keyword
	`__inline' but not `inline' (such as NeXT ships), define `inline'
	to be `__inline'.  This macro calls `AC_PROG_CC' if it hasn't been
	called already.

With GCC 1.40, both `inline' and `__inline__' are normally available.
Is there GNU C variants in which neither `inline' nor `__inline__' are
available, while `__inline' would be?  Quite awkward if this is true!

-- 
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: talvola@qin.berkeley.edu (Erik Talvola)
Subject: Indent v1.5 (or anything) on VMS
Organization: /usr/users/talvola/.organization
Distribution: gnu
Date: Tue, 11 Aug 1992 20:58:19 GMT

Using GCC v2.2.2 on VMS, I have compiled indent-1.5 under
VMS v5.5.  However, it doesn't work.  The problem is that
apparently when indent reads the source file, there are null
characters in the input, which indent treat as end_of_file
tokens.  So, usually, no output results, but sometimes one line
will come out.

I used the VMS DUMP command to look at a typical sources file,
and it does look like there are null characters after the new
lines.  This seems really bogus, and I couldn't find a quick
work-around.  

If anyone has compiled GNU Indent, or BSD Indent, or anything 
under VMS, using VAXC or GNU C, then please let me know.  Thanks...

--- Erik
--
+----------------------------+
! Erik Talvola               | "It's just what we need... a colossal negative 
! talvola@qin.berkeley.edu   | space wedgie of great power coming right at us
! ...!ucbvax!qin!talvola     | at warp speed." -- Star Drek

Xref: sparky gnu.utils.bug:1392 gnu.announce:105
From: jla@gnu.ai.mit.edu (Joseph Arceneaux)
Newsgroups: gnu.utils.bug,gnu.announce
Subject: GNU indent 1.6 released
Date: 21 Aug 92 01:52:34 GMT
Reply-To: jla@ai.mit.edu
Followup-To: gnu.utils.bug
To: info-gnu@prep.ai.mit.edu

GNU indent changes the appearance of a C program by inserting or
deleting whitespace according to a great variety of options.  Several
canned styles of formatting are supported as well.  GNU indent is a
decendant of BSD indent.

GNU indent 1.6 is now available on prep.ai.mit.edu [18.71.0.38] in the
file /pub/gnu/indent-1.6.tar.Z.

Version 1.6 fixes all the bugs reported for version 1.5.

Please report bugs to the mailing list bug-gnu-utils@prep.ai.mit.edu
(not to the newsgroup gnu.utils.bug).

      [ Soon to be at these ftp sites as well.  Please try them
	before prep.ai.mit.edu!  thanx -len

	    archie.au, archive.eu.net, src.doc.ic.ac.uk, ftp.diku.dk,
	    ftp.informatik.tu-muenchen.de, ftp.eunet.ch, ftp.funet.fi,
	    isy.liu.se, ftp.stacken.kth.se, sunic.sunet.se,
	    ftp.win.tue.nl, ugle.unit.no, ftp.cs.titech.ac.jp,
	    wuarchive.wustl.edu, gatekeeper.dec.com, uxc.cso.uiuc.edu,
	    col.hp.com, and ftp.uu.net (under /packages/gnu).

	For information on how to order GNU software on tape, check
	the file etc/DISTRIB in the GNU Emacs distribution, or e-mail
	a request to:	gnu@prep.ai.mit.edu
      ]
Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU autoconf 1.0, no file on AC_OUTPUT()
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 19:38:19 GMT

*Maybe* GNU autoconf 1.0 should accept no files on AC_OUTPUT(), and
still produce a legal config.status.  Right now, it gives:

	[...]
	top_srcdir=$srcdir
	for file in ; do
	  srcdir=$top_srcdir
	[...]

which generates a shell syntax error.  The whole for loop could be
omitted.  Sometimes, the config.status file *is* the main output.

-- 
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: tmb@idiap.CH (Thomas M. Breuel)
Subject: GNU du
Reply-To: tmb@idiap.ch
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 22:48:14 GMT

GNU du adds trailing slashes. This confuses "xdu". I think the
trailing slashes should go or become optional...

arolla$ /bin/du x
5       x/y
10      x/z
21      x
arolla$ /sym/gnu/bin/du x
5       x/y/
10      x/z/
21      x/
arolla$ 

				Thomas.

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU indent 1.6 installation report
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 23 Aug 1992 02:45:44 GMT

This message pertains on GNU indent 1.6 installation, compiled with
GNU C 1.40 under COFF-encapsulation on a 386/ix 2.0.2 system (waiting
for Hurd to be ready :-).

For version 1.5, I suggested changing, in sys.h:

      #ifdef __STDC__
      #define INLINE inline
      #else
      #define INLINE
      #endif

by:

      #ifdef __GNUC__
      #define INLINE __inline__
      #else
      #define INLINE
      #endif

>From 1.5 to 1.6, the first line has been changed, the second has not.
Both changes are still necessary.  On this system, CC is predefined to
`gcc -ansi -Di386', and GNU C used together with -ansi does not define
inline, but only __inline__.  Node (gcc.info)Inline says:

   (If you are writing a header file to be included in ANSI C
   programs, write `__inline__' instead of `inline'.  *Ref Alternate
   Keywords::.)

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