🚀 go-pugleaf

In article <13345@reed.UUCP> trost@reed.UUCP (Bill Trost) writes:
>The following is a spurious bug I noted on both our DECstations and
>our UTek box.  This is a little twisted, so let me go into detail.

What's in your .bashrc?

>Oh, by the way, the Makefile has says that OS can be "Bsd", where it
>should say "BSD".  I found this misleading the first time through.

Nope, "Bsd" is right.  "BSD" is defined on 4.3 machines in
/usr/include/sys/param.h, so we needed another string to serve in
the Makefile.

Chet Ramey
Chet Ramey			"We are preparing to think about contemplating 
Network Services Group, CWRU	 preliminary work on plans to develop a
chet@cwjcc.INS.CWRU.Edu		 schedule for producing the 10th Edition of 
				 the Unix Programmers Manual." -- Andrew Hume

   Date: 26 Sep 89 05:29:22 GMT
   From: ogccse!reed!trost@ucsd.edu  (Bill Trost)
   Organization: Reed College, Portland OR

   The following is a spurious bug I noted on both our DECstations and
   our UTek box.  This is a little twisted, so let me go into detail.

   In all cases, I am executing "xterm -e bash" from a shell inside
   emacs.

From which shell within Emacs?  /bin/csh?  /bin/sh?

  The machines are:

   -- a DECstation (TARGET=VAX, OS=BSD, BISON=yacc, CC=cc).  gcc was not
   available for this machine.

OS should be "Bsd", not BSD.

   -- a Tektronix 4310 box (TARGET=SUN3, OS=BSD, BISON=yacc, CC=gcc).
   These are little 68020 boxes running a variant of 4.2BSD.

CC='gcc -traditional' I hope, or job control and readline won't compile
correctly, unless...  Do you have the fixed-include files for gcc
installed? 

   -- a Vax 11/785 (TARGET=VAX, OS=BSD, BISON = bison -y, CC=gcc).

   When using gcc, I had the flags -g -fstrength-reduce
   -finline-functions.

For all of the above,  were the exact same source files used in each
case?  Did you apply patches to one set of sources, and not the other?
What version of Bash were you compiling in each case?

   On each machine, I executed the xterm.  On all machines, the .bashrc
   wasn't read.  This bug, and the one I'm about to describe, also occur
   when logging in from a McMacintosh over telnet (though the .profile
   may have been, I don't know...), or from within emacs, or....

If Bash is a login shell, it reads the ~/.bash_profile file, but
deliberately does not read the ~/.bashrc file.  You must source the
.bashrc file from within your .bash_profile file.  If you don't already
know this, could this explain the behaviour that you are having?  If you
are using bash-1.03, then this is likely to be the case, since it is a
little confused about what constitutes a login shell.

   $ for i in a b; do echo $i; done
	works,
   $ . ~/.bashrc
   $ for i in a b; do echo $i; done
	gives error "`done' is not a valid identifier"

Possibly there is an open FOR loop in your .bashrc.  Please send it.

   And, for good measure, if I recompile bash on the Vax with yacc, I get
   the same bug.  Looks like we have a parser-generator incompatibility.

Yes, which version of Bison did you use?  Perhaps there is a bug in
bison which allows an error to slip through.

Brian