MSYS 1.0.12 Features

The major feature I would like to see added comes from a discussion with Eli Zaretskii of the GNU Make team. The idea disables the path translations and uses the paths as are. The caveat to this would be that the /bin, /etc/, etc directories must live in the root of the disk drive. I had created a working model months/years ago but didn't keep up with the changes to 1.0.11. I will create a patch file and upload it here (hopefully sometime in May 2009).

This wiki page is to be used for discussion of this idea. The idea does improve the performance of a package build since the path strings aren't manipulated. One reason I don't like this is because it provides the user with an option to change the behavior of MSYS with an environment variable. It will cause headache in trying to help a user. But the headaches with the non-technical shouldn't stop a good idea from being used by the technical.

Re: MSYS 1.0.12 Features

keith's picture

Sorry, but I am not in favour of this; at least, not in the form it has been previously discussed.

I agree that there is a need to do something, but if I'm understanding you correctly, you propose implementing some sort of environment variable hook, which will switch path name translation ON or OFF globally? IMO, that simply will not cut the mustard. If path name translation is globally OFF, then MSYS will be emasculated, becoming nothing more than a limited clone of an obsolete version of Cygwin; might just as well ditch it, and use current Cygwin instead.

For me, the principal reason to choose MSYS over Cygwin is the automatic path name translation feature. Take that away, and MSYS is dead; I will use Cygwin instead. (Except, of course, that you make it optional, so I keep the path translation turned ON, and entirely ignore whatever effort you invest in providing the option).

No, we do not need a global method of disabling path name translation. What we do need, is a method of exempting individual argument strings from consideration for translation. IIRC, this issue was first raised during a discussion on building emacs: within the standard POSIX platform build process, (which is what we expect to use with MSYS), there was one command in one makefile, which had one argument requiring exemption from path name translation. In the same command, there were three or four arguments which were POSIX style path names, and they did need translation. Turn translation OFF, globally, to leave the one troublesome argument untranslated, and the build remains just as broken, because the three or four that did need translation now aren't; you've gained nothing.

By all means, provide a global ON/OFF switch as a placebo to those who think it might be useful; (at least they will then have the opportunity to verify for themselves, that it perhaps isn't as useful as they thought it would be). However, if you do this, please do it as an adjunct to a much more useful change: add support for some argument specific flag -- perhaps an argument prefix string, and perhaps even itself defined as an environment variable -- which changes the translation behaviour for the associated argument alone, such that the flag is removed at translation time, leaving the remaining argument string otherwise untouched.

Re: MSYS 1.0.12 Features

This would be very good as an install option, also it would be good to have the /usr == / optional as well at install time.

Re: MSYS 1.0.12 Features

keith's picture

Why do you want to break the loop back mount association between /usr and /? IIRC, that was originally implemented to accommodate scripts which explicitly expected common tools in /usr/bin, (not uncommon on *nix systems), alongside those explicitly expecting them in /bin, (equally common). I can see untold potential damage, as a consequence of breaking this association; I'm having a hard time visualising any potential advantage which might accrue.

Where I can see a potential benefit, is in moving /usr/local outside of the MSYS tree, but you can do that already with MSYS-1.0.11, (and likely earlier as well); indeed, this is how I set my system up, as a matter of course:

$ uname -orv
1.0.11(0.46/3/2) 2009-01-29 00:39 Msys

$ mount | grep local
D:\usr\local on /usr/local type user (binmode)

$ ls /local
ls: /local: No such file or directory

$ ls /usr/local
bin  etc  include  info  insight  lib  man  sandbox  sbin  share  vim

Re: MSYS 1.0.12 Features

earnie's picture

Since the option would do zero mounts then that option is automatic. For the ``typical installation we might look at allowing for a /usr mount point specified in /etc/fstab to override the automatic mount point.

Re: MSYS 1.0.12 Features

rodneymcname44's picture

I'm with Earnie on this one. Allowing a /usr mount point to override the automatic mount is a great idea.

- Rodney

Re: MSYS 1.0.12 Features

keith's picture

Can you explain why? In the past several years, I recall three, or maybe four, people asking for this. Notwithstanding that this represents an insignificant drop in the ocean, when compared to the total population of MSYS users, not one of those paltry few has offered any form of justification for the request; just because Joe Soap thinks it's a great idea doesn't make it so.

Personally, I think it is a rather bad idea, and yes, I am prepared to defend that point of view:--

  • I've already explained the primary reason why it is advantageous to preserve the association between / and /usr; break the association, and you have to maintain two parallel copies of the standard tools, (and, unlike on a POSIX system, you can't just symlink them, because MS-Windows in general, and MSYS in particular doesn't support symlinks).
  • On a standard POSIX system, (of which, let's face it, MSYS provides a minimal emulation for the purpose of providing a command line environment only), both / and /usr are reserved for the system; regular users have no business messing about with either their content, or their function. Please leave the system maintainers to determine how they are deployed. Users may mess around, to their hearts' content, within /usr/local, (which, as I've also explained in that previous reference, can already be easily separated from the / and /usr mount association), or better still, as it would be on a real POSIX system, within /home/$USERNAME, (because modification rights in /usr/local are also normally restricted to the superuser).
  • Give naive users an option which has potential to break their systems, and they are sure to do just that; result: an increased support burden, which I am unwilling to sustain.

IIRC, when this idea was first mooted, Earnie was opposed, but open-minded. I see no evidence here, to suggest he has changed his opinion; back then he said it could be offered as an option, just as he continues to say today, but that doesn't imply that it should. I too am willing to keep an open mind on the issue, provided it is just that: an option which isn't enabled by default. However, in the absence of a strong and rationally presented justification for doing otherwise, let's apply the KISS principle, and keep it as it is now -- simple and standard.

Site Status

Site maintenance completed May 25th, 2012 at 12:38 UTC