I use ksh As part of the .profile, it runs the terminal reset sequence each login I don't see this as bad behavior
The ,kshrc file sets the prompt and does no other output. I don't see either of these as setting up a bad environment I don't see why either should break the test scripts. On Feb 26, 2010, at 8:02 AM, Eric Blake wrote: > [moving to bug-m4; replies can drop bug-autoconf] > > According to Gene Spafford on 2/25/2010 11:10 PM: >> Thanks for the reply, Ralf. >> >> I am enclosing the output of the "make check" on the m4 build so you can see >> the failures. > > M4 failures should be reported to the m4 list; so I've redirected accordingly. > > All of the failures in your log look like: > > Checking ./006.command_li > @ ../doc/m4.texinfo:979: Origin of test > ./006.command_li: stderr mismatch > --- m4-tmp.13684/m4-xerr Fri Feb 26 01:01:42 2010 > +++ m4-tmp.13684/m4-err Fri Feb 26 01:01:42 2010 > @@ -1,2 +1,4 @@ > +Must be attached to terminal for 'am I' option > +Must be attached to terminal for 'am I' option > hi > bye > > Each of those tests invoke a subsidiary instance of m4 via the equivalent > to a system() call (that is, an instance of /bin/sh is spawned to find the > subsidiary m4). My guess is that you have a weird environment setup, such > that /bin/sh attempts to call who(1) during startup and ends up being > quite noisy. In other words, the bug is not in m4, but in your > /etc/profile, ~/.bashrc, or some other sort of script startup file. It is > bad practice to have noisy startup environment files. > > I know of no way to make m4 robust against such a bad environment, where > the mere act of starting /bin/sh outputs junk to stderr before the > intended command passed to system() is even started. > > -- > Don't work too hard, make some time for fun as well! > > Eric Blake e...@byu.net >
smime.p7s
Description: S/MIME cryptographic signature
