bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #46007] texi2dvi Msys support


From: Vincent Belaïche
Subject: Re: [bug #46007] texi2dvi Msys support
Date: Fri, 25 Sep 2015 19:19:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt)


Le 24/09/2015 18:14, Eli Zaretskii a écrit :
>> Date: Thu, 24 Sep 2015 18:09:32 +0200
>> From: Patrice Dumas <address@hidden>
>> Cc: Vincent Belaïche <address@hidden>,
>>         address@hidden
>>
>>> MSYS is not bastard, it just wasn't meant to be used in this
>>> capacity.  If you need something like that, just use Cygwin instead.
>>
>> I personnally only use GNU/Linux, but I have colleagues who use MSYS
>> as a generic shell, in particular when they use a software that comes
>> with MSYS (grass, some python).  Other use Cygwin.  A disadvantage of
>> Cygwin is that it seems to be quite slow.
>
> There's always someone who likes to live dangerously, or is unaware of
> the subtle issues which might bite them.

No direct relationship to Texinfo, just chatting about MSYS and bash...

I must admit that I am that sort of someone, probably mostly out of
unawareness, if not mere ignorance, but also because it was too
tempting to use MSYS as I had already installed it on my machine for
building free SW. Like Patrice I had also heard of that Cygwin is big &
slow, but frankly speaking I cannot tell as I have just never used it.

Anyway, as long as you don't use absolute pathes and envvars, MSYS is
not that ``dangerous''. It was designed to be a build system, not a
general purpose shell, but it could become a jeep shell if bash had some
enhancements.

What I like in MSYS is the intention that contrary to djgpp you don't
have to do special programming in your script to be compatible to MSW,
ie the intention is that you should be able to do scripting exactly the
same in Linux & in MSYS/MSW, all the conversions being centralized in
MSYS, and, as opposed to Cygwin, with the benefit of a lightweight
system for you can reuse MSW native ports. In djgpp you need some
special care like setting some path_sep variable. However this MSYS
objective is missed due to some lacking feature, and in the end, like in
the case of texi2dvi, compatibility full with MSW requires more
tinkering with MSYS than that with djgpp. So in these cases the
objective/concept is missing its target.

Eli clarified that the problem is that 1) --- conversion of MSW envvars
(PATH only) from MSW style to Linux style when entering bash shell from
MSW, is not the exact converse of 2.1) --- conversion of MSYS envvars
from Linux style to MSW style when entering a native program subshell
launched from MSYS bash.

The reason why these two operations cannot be converse of each other is
that MSYS does not know the syntax of each envvars, so best effort
sometimes miss the target: that is probably why MSYS designers decided
to do only some of the conversions, like in (1) where only PATH is
converted, and, also for the same reason, conversion can be done only
with a generic algorithm that is good for 99% of cases but that does not
do the work properly in some few cases, like in 2.1) where
TEXINPUTS-like variables are erroneously stripped off from empty dirs
and tailing double slashes.

If there were some bash extension to restrict in some way the syntax of
some envvars or of some commands, then MSYS would have that missing
information which is needed to do all the conversion properly.

These declarations would be helpful not only for the MSYS case, but in
general for any *nixy platform they would allow if need be to activate
some strict mode where the envvar settings/command launching could be
error controlled for syntax by bash. Making a project portable accross
platforms *nix/MSW would then just consist in declaring at some point
this syntax information, there would not be any need to modify and make
hard to read/understand scripts, no need in texi2dvi to replace in many
places some of the `:' by $path_sep and set path_sep in the correct way
by detecting through a number of tricks what the underlying platform is,
you would just declare the envvar/commands syntax at some point (your
init file or the script itself) and the rest would be done for you by
the bash port. So, in the end there would be far less impact on scripts
like texi2dvi to get the compatibility.

        Vincent

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]