Re: Fw: bug in texi2dvi, and hack patch

[Eli Zaretskii]

> Date: Wed, 19 Jan 2005 05:36:26 -0700
> From: Eric Blake <address@hidden>
> CC: address@hidden,  address@hidden
> 
> > If this is what Autoconf 2.59 really does (i.e., no typos etc. in this
> > snippet), then Autoconf 2.59 is broken, at least for DJGPP, because it
> > will always produce PATH_SEPARATOR=:.  This is because it invalidates
> > PATH, and therefore defeats the DJGPP magic that looks for sh.exe
> > along PATH if /bin/sh.exe does not exist.  (And /bin/sh.exe does not
> > exists on almost every DJGPP installation.)
> 
> If this is true about DJGPP, then autoconf needs to revisit how
> PATH_SEPARATOR is calculated.

It's true, and autoconf does need to revisit that.

(FWIW, I think this DJGPP feature is a very useful one: it lets shell
scripts and Makefile's that say "SHELL = /bin/sh" seamlessly run
unaltered without requiring that the user has a /bin/sh.exe file on
each drive, and without any need for Cygwin-style normalization of the
installation directory to `/'.)

> There is always the uname utility

Yes, but I hoped OSTYPE says something useful in the Cywin Bash.  Does
it?  If it does, we could avoid invoking `uname'.  If not, `uname' is
the way to go (its DJGPP port prints a string that contains "MS-DOS").

> >>Additionally, according to autoconf, `test -x' is not portable.
> > 
> > But needed for DJGPP/MinGW, where "test -f tex" does not find tex.exe,
> > but "test -x tex" does.
> > 
> > So if this is changed to not use "test -x", the non-Posix systems will
> > still need "test -x" (which is okay for those systems, since the
> > ported Bash supports "test -x").
> 
> CVS Autoconf also tackled this issue, see
> http://lists.gnu.org/archive/html/autoconf-patches/2004-12/msg00057.html

I don't see how it does.  Perhaps I'm missing something.

The problem is that on a typical DOS/Windows box, "test -f tex" will
simply fail, since there's no file named `tex'.  That's because the
TeX executable is called `tex.exe', but the script doesn't check
"test -f tex.exe".  Therefore, "test -x tex" was modified to check for
`tex.exe' if `tex' does not exist.

Unless I'm missing something, the above message from autoconf-patches
does not solve this problem, since "test -f tex && test -x tex" will
fail due to the absence of a file named literally `tex'.

> > Again, doing the latter (i.e. determining the location of TeX at
> > configure time) might be okay on Posix systems, but not on
> > DJGPP/MinGW, since it is _very_ customary on those systems to download
> > pre-compiled binaries, and thus configure-time settings are usually
> > invalid.  (Actually, I think Cygwin users will not like your
> > suggestion either, since AFAIK they, too, tend to download binaries.)
> > 
> 
> But on cygwin downloads, they tend to be to a normalized path (ie the
> cygwin installation point is normalized to /, all pre-compiled cygwin
> binaries are put in /bin, and /usr/bin is mounted to /bin), so even if the
> tex executable is downloaded to something as outrageous as 'q:\my
> hairy\windows\path\cygwin\bin', the precompiled binary still sees it at
> /usr/bin because of the PATH normalization going on.

I was thinking about a non-Cygwin TeX (e.g., fpTeX or TeXLive) being
installed.  However, if Cygwin users are told not to use non-Cygwin
ports of TeX, perhaps that problem does not exist for Cygwin users.
It is still a real issue for DJGPP/MinGW users, though.