Menu

Spaces in installation path philosophy

2015-02-28
2015-04-24
  • Philip Oakley

    Philip Oakley - 2015-02-28

    Hi,

    I see that one of the stated purposes of MSYS2 (https://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/) is that "MSYS2 makes every effort to interoperate with native Windows software as that is often a requirement for running and (by extension) building such software".

    However in the installation page there is the strong statement "you MUST use folder names that consist of only ascii characters and no spaces" which appears to contradict this good intention. In particular the 'no spaces' (rather than the non-ascii coding which could contain 00h bytes) does appear rather strong.

    Further down the "Contributing" page there is the discussion section for 'Filesystem namespaces' which implies that, with appropriate quoting and care such 'space in filenames' should work.

    Is there any expectation that the initial installation should be able to work for ascii-with-spaces paths?

    I'm happy that the 'no spaces' is an initial guidance to ensure a Firm Foundation policy that ensures that any development on top of MSYS2 doesn't have problems that are masked by gaps in the foundations.

    If there is a (long term maybe) hope that MSYS2 would be able to be installed on Windy Foundations using ascii-with-spaces, are there any specific areas that are already known concerns?

    I ask because I was looking at Msysgit, and it's support (in git/contrib/buildsystems) for Visual Studio, and the one remaining 'issue' (if it's that) is that msysgit has the same base path limitation, so that the initial install must be be to an ascii-no-spaces path, but once installed, one can rename the base path to an ascii-with-spaces path and the updated msvc-build script for creating the Visual Studio project works just fine (https://github.com/msysgit/git/pull/318).

    At it's core the install sticking point was the 'windres' Windows Resource tool from binutils (2.19.1), which couldn't handle spaces. I just wanted to check up on what general policy/philosophy the team had about the issue before I start looking down that rabbit hole

    Is there a long term hope that an installation should be possible at an ascii-with-spaces path?

    Philip

    PS Out of date link:: last para of the 'Filesystem namespaces' section has a link to https://github.com/Alexpux/path_convert which is no longer valid; can the link be updated to its new URL?

     
    • Ray Donnelly

      Ray Donnelly - 2015-02-28

      When I wrote "MSYS2 makes every effort to interoperate with native Windows software as that is often a requirement for running and (by extension) building such software", I was not referring to software outside of the MSYS2 software distribution. Such interoperation is far beyond our control and we should modify that text to specifically exclude this software. MSYS2 aims to provide a complete software environment (glaringly, we are missing web browsers and email clients).

      MSYS2 (the shell and core utils, not the distribution) was created for building native Windows software, generally Unix-y Open Source software. As such those build systems often do not work in the face of spaces in paths, see for example:

      http://savannah.gnu.org/bugs/?712
      http://qt-project.org/doc/qt-4.8/install-win.html

      We won't adopt or recommend bad practices, even if Windows has a history of encouraging them ("Program Files", the Windows registry, non-shared DLLs, hard to update software installation procedures), and allowing spaces in paths is bad practice, one that, thankfully even MS is dropping:

      http://social.technet.microsoft.com/wiki/contents/articles/6083.windows-xp-folders-and-locations-vs-windows-7-and-vista.aspx

      For many use cases of MSYS2, spaces will cause no problem, but we must take the cautious approach and recommend the most compatible option. If I see any bug report where the user has installed to a path with spaces, my first recommendation will be to try it in a path without and then get back to us if that doesn't help.

      Assuming you mean that you would like to install MSYS2 in "Program Files" I also recommend not installing MSYS2 into a path that already consumes so many characters. Unfortunately, lots of Windows software is built with PATH_MAX (260) character limitations, and Unix software can sometimes have quite long paths. C:\msys64 or C:\msys32 (or some other drive than C:) is my recommendation.

      The link to https://github.com/Alexpux/path_convert is correct and works for me.

      What is Windy Foundations?

       

      Last edit: Ray Donnelly 2015-02-28
  • Philip Oakley

    Philip Oakley - 2015-03-03

    Hi Ray, Thanks for getting back on this.

    I'm happy that other build systems that are not part of MSYS2 may not work, and that some never will because of their perspective on 'The Right Thing'.

    I was hoping that, within the general aims of the project (but lower priority), it should be possible to install MSYS2 at say "C:\My Msys2\", despite those issues you mention regarding PATH_MAX and an unhappiness that Windows user do use spaces in file names. The MS link lists their new paths relative to old (XP) paths, but still uses spaces in some filenames.

    I'm quite happy with the cautious approach you mentioned regarding the need for space related bugs to be isolated separately from real issues, and that those reporting bugs should first prove out the issue on C:\MSYS2\ to separate the wheat from the chaff.

    In my case I'm trying to resurrect MsysGit's ability to create and run the (Msys)Git project within Visual Studio, so that a few more folks from the Windows community might help if it's available on their 'favourite' tool (one can always hope). (See https://github.com/msysgit/git/pull/318). The one remaining potential 'issue' is if they have spaces in their base file path, where windres in binutils (on the current MsysGit) fails. I.e the net install of Msysgit to 'c:\My Git\' (note the space) installs Msys etc ok, but then fails when it tries to compile Git itself as part of their initial start-up profile, failing at the windows resource compile windres stage of the make file - so near, yet so far!

    It looks like Msysgit will be converting to MSYS2 very soon, so I thought it worthwhile asking about how the MSYS2 team would handle patch requests that 'fixed' spaces-in-install-path problems within MSYS2?

    -

    The link problem (I looked a little deeper as you said it worked for you) is that the link on the page includes the final period (.) within the URL, rather than having it as a separate full stop to end the sentence. I haven't checked if I have permissions to change the wiki page.

    The "Windy Foundations" was a mixed allusion to the 'gaps' (spaces) in filenames common on Windows that allows the wind to blow through and ventilate the foundations on which one's house is built. Having a name for the particular issue can help discussion (i.e. it's not about nulls nor windows 'special' characters, just the ability to have spaces in the (base) path/filenames)

    regards
    --
    Philip

     
  • David Macek

    David Macek - 2015-04-24

    Links on wiki fixed.

    As for the spaces issue, unfortunately people writing build scripts (and software in general) often forget about them, so there's a lot of such problems out there. It's useful to fix problems affecting users (for example if git had a problem working with a repository that's on a path with spaces), but I don't think there's much advantage to putting work into fixing space-related issues in developer stuff.