Re: autoconf problem building

[Eurico de Sousa]

I added </dev/null (in aclocal.m4 I presume) as suggested, but it still hangs 
on the configure. I
don't know much about it as I don't use it, but it doesn't seem to accept any 
options I give it,
like -help, --version, -v, -V. When I run emacs, I can't CTRL-C out of it to 
get back to the shell -
it hangs - I have to kill the cmdtool (Solaris 2.6/7/8). If I run 
emacs</dev/null, I can CTRL-C out
of it. Unfortunately, I don't have any man pages for it. However, I just 
noticed we have a very old
version of MicroEmacs - I have MicroEmacs 3.6 installed (1990!!).

I will try installing the latest version and rebuild autoconf. Should this make 
a difference do you
think?

Eurico

Tim Van Holder wrote:

> > Tim> Oh dear - looks like your emacs ignores command lines it doesn't
> > Tim> recognize and uses stdout as a terminal even if it isn't a tty...
> >
> > Tim> Does MicroEmacs even support Emacs Lisp packages?  If not, we
> > Tim> should probably adjust the emacs test to disallow MicroEmacs.
> >
> > Correct.  Tim, would you handle this bug report please?
>
> Sure.
>
> >  As a first
> > stab, I would suggest to have `</dev/null' added:
>
> Eurico, does adding "</dev/null" as below actually help?
> (i.e. does 'emacs </dev/null' start up emacs normally, or
> does it exit?)  Does it actually use Emacs Lisp, or some
> other scripting system (if any)?
>
> If not, does MicroEmacs have a --version option, or some other way
> we can identify it?  Then at least we can check for it and avoid
> running it.
>
> >        [AC_RUN_LOG([$EMACS -batch -q -eval '(while load-path
> > (princ (concat (car load-path) "\n")) (setq load-path (cdr
> > load-path)))' >conftest.out])
> >
> > =>
> >         [AC_RUN_LOG([$EMACS -batch -q -eval '(while load-path
> > (princ (concat (car load-path) "\n")) (setq load-path (cdr
> > load-path)))' >conftest.out < /dev/null])
> >
> > Actually, I *strongly* suggest that it be added.  Would you also
> > handle the Automake part?
>
> Sure.  Is this required for anything other than this problem?
> If not, it might not be needed (as we should probably reject
> MicroEmacs in the first place, so this would never be run to
> begin with).