HDTenEightyP/NetNews huggingface dataset:
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: altering pathnames
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 28 Aug 1992 12:46:21 GMT

   Resent-Date: Fri, 28 Aug 1992 08:13:18 -0400
   Date: Fri, 28 Aug 1992 08:13:18 -0400
   From: karl@claude.cs.umb.edu (Karl Berry)
   Sender: gnulists@ai.mit.edu
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

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

Clearly not, because / at the end of a directory causes a failure if
it's just a file, and this is important.  The file utilities assume
that nobody cares about this distinction, or that they just don't know
about it.

   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?

It's running on the kernel that we care about, and it's here that the
file utilities *remove* a useful bit of functionality.

   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.

The "most convenient way" as I see it is for the program to act as a
simple program which executes a simple system call.  

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

Yes.  If the file is changed from a directory to an ordinary file
between the stat and the rename, then the (new) file gets obliterated.
The original semantics guarantee (because they rely on the kernel to
make this decision) a certain measure of atomicity.

The general idea is that programs should not be more clever than the
kernel, thus, you get a system with only one set of rules to remember
instead of two.

	-mib



Newsgroups: gnu.utils.bug
From: rsm@math.arizona.edu (Robert S. Maier)
Subject: HAVE_TZNAME problem with shellutils-1.7
Organization: Mathematics Department, University of Arizona
Distribution: gnu
Date: Fri, 28 Aug 1992 00:42:07 GMT

Under DG/UX 5.4 on a Data General Aviion, shellutils-1.7 compiles and runs,
out of the box, except for one small problem: date(1) coredumps.  I traced
this problem to an omission in the autoconfigured Makefile.

DG/UX has tzname, but the automatically configured Makefile didn't contain
-DHAVE_TZNAME.  This caused a problem with lib/strftime.c: the function
zone_name() was unnecessarily included and compiled.  zone_name calls
timezone(), but calling timezone() in DG/UX seems not to work.
It's an undocumented function, anyway.

The problem is ultimately due to a bug in the configure script.  It checks
for tzname only if tm_zone is present in struct tm.  I see no reason for
this.  DG/UX has no tm_zone in struct tm, so HAVE_TZNAME never got set.

My recommendation: fix configure (and also, the documentation line in the
Makefile) so that HAVE_TM_ZONE and HAVE_TZNAME are truly independent.  Any
given system may have one but not the other.

-- 
Robert S. Maier   | Internet: rsm@math.arizona.edu, rsm@cs.arizona.edu
Dept. of Math.    | UUCP: uunet!arizona!amethyst!rsm
Univ. of Arizona  | Bitnet: maier@arizvms
Tucson, AZ  85721 | FAX: +1 602 621 8322
U.S.A.            | Voice(POTS): +1 602 621 6893  /  +1 602 621 2617

Newsgroups: gnu.utils.bug
From: lmorris@mdd.COMm.mot.COM (Larry Morris)
Subject: make 3.62 problem (from make 3.59)
Organization: Motorola, Mobile Data Division - Seattle, WA
Distribution: gnu
Date: Thu, 3 Sep 1992 21:50:15 GMT

I had a makefile which was running under gnumake 3.59.  When I upgraded
to 3.62, it failed.  I tracked the problem to a statement which was
on multiple lines and did a redirection.  A short sample is:

---------------  Makefile ---------------------------
define BINCMD
	ls -l \
	  > out_file
endef

all:
	$(BINCMD)
---------------  End Makefile -----------------------

The 3.59 results are what I expected, a file listing in out_file.  The 3.62
results are an "ls -l" echoed to my screen, then the "> out_file" is
run, apparently as a separate command.  Things work fine if I either don't
split the line, or split with some character other than ">" as the first
char of the continued line.

I assumed that the ">" had been added as some sort of special symbol, but
found no reference to it in the documentation.  Is this a bug, or yet
another RTFM?



Also, what happened to the "-" operator?  I used -rm on a lot of my 
rules to ignore errors if the file didn't exist.  Not really needed
with "rm -f" but I am curious why it went away.  In 3.62, I get
errors from the shell that -rm is not a valid command.  Once again, sorry if
this is documented.  The most recent docs I found are 3.61 Beta and I am
running 3.62, so I may have missed something.


Thanks in advance.
-- 
Internet:    <lmorris@mdd.comm.mot.COM>   |  Larry Morris
 ...uw-beaver!sunup-----\                 |  Motorola/Mobile Data Division
 ...uunet-----------------!mdisea!lmorris |  19807 North Creek Parkway
 ...van-bc!mdivax1------/                 |  Bothell, WA  (206) 487-5810

Newsgroups: gnu.utils.bug
From: toy@alydar.CRd.ge.COM (Raymond L. Toy)
Subject: Indent 1.6:  bug in reading stdin
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 08:31:17 GMT

In indent 1.6, there is a stupid bug that causes the
input to be overwritten.  It's caused by not resetting the
input pointer when the buffer has been realloc'ed to a new
place.  The patch is a simple two-line addition to update
the input pointer after realloc'ing the input buffer.
Patch follows.

Ray
----------
Ray -----> toy@soho.crd.ge.com
Toy -----> KWC407, x6270

---------------Cut here------------
*** io.c~       Fri Aug 14 19:09:17 1992
--- io.c        Wed Aug 26 12:26:00 1992
***************
*** 502,509 ****
--- 502,511 ----

        if (ch != EOF)
        {
+         int offset = p - stdinptr.data;
          size += (2 * BUFSIZ);
          stdinptr.data = xrealloc (stdinptr.data, size);
+         p = stdinptr.data + offset;
        }
      }
    while (ch != EOF);
From: greg@wind.UUCP
Newsgroups: gnu.utils.bug
Subject: Possible SED interval bug.
Date: 25 Aug 92 19:56:13 GMT
Distribution: gnu
Organization: GNUs Not Usenet

I pulled down v1.09 from prep this morning so that I could compile a
fresh copy under LINUX(c) using shared libraries.  Just a couple of
comments, perhaps I need some clarification.

When the regex syntax is set near the start of main in sed.c the
define RE_NO_BK_BRACES is used.  This of course obviates the need for
backslashes when specifying intervals.  In most other sed's that I
have been exposed to there has always been the need to backslash both
parenthesis and braces when these characters are to have special
meanings.

This conjecture is based on the fact that according to the documents I
have the regular expression syntax in SED is supposed to be compatible
with ED.  I believe that ED requires backslashes to both parenthesis
and backslashes.  I would be interested in comments and or
clarifications.

My second concern has to do with what appears to be an inconsistency
in handling three regular expressions which should be equivalent.

I am attempting to parse out the system name from UUCP work files
generated by Taylor uucp.  These of course are of the form: C.xxxxxxxyzzzz

	Where:   xxxxxxx => System name.
                       y => UUCP transport grade.
                    zzzz => Job sequence number.

The test example which I have been using is:

	/usr/spool/uucp/systemx/C.systemxN0000

	From now on the aforementioned string will be referred to as
	$system.

The following command correctly produces as output: systemx

	echo $system | sed -e 's/.*\.\([a-zA-Z]*\).....$/\1/'

The following command results in a failure to match which generates
the original string as output.

	echo $system | sed -e 'sed -e 's/.*\.\([a-zA-Z]*\).\{5\}$/\1/'

However the following produces as output: systemx

	echo $system | sed -e 'sed -e 's/.*\.\([a-zA-Z]*\).\{5,\}$/\1/'

If my references and understanding of ED's regular expression syntax
is correct the above three should produce identical output.


Any comments, suggestions or clarifications would be appreciated.
Thanks for taking the time to consider this.

                           As always,
                           Dr. G.W. Wettstein
                           Oncology Research Division Computing Facility
                           Fargo Clinic / MeritCare

                           UUCP: uunet!plains!wind!greg
                           INTERNET: greg%wind.UUCP@plains.nodak.edu
                           PHONE: 701-234-2833

`The truest mark of a man's wisdom is his ability to listen to other men
 expound their wisdom.'
Newsgroups: gnu.utils.bug
From: dir@lookout.IT.USwc.USwest.COM (Daniel I. Rosenblatt)
Subject: make 3.62 problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 02:43:17 GMT

I've run across a problem with GNU make and Imake.
The command sequence in imake is (typical for imake with sub-directories):
	for i in list_of_directories ;\
	do \
	    (cd $$i ; echo Making all in $$i ...; \
	    $(MAKE) $(MFLAGS) all ); \
	done
This command sequence is executed via '/bin/sh -c command_sequence'.
The problem is that if a non-last (from list_of_directories) sub-make
aborts with an error, the sub-make reports the error but the 1st level
make does not quit.  The fix is to pass the -e flag to the shell which
says 'exit immediately if a command exits with a nonzero exit status'.
This additional flag to the shell should probably be optional based on
-k being given to make (-k given to make should imply no -e to the shell).

Note that Sun's version of make does pass -e to the shell, though I
haven't verified that passing -k to make turns off -e to the shell.

Dan Rosenblatt

Newsgroups: gnu.utils.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: more thoughts on fileutils
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 30 Aug 1992 20:57:28 GMT

      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.

It follows from this that the canonical way to use mv to rename into a
directory named foo must be `mv bar foo/'.  `mv bar foo' is something
that may or may not work.

So it is proper that `mv bar foo/' work now on Unix systems.  On the
GNU system, this can work by passing `bar/' to the kernel unmodified.
But if on other systems that is not true, then on those other systems
mv needs to compensate by deleting the /.



Xref: sparky gnu.utils.bug:1470 comp.os.msdos.programmer:9044
From: pynq@midway.uchicago.edu (George Jetson)
Newsgroups: gnu.utils.bug,comp.os.msdos.programmer
Subject: Re: MS-DOS Version of diff Exhausts Memory
Date: 3 Sep 92 15:58:35 GMT
Reply-To: pynq@midway.uchicago.edu
Followup-To: gnu.utils.bug,comp.os.msdos.programmer
Organization: D. J. Dougherty & Associates
Apparently-To: <gnu-utils-bug@ncar.ucar.edu>

In article <87kn3yb.westes@netcom.com> westes@netcom.com (Will Estes) writes:
>Using the MS-DOS version of diff 1.15, I occasionally get an error
>message reporting that memory has been exhausted (this on a machine that
>has 15 megs of extended memory).  Do other users of the
>MS-DOS version get the same error?  Can someone point me to an ftp site
>for a version of diff that has been made to work with VCPI, DPMI, or EMS
>under MS-DOS?

This tells us nothing about which specific version of diff you are using.
Who is it from? Who compiled it? Which compiler? etc.

Anyway, get the DIFF that comes with DJGPP.  It seems to have no memory limits.

************************************************************************
A note to new readers:  the weasely :-) symbol is frowned upon in this
group.  Any questions, see Phil Gustafson who will gladly rearrange your
diodes for you.
			- From the AFU FAQ -

	- pynq@quads.uchicago.edu, who is still costing the net
	  hundreds, if not thousands, of dollars, every time he posts -
************************************************************************
Xref: sparky gnu.utils.bug:1466 comp.os.msdos.programmer:9015
From: westes@netcom.com (Will Estes)
Newsgroups: gnu.utils.bug,comp.os.msdos.programmer
Subject: MS-DOS Version of diff Exhausts Memory
Date: 3 Sep 92 00:07:36 GMT
Followup-To: gnu.utils.bug,comp.os.msdos.programmer
Organization: Mail Group
Apparently-To: gnu-utils-bug@ames.arc.nasa.gov

Using the MS-DOS version of diff 1.15, I occasionally get an error
message reporting that memory has been exhausted (this on a machine that
has 15 megs of extended memory).  Do other users of the
MS-DOS version get the same error?  Can someone point me to an ftp site
for a version of diff that has been made to work with VCPI, DPMI, or EMS
under MS-DOS?

Thanks,
Will Estes		Internet: westes@netcom.com
Newsgroups: gnu.utils.bug
From: mycroft@gnu.ai.mit.edu
Subject: autoconf: Doesn't catch `tzname' on RS/6000.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 08:22:14 GMT

The test case `configure' tries to compile to check for `tzname' looks
like this:

  #include <time.h>
  #ifndef tzname /* For SGI.  */
  extern char **tzname;
  #endif
  main() { exit(0); } t() { atoi(*tzname); }

With some versions of the IBM C compiler, this generates an error:

  "conftest.c", line 3.15: 1506-030 (S) Identifier tzname cannot be redeclared.

This is because previously, in <time.h>, `tzname' was defined as:

  extern char *tzname[];

This generates a type mismatch.  Defining the test case as:

  #include <time.h>
  #ifndef tzname /* For SGI.  */
  extern char *tzname[];
  #endif
  main() { exit(0); } t() { atoi(*tzname); }

solves the problem, on this machine.


Xref: sparky gnu.utils.bug:1430 gnu.gdb.bug:1010 comp.unix.aix:9160
From: ramabs2@rpi.edu (Shiva Ramabadran)
Newsgroups: gnu.utils.bug,gnu.gdb.bug,comp.unix.aix
Subject: GNU regex routines.(for xxgdb) on AIX
Summary: Buggy as hell !!
Date: 27 Aug 92 15:39:04 GMT
Followup-To: gnu.utils.bug
Organization: Information Technology Services, 
              Rensselaer Polytechnic Institute, Troy NY
Apparently-To: gnu-utils-bug@cis.ohio-state.edu

Hi,

	I'm trying to use the GNU regex routines that are available 
as part of _many_ GNU products. (emacs-18.58, gdb-4.5, xxgdb-1.06, to
name a few.)

	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  '[ ]*'. 

	Has anyone been able to use these on an Rs/6000 ? I'd 
suspect that it is a memory leak which fails to get past AIX's
stringent memory management scheme. The same code works on a 
Sun and other platforms. 

	Has anyone got xxgdb working on an Rs/6000 ? 

	Is there a newer version of this code that I can ftp from
anywhere ? The regex.[ch] that is part of the above GNU products does
not seem to work on Rs/6000's.

	Any help will be appreciated. 

Thanks, 

-Shiva
-=-
ITS Systems Programmer.
Newsgroups: gnu.utils.bug
From: trq@dionysos.thphys.ox.ac.uk
Subject: bug in sed 1.09
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 09:41:23 GMT

The following script will cause sed to abort in re_compile_fastmap()
and dump core.  It appears that the 'on_failure_keep_string_jump'
opcode is not handled by the switch in re_compile_fastmap().

This is GNU sed version 1.09 compiled with GCC version 2.2.2 on a
Sparcstation ELC running SunOS 4.1.1.

The sed command:
        ./sed -n                \
        -e '/^\.c\.o:.*;/{'             \
        -e    's/\$\*\.c//'             \
        -e    's/^[^;]*;[        ]*//p' \
        -e    q                         \
        -e '}'                          \
        -e '/^\.c\.o: *$/{'             \
        -e    N                         \
        -e    's/\$\*\.c//'             \
        -e    's/^.*\n[  ]*//p'         \
        -e    q                         \
        -e '}' < mf
and the file "mf" contains:
.c.o:
	$(CCCMD) $*.c
The following is a suggested patch:
===================================================================
RCS file: RCS/regex.c,v
retrieving revision 1.1
diff -c -r1.1 regex.c
*** 1.1	1992/08/31 09:18:53
--- regex.c	1992/08/31 09:20:38
***************
*** 2436,2441 ****
--- 2436,2442 ----
  	case notwordbound:
  	case wordbeg:
  	case wordend:
+ 	case on_failure_keep_string_jump:
            continue;
  
Tom Quinn        Theoretical Physics, University of Oxford
Internet: 	 trq@dionysos.thphys.ox.ac.uk
JANET:    	 trq@uk.ac.ox.astro
Phone:		 44-865-273956

Newsgroups: gnu.utils.bug
From: schrod@iti.INformatik.TH-darmstadt.DE (Joachim Schrod)
Subject: Re: GNU fileutils v3.2.3 alter pathnames by removing trailing slashes
Organization: TU Darmstadt
Distribution: gnu
Date: Thu, 27 Aug 1992 09:59:44 GMT

In article <9208261851.AA19014@geech.gnu.ai.mit.edu>, mib@gnu.ai.mit.edu (Michael I Bushnell) writes:
> The solution is for readline completion to refrain from appending the
> slash when complieting tto the name of a directory.

!!!! NO !!!!

It's such a nice thing to see immediately if a file is a directory or
not. Otherwise one cannot distinguish the fact if this is a common
prefix of more than one file or if it's a directory. (Btw, your
example was wrong. You forgot the space at the end of the completed file.)

--
Joachim

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

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: Fri, 28 Aug 1992 12:57:34 GMT

There is another, even more important reason for not having the
fileutils be overly clever.

In GNU, nodes can be both directories and ordinary files.  (This is a
*possibility* for filesystems; it will not be thus for ufs
filesystems, but it will be thus for other kinds of filesystems in the
initial release.)

The interpretation of such a node is based on context.  When it is
used as a directory, it is a directory.  When used as a file, it is a
file.  Typically, filesystems which permet this are not disk based,
and the contents of the directory tree under such a node is also
present elsewhere on the system.  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.

To summarize, there are the following possibilities:

Command used->    	    mv bar foo	 		mv bar foo/
Type of foo
    |
    v
ordinary file		    replace foo with bar	generate error

just a directory	    replace foo/bar with bar	ditto

both dir and file	    replace foo with bar	replace foo/bar
							with bar

Filename completion will need to be wise to this possibility in the
Hurd, and, when it is, the fileutils need to be "unclever".

	-mib


Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: GNU shellutils 1.7 installation report
Reply-To: pinard@iro.umontreal.ca
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 16:37:34 GMT

This is an installation report for GNU shellutils 1.7, using GNU C
1.40 under COFF-encapsulation, on a 386/ix 2.0.2 system (waiting for
Hurd :-).

* Compilation yields:

	making all in lib
	strftime.c:78: sys/time.h: No such file or directory

The problem resides in the fact that, in configure, we read:

	if test -n "$no_tm_zone"; then
	echo checking for tzname
	echo "#include <time.h>
	#ifndef tzname /* For SGI.  */
	extern char **tzname;
	#endif
	main() { exit(0); } t() { atoi(*tzname); }" > conftest.c
	if eval $compile; then
	  DEFS="$DEFS -DHAVE_TZNAME=1"
	fi
	rm -f conftest*

In <time.h> on this machine, we read:

	extern char *tzname[];

which conflicts with the declaration of tzname included in the test.
This causes the test to fail, so HAVE_TZNAME will not be defined as it
should.  So, I removed the include declaration for installing on this
386/ix 2.0.2 system, but this would break installation on SGI's.  The
proper correction is not obvious to me.

* Passing by, modifying `configure' does not bring Makefile's to be
automatically redone.  I think they should.

* `su' is missing at two places in src/Makefile.in:

--- 1.1	1992/08/29 13:14:20
+++ ./src/Makefile.in	1992/08/29 13:15:54
@@ -52,7 +52,7 @@
	etags $(SOURCES)

 clean:
-	rm -f $(PROGS) *.o core
+	rm -f $(PROGS) su *.o core
 .PHONY: clean

 mostlyclean: clean
@@ -70,7 +70,7 @@
	ln $(DISTFILES) ../`cat ../.fname`/src
 .PHONY: dist

-$(PROGS): ../lib/libshu.a version.o
+$(PROGS) su: ../lib/libshu.a version.o

 basename: basename.o
	$(CC) $(LDFLAGS) -o $@ basename.o ../lib/libshu.a version.o $(LIBS)

-- 
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: josh@viewlogic.COM (Josh Marantz)
Newsgroups: gnu.gcc.bug
Subject: empty-else-body warning
Date: 25 Aug 92 21:30:51 GMT
Distribution: gnu
Organization: GNUs Not Usenet

A number of people suggested that I do something like:

	#define MAC()	if (whatever) something ; else {}

in place of what I had, which is this:

	#define MAC()	if (whatever) something ; else

The problem is that I want to allow users of the macro to
use them in the following context:

    if (some_condition)
        MAC ();
    else
        do_something_else;

which won't work if I end the else clause with {}.  I need to let the
macro caller supply the ";" to make the macro call look like a
statement.

Skip Montanaro suggested I do this:

    #define TEST(a) do { if (a) printf("a") ; } while (0)

That would work.  In fact, I already use this form to make macros out
of a blocks of statements that are *not* in an if statement, but I'm a
little concerned that some compilers (not gcc, I assume, but I have to
use others as well) will fail to optimize this ersatz loop away, so I
didn't put one in except where necessary.  It doesn't appear to be
necessary to put in the do{...}while(0) syntax when there's a
conditional, so I'd prefer not to do it.  Unfortunately for me, gcc
2.2.2 warns about this (though not 1.39), so I'm hoping I can lobby
for the ability to disable this warning message.  What are my chances?

Thanks,
-Josh
Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: WRONG LIST (was: Re:  gcc-2.2.2 and extended class scope operator)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 13:26:22 GMT

In the future please report all g++ bugs to the

        bug-g++@prep.ai.mit.edu

list, thanks.  If they are back-end bugs, they can be reported here,
but please let us know if you think the problem is in the back-end.

You don't need to resubmit this one.

> From: "Amos A. Gouaux" <amos@sol.acs.unt.edu>
> Message-Id: <199208211616.AA19052@sol.acs.unt.edu>
> To: bug-gcc@prep.ai.mit.edu
> Date: Fri, 21 Aug 92 11:16:13 CDT

> i'm sending an uudecoded file called bug.tar.Z.  it includes a Makefile with
> the targets good, bad, and clean.  the sources contained demonstrate what
> i believe is a bug.  when i have a non-template class nested inside of a

Newsgroups: gnu.gcc.bug