trost@reed.UUCP (Bill Trost) (09/26/89)
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
chet@kiwi.CWRU.EDU (Chet Ramey) (09/27/89)
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
bfox@aurel.cns.caltech.edu (Brian Fox) (09/27/89)
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
trost%REED.BITNET@MITVMA.MIT.EDU (09/28/89)
Details that Brian asked about: Subshell in emacs was usually /bin/csh. gcc got the appropriate flags (like -traditional) --- it did, after all, compile. The include files have not been "fixed". I have made no changes to the sources; they are made from literally the same source files. I have made no patches, no nothin'. Just compile and go --- your configuration management is very clean. I finally understand the bit about not reading the .bashrc. Trouble is, bash being run under an xterm isn't really a login shell. How is loginness being determined? (I know --- UTSL). *And*, it looks like I dropped a critical part of the bug report. After reading the .bashrc, if I put the entire for loop on one line, it works --- if I break it up, it doesn't. This is almost definetely a grammar problem. Our bison is version 1.03. Oh, and why does "rsh reed xterm -display bassoon:0" cause my .profile to be executed? This is confusing; I thought non-interactive processes weren't supposed to get anything? (I switched shells last night, so my environ has changed slightly). ---------------- STOP THE PRESSES! A little experimentation points out the problem. Setting the shell variable PROMPT_COMMAND causes the error I described when the shell is compiled with yacc. Record follows: % bash -norc bash$ PROMPT_COMMAND='dirs' /reed/u/ss/trost bash$ for i in a b; do /reed/u/ss/trost bash>echo $i /reed/u/ss/trost bash>done `done' is not a valid identifier /reed/u/ss/trost bash$ for i in a b; do echo $i; done a b /reed/u/ss/trost bash$