Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!aurel.cns.caltech.edu!bfox From: bfox@aurel.cns.caltech.edu (Brian Fox) Newsgroups: gnu.bash.bug Subject: yacc/bison incompatibility? Message-ID: <8909271526.AA04168@aurel.caltech.edu> Date: 27 Sep 89 15:26:08 GMT References: <13345@reed.UUCP> Sender: daemon@tut.cis.ohio-state.edu Reply-To: bfox@aurel.cns.caltech.edu Distribution: gnu Organization: GNUs Not Usenet Lines: 63 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