#425 msys.bat w/ CR+LF replacement

closed-fixed
msys (22)
2012-11-29
2009-09-08
iysil
No

MSYS.BAT is broken on Windows 9x platforms because it uses UNIX style
(LF) line endings, which is incompatible with MS-DOS - the environment
that batch (.BAT) files use under Windows 95/98/ME. When msys.bat is
invoked on these systems, it will return "Bad command or file name".

This solution, from the advice of Peter Hayward, is to save the file
with DOS-style CR/LF line endings. This corrects the situation under
win9x and should pose no problem on NT/2000/XP/Vista/7 systems.

I included the standard `patchfile.diff' , but I'm also including the actual,
modified `msys.bat' file too.

Discussion

  • iysil

    iysil - 2009-09-08

    msys.bat replacement w/ CR+LF pairs

     
  • Earnie Boyd

    Earnie Boyd - 2009-09-08

    I'm no longer working on MSYS. If it were me I would close as invalid and state that win9x is no longer supported.

     
  • Earnie Boyd

    Earnie Boyd - 2009-09-08
    • assigned_to: earnie --> cstrauss
     
  • iysil

    iysil - 2009-09-08

    That's ridiculous. Just because a business stops supporting a (mature) product to bring in more revenue and lower (support) expenses, doesn't mean that every developer in the world should follow suit - especially if the application can remain backward compatible with just a few lines of code submitted by someone else.

     
  • Cesar Strauss

    Cesar Strauss - 2009-09-09

    MSYS.BAT in MSYS-1.0.10 does have CR/LF line endings. It got LF line endings in 1.0.11 by some accident.
    I will correct this.

    Thanks,
    Cesar

     
  • Keith Marshall

    Keith Marshall - 2009-09-09

    > That's ridiculous...

    FWIW, *this* project administrator is inclined to agree, (although I do find your tone mildly offensive, both here and on the mailing list); it would seem that the current MSYS maintainer concurs.

    That MSYS-1.0.11 has been packaged with LF, rather than CRLF line endings in msys.bat is a packaging bug. It is trivially easy to correct, I see absolutely no reason why we shouldn't do so, and Cesar, the current maintainer has already agreed to address the issue. I've no idea why Earnie suggested we should do otherwise, on the grounds that you choose to use a dinosaur OS; perhaps he was having a bad day.

    Just for the record, msys.bat is stored in CVS with bare LF line endings. It has to be so, otherwise it may accumulate CR...CRCRLF endings on any checkout..commit cycle initiated from a *nix working host, (as I use). Windows CVS clients are *expected* to convert to CRLF on checkout, but the MSYS' CVS client doesn't do this -- something requiring care, (or unix2dos), when packaging.

     
  • iysil

    iysil - 2009-09-10

    >although I do find your tone mildly offensive, both here and on the mailing list

    I apologize. I definitely have a lot of frustration with these (win9x) issues. My feeling is that if a program (or collection of programs) can support a particular OS, and somebody is willing to provide that code, then there is no reason it shouldn't be. I guess I am learning the difference between "open source" and "open development" the hard way.

    If I have to, I'll fork MSYS - but I would rather submit patches here and there that maintain compatibility. Then I could move on to something really productive like actually documenting some of these nuances for users.

    I guess I was just looking for an educated answer (thanks cstrauss & keith), and the steam started to build when valid reports were closed without "due process". There are *millions* of computers out there that still run Windows 95/98/ME. The forums on www.annoyances.org and other sites are still crawling with win9x users to this day. From a Microsoft standpoint it does make a lot of business sense to obsolete an old OS, but from a developer, it makes none (unless it is absolutely necessary). I was able to recompile msys-1.0.dll so that bash/sh/rxvt now work properly under win9x by changing only *one line* of code.

    Anyway, I look at MinGW / MSYS as a great tool set for maximizing compatibility. Now there is a GCC for every 32/64-bit OS I can think of! To break compatibility over one line of code though... (i'll stop while i'm ahead)

    Can we get a forum open here on sourceforge for mingw/msys users so I don't have to rant & rave in the tracker =) I'm not a big fan of mail lists.

     
  • Earnie Boyd

    Earnie Boyd - 2009-09-10

    Let me apologizes and run to hide. I must have been venting from real job issues in the MinGW issue queue. I'll shut up, run and hide now. :$

     
  • Keith Marshall

    Keith Marshall - 2009-09-10

    > If I have to, I'll fork MSYS - but I would rather submit patches...

    I really hope that you will not feel a need to fork MSYS; I'm sure Cesar will be receptive to patches, provided you can base them on freely available documentary sources, or can demonstrate their utility through experimentation, using FLOSS tools only. However, please refrain from poisoning our trackers with text quoted verbatim from any Microsoft SDK, (as I believe you did, on another ticket); we don't consider these to be a legitimate source, and we reject patches from those who use them as basis.

    > Can we get a forum open here on sourceforge for mingw/msys users so I
    > don't have to rant & rave in the tracker =) I'm not a big fan of mail
    > lists.

    We tried that, at one time, and found it gravely unpopular -- the majority of our users didn't like notification of forum activity via the mailing list, inviting them to read the thread elsewhere, and expressed a strong preference for keeping all discussion on the mailing lists. We've gone through a phase of having too many of those; we now prefer to use just the MinGW-users list for everything. Going back to any nasty, disjointed forum, which few will monitor, isn't on our agenda.

     
  • Cesar Strauss

    Cesar Strauss - 2012-11-29

    Fixed in msys-core 1.0.18.

     
  • Cesar Strauss

    Cesar Strauss - 2012-11-29
    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks