Re: emacs Shell mode vs AC_CHECK_PROG(EMACS, ...)
Chet == Chet Ramey [EMAIL PROTECTED] writes: Chet Bash does inspect the EMACS environment variable as part of Chet checking whether or not to turn off line editing even when Chet the shell is interactive. It also checks for TERM==emacs. Chet If the shell discovers it's running in an emacs buffer, it Chet turns off readline. Maybe emacs should be in charge of turning readline off directly instead expecting the shell to check envars to deal with special cases. For example, emacs could send the shell something like shopt -u -o emacs; shopt -u -o vi. Then emacs could leave EMACS alone. It might also be a good idea for AC_CHECK_COMMAND to at least give a warning if shell variables have crazy-seeming values like t, 0 or 1. Better yet, when envars try to override command names it could check whether the the command really exists. Or, PROG=enval AC_CHECK_COMMAND(PROG, foo bar ...) -- AC_CHECK_COMMAND(PROG, enval foo bar ...) -Don
must install-sh be executable?
Hi, In automake-1.9b, the @install_sh@ variable was changed to start with '$(SHELL) '. 2005-10-03 Peter O'Gorman [EMAIL PROTECTED] (tiny change) * lib/am/distdir.am: Remove $(SHELL) when calling install_sh * m4/strip.m4: Ditto. * m4/install-sh.m4: Add $(SHELL) to the definition of install_sh Apparently as a protection against invoking a non-executable shell script. But AM_PROG_MKDIR_P sets mkdir_p to $MKDIR_P from AC_PROG_MKDIR_P, and the value of MKDIR_P from AC_PROG_MKDIR_P can be set to a value that doesn't start with $(SHELL): ac_install_sh=$ac_aux_dir/install-sh -c ... MKDIR_P=$ac_install_sh -d Similarly, the INSTALL variable may be set to a value that doesn't start with $(SHELL): ac_install_sh=$ac_aux_dir/install-sh -c ... INSTALL=$ac_install_sh Here is a fix that ensures that INSTALL and MKDIR_P are always starting with $(SHELL) when they refer to a shell script in the package. 2006-09-10 Bruno Haible [EMAIL PROTECTED] Don't require that install-sh be executable. * lib/autoconf/status.m4 (_AC_OUTPUT_FILE): Prefix ac_INSTALL and ac_MKDIR_P with $(SHELL) when they refer to install-sh or install.sh or shtool. *** autoconf-2.60a/lib/autoconf/status.m4.bak 2006-08-08 18:29:05.0 +0200 --- autoconf-2.60a/lib/autoconf/status.m4 2006-09-10 18:21:28.0 +0200 *** *** 493,498 --- 493,500 AC_PROVIDE_IFELSE([AC_PROG_INSTALL], [ case $INSTALL in [[\\/$]]* | ?:[[\\/]]* ) ac_INSTALL=$INSTALL ;; + */install-sh -c | */install.sh -c | */shtool install -c) + ac_INSTALL=\$(SHELL) $ac_top_build_prefix$INSTALL ;; *) ac_INSTALL=$ac_top_build_prefix$INSTALL ;; esac ])dnl *** *** 500,506 [ ac_MKDIR_P=$MKDIR_P case $MKDIR_P in [[\\/$]]* | ?:[[\\/]]* ) ;; ! */*) ac_MKDIR_P=$ac_top_build_prefix$MKDIR_P ;; esac ])dnl _ACEOF --- 502,510 [ ac_MKDIR_P=$MKDIR_P case $MKDIR_P in [[\\/$]]* | ?:[[\\/]]* ) ;; ! */install-sh -c -d | */install.sh -c -d | */shtool install -c -d) ! ac_MKDIR_P=\$(SHELL) $ac_top_build_prefix$MKDIR_P ;; ! *) ac_MKDIR_P=$ac_top_build_prefix$MKDIR_P ;; esac ])dnl _ACEOF This fix has no effect for automake's mkdir_p variable, since it is coded to use the value of MKDIR_P (before config.status), not of ac_MKDIR_P (inside config.status). So here is an additional fix: 2006-09-10 Bruno Haible [EMAIL PROTECTED] Don't require that install-sh be executable. * m4/mkdirp.m4 (AM_PROG_MKDIR_P): Prefix mkdir_p with $(SHELL) when it refers to install-sh or install.sh or shtool. *** automake-1.9b/m4/mkdirp.m4.bak 2006-08-20 17:37:06.0 +0200 --- automake-1.9b/m4/mkdirp.m4 2006-09-10 18:24:03.0 +0200 *** *** 21,26 AC_SUBST([mkdir_p], [$MKDIR_P])dnl case $mkdir_p in [[\\/$]]* | ?:[[\\/]]*) ;; ! */*) mkdir_p=\$(top_builddir)/$mkdir_p ;; esac ]) --- 21,28 AC_SUBST([mkdir_p], [$MKDIR_P])dnl case $mkdir_p in [[\\/$]]* | ?:[[\\/]]*) ;; ! */install-sh -c -d | */install.sh -c -d | */shtool install -c -d) ! mkdir_p=\$(SHELL) \$(top_builddir)/$mkdir_p ;; ! *) mkdir_p=\$(top_builddir)/$mkdir_p ;; esac ])
Re: Autoconf 2.60a on UnixWare 7.1.4
On Mon, 11 Sep 2006, Ralf Wildenhues wrote: * Tim Rice wrote on Mon, Sep 11, 2006 at 03:35:11AM CEST: I got an opportunity to test 2.60a on UnixWare 7.1.4. snip from test 168's config.status --- # Find out whether ``test -x'' works. Don't use a zero-byte file, as # systems may use methods other than mode bits to determine executability. cat conf$$.file _ASEOF #! /bin/sh exit 0 SESEOF chmod +x conf$$.file I have no idea why SESEOF is there instead of _ASEOF I had updated to m4-1.4.6 so just to make sure it wasn't a m4-1.4.6 problem, I went back to m4-1.4.4 and re-tested. Same problem. The problem can't be with m4, because the configure script looks identical to the one generated on a sane system, only the generated config.status file is bogus at this position. I assume another bug wrt. here-documents. Let's see: the problem occurs on line 256 of the generated config.status script, near byte 6524. This part is completely generated from the first here-document that contains config.status; it's delimited by \_ACEOF (thus no variable expansion within). Does the bug go away when you insert 1 (2, 3) empty lines before the inner here-document in the configure script (i.e., before line 2003)? What if instead you just insert some bytes before (e.g., in the comment)? Does the problem go away if you replace the inner here-document by echo '#! /bin/sh exit 0' conf$$.file And for those methods that work, could you retest, this time applying the change to autoconf/lib/m4sugar/m4sh.sh:_AS_TEST_PREPARE (it will cause changes to more than one point in the configure script)? Applying this patch makes it work. --- lib/m4sugar/m4sh.m4.old 2006-06-19 22:35:38.0 -0700 +++ lib/m4sugar/m4sh.m4 2006-06-19 22:35:38.0 -0700 @@ -1021,6 +1021,7 @@ m4_defun([_AS_TEST_PREPARE], [# Find out whether ``test -x'' works. Don't use a zero-byte file, as # systems may use methods other than mode bits to determine executability. + cat conf$$.file _ASEOF #! /bin/sh exit 0 In another e-mail, Paul suggests: So this very much looks like the same sort of problem that we already know that ksh has with here-documents and variables. He might try uniformly replacing _ASEOF with FOOEOF (without making any other changes) and see whether the word gets munged to OEOEOF. So I tried this patch (on a fresh tree). Tests passed. --- lib/m4sugar/m4sh.m4.old 2006-06-19 22:35:38.0 -0700 +++ lib/m4sugar/m4sh.m4 2006-06-19 22:35:38.0 -0700 @@ -1021,10 +1021,10 @@ m4_defun([_AS_TEST_PREPARE], [# Find out whether ``test -x'' works. Don't use a zero-byte file, as # systems may use methods other than mode bits to determine executability. -cat conf$$.file _ASEOF +cat conf$$.file FOOEOF #! /bin/sh exit 0 -_ASEOF +FOOEOF chmod +x conf$$.file if test -x conf$$.file /dev/null 21; then as_executable_p=test -x I'm not sure why this should make things work. I had also tried doing a global s/_ASEOF/FOOEOF/ on configure and lib/m4sugar/m4sh.m4 (the only 2 files that contained the pattern _ASEOF). Tests passed. ... 277 tests behaved as expected. 9 tests were skipped. ... I'll be out of the office the 12th - 18th. I can do more testing when I return. -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: Autoconf 2.60a on UnixWare 7.1.4
On Sun, 10 Sep 2006, Paul Eggert wrote: Tim Rice [EMAIL PROTECTED] writes: I have no idea why SESEOF is there instead of _ASEOF It's probably some bug in the Unixware shell. You might be able to use the truss command to verify this. If we knew more about the bug, we might be able to work around it. http://uw714doc.sco.com/en/man/html.1/sh.1.html talks about /u95/bin/sh, whereas your traces show that you specified CONFIG_SHELL=/usr/bin/posix/sh. What's the difference? Does switching to /u95/bin/sh fix your problem? How about /bin/ksh? Which shell does 'configure' use by default, and why didn't that suffice? Actually /usr/bin/posix/sh is the default on UnixWare as of 2.60 Prior to 2.60 it used /bin/ksh I did not specify a CONFIG_SHELL on the configure command line. /usr/bin/posix/sh is a symbolic link to /u96/bin/sh /bin/ksh is a symbolic link to /u95/bin/ksh /u95/bin/ksh and /u95/bin/sh are hard linked. Same problem with /bin/ksh -- Tim RiceMultitalents(707) 887-1469 [EMAIL PROTECTED]
Re: emacs Shell mode vs AC_CHECK_PROG(EMACS, ...)
I like to do my builds of almost anything from source under emacs Shell mode. But emacs Shell mode sets the environment variable EMACS to t. This causes the output of autoconf's AC_CHECK_PROG(EMACS, ...) to set EMACS=t, with the result that in any Makefile generated from EMACS = @EMACS@ in Makefile.in end up with the makefile variable EMACS set to t. One example where this is a problem is the current (Sept 10) CVS version of gnuplot. For a short-term correction, I think the easiest way is to change Autoconf to ignore a value of `t' for this environment variable. Autoconf maintainers, what do you think? For longer term, perhaps the best thing is to change Emacs to use a different environment variable. Alas, I don't remember what software checks that environment variable, or the motive for binding it. Is it Bash? I have cc'd the Bash maintainer so he can answer.
