Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ogccse!reed!trost
From: trost@reed.UUCP (Bill Trost)
Newsgroups: gnu.bash.bug
Subject: yacc/bison incompatibility?
Message-ID: <13345@reed.UUCP>
Date: 26 Sep 89 05:29:22 GMT
Organization: Reed College, Portland OR
Lines: 44

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.  The machines are:

-- a DECstation (TARGET=VAX, OS=BSD, BISON=yacc, CC=cc).  gcc was not
available for this machine.
-- a Tektronix 4310 box (TARGET=SUN3, OS=BSD, BISON=yacc, CC=gcc).
These are little 68020 boxes running a variant of 4.2BSD.
-- 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.

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

At this point, the command string:
$ for i in a b; do
> echo $i
> done
do what you expect them to do.  I now type ". ~/.bashrc", and repeat
the same string of commands, to get the error message "`done' is not a
valid identifier" *if* I am on a DECstation or a UTek box, but *not*
on the Vax.

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.
How scary.  Sorry about all the unnecessary detail in here, but it was
a twisty maze to get to this.

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.

And, a request/suggestion:  I would prefer not to have PROMPT_COMMAND
not executed when PS2 is displayed --- must be time for Yet Another
Shell Variable.
-- 
Whaddya mean, these are *my* opinions??  I never wrote that!
Bill Trost
trost@reed.bitnet, but probably trost%reed@tektronix.tek.com