Re: bug in texi2dvi, on Windows/Msys2 it cannot find tex

[Tomas Kalibera]

On 4/8/22 17:25, Gavin Smith wrote:
> On Fri, Apr 08, 2022 at 04:30:12PM +0200, Tomas Kalibera wrote:
> > I am not sure what is the correct name of it. I executed
> > C:\MinGW\msys\1.0\msys.bat to get the shell.
> > It uses : as path separator.
> >
> > > Have you found that running texi2dvi fails in such an environment, with
> > > my patch above?
> > Yes. It is because "uname" returns "MINGW32_NT-6.2".
> > The original version works because "MSYSTEM=$OSTYPE uname" returns
> > "msys_NT-6.2"
> I don't like the whole setting MSYSTEM via OSTYPE and then running uname
> process; it's far too fiddly and hard to understand.  People like myself
> have no idea what the MSYSTEM variable is supposed to be.
> Instead, I propose checking OSTYPE directly for msys, where uname
> doesn't give this information:
>
> diff --git a/util/texi2dvi b/util/texi2dvi
> index 1f42b41907..e5d0ffb4e2 100755
> --- a/util/texi2dvi
> +++ b/util/texi2dvi
> @@ -80,12 +80,9 @@ IFS="$space$tab$newline"
>   # directories in TEXINPUTS -- except for Cygwin and Msys, where COMSPEC
>   # might be inherited, but : is used.
>   
> -# In the case of Msys, uname returns a value derived from MSYSTEM, as
> -# MSYSTEM is user configurable, it is not so safe to use it to detect
> -# Msys. It is safer to use OSTYPE, this is why we set MSYSTEM to
> -# $OSTYPE before calling uname
>   if test -n "$COMSPEC$ComSpec" \
> -   && MSYSTEM=$OSTYPE uname | $EGREP -iv 'cygwin|msys' >/dev/null; then
> +   && uname | $EGREP -iv 'cygwin|msys' >/dev/null
> +   && test "$OSTYPE" != msys ; then
>     path_sep=";"
>   else
>     path_sep=":"
>
>
> How does that work?

Works for me on all those 3 systems (just needed to add \ at the end of 
the line after "/dev/null "). And checking OSTYPE against "msys" is a 
common pattern in Msys2 patches, so I assume it is correct for Msys2.

OSTYPE is "cygwin" for me on cygwin and "msys" on the other two. It 
would be tempting to ask whether we could be testing OSTYPE only, also 
for cygwin, but I don't know, maybe earlier some derived systems behaved 
differently and that is why the check was so complicated.

Tomas