From: "Tim Van Holder" To: Subject: RE: Robust shell-based test for DJGPP? Date: Tue, 2 Jan 2001 19:11:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id NAA05222 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > Example: > > AC_CONFIG_HEADER(foo.h:foo.hin) > > AC_CONFIG_FILES([po/Makefile.in:po/Make-in foo.spec:foospec.in) > > This is a different, even if related, issue. Are you saying that the > IFS=: etc. is used to parse these specs? Exactly! And that's why I don't want ot use ac_pathsep for this. If this was a purely internal thing, where configure built a colon-separated list, it would be trivial to use a different separator for DJGPP, but changing this would break automake and every single configure.in script that used a non-standard template (as done often for DJGPP ports (config.h:config.hin)). > > If the configure script made from this is called with --srcdir=d:/src > > (or if, as with emacs, the configure script forces srcdir to be > > absolute) > configure scripts should be called with --srcdir=/dev/d/src form of file > names, otherwise lots of other places in the configure script will fall > apart. Just the snippet discussed above, actually. > I don't think I understand what does Emacs add to this problem. Can you > elaborate? Emacs's configure forces srcdir to be absolute: == snippet from emacs 20.7's configure.in #### Make srcdir absolute, if it isn't already. It's important to #### avoid running the path through pwd unnecessary, since pwd can #### give you automounter prefixes, which can go away. We do all this #### so Emacs can find its files when run uninstalled. case "${srcdir}" in [[\\/]]* | [[a-zA-Z]]:[[\\/]]* ) ;; . ) ## We may be able to use the $PWD environment variable to make this ## absolute. But sometimes PWD is inaccurate. ## Make sure CDPATH doesn't affect cd (in case PWD is relative). unset CDPATH if test "${PWD}" != "" && test "`(cd ${PWD} ; sh -c pwd)`" = "`pwd`" ; then srcdir="$PWD" else srcdir="`(cd ${srcdir}; pwd)`" fi ;; * ) srcdir="`(cd ${srcdir}; pwd)`" ;; esac == end of snippet > > Note that there is another valid reason to use dtou, besides Unix > > compatibility of the output. In many case, makefiles and/or will use > > 'cmp' to compare file to decide whether some command needs to be run. > In most of the cases where `cmp' is used, you need utod, not dtou. I > find it hard or impossible to know in advance whether you should do one > or the other, or nothing at all, to get the results the maintainers had > in mind. There are also the cases where `cm' should simply be replaced > with `diff'. > > > It's not a Bash problem, it's a Linux kernel problem: it cannot grok > > > the magic "#!/bin/sh" signature if it ends in \r\n. Unlike in the > > > DJGPP port, on Unix the kernel interprets #!/bin/sh and invokes Bash. > > Maybe, but the problems I'm referring to come when running 'sh > > ./configure' and the like, so the kernel doesn't have to do any > > grokking. > I think you are wrong: what Bash does in this case is still make the > EXEC system call, and the kernel gets to decide how to run the script. You may be right - but if the kernel doesn't grok the #!/bin/sh, it should barf pretty quickly, and as far as I recall, most of the script got executed without errors (which is not to say nothing went wrong). I'll try to do a few tests this week. But even if it is a kernel issue, the dtou would have prevented it :-) > Did you try to make the dtou call part of the "trap ..." group? I think > you can catch normal exits with `trap', can't you? I suppose I could, but I'm not sure whether the file will have been closed at that point. I'll give it a try.