Rich Simoes wrote, quoting me:
>> Well the advantage of option 4 is that it provides one standard script
>> invoking MSYS, whereas option 2 requires some other, user supplied
>> script with a non-standard name.
>> On the contrary, with option 4 I think: "I want to start MSYS, so I
>> invoke msys.bat, but I don't like some of the default options, so I
>> customise some configuration file, which may be a user supplied
>> script, which msys.bat will use to establish such customisations as I
>> require". To me, that seems a more logical, and linear scenario.
> One problem, two solutions. And there could be more solutions.
Not really. The option 2 approach relies on a wrapper script, which is
a part of MSYS; it isn't inherently an MSYS solution, but it will *always*
remain an available option, for those who wish to exploit it.
OTOH, the option 4 approach provides a solution which is integral to MSYS
itself. It defines a configuration mechanism which inherently relates to
MSYS exclusively. In essence, it provides a method of local customisation
which is analogous to hacking msys.bat directly, but it does it in a
which MSYS recognises to be under the exclusive control of the end user;
therefore, it avoids any risk that MSYS itself would ever destroy the
>> Well, I can neither condone nor recommend arbitrary hacking within
>> I can't forbid you to do it, but you have only yourself to blame if you
>> subsequently destroy your configuration during a future upgrade or
> arbitrary??? - Ouch! By hard coding the command line options
> on the rxvt line, I can not change them in any other way
> unless I edit them in the "msys.bat" file.
Yes, arbitrary! You are making uncontrolled changes to a core system
in a manner which is entirely beyond the purview of the package
Since your changes are never fed back into CVS, they are necessarily
volatile, and will not survive an in-place upgrade or reinstallation.
I do agree, however, that those hard coded options, on the rxvt start up
command, need to be represented in a manner which will support external
configuration. Thanks for pointing this out.
>> OTOH, you *are* expected to configure /etc/fstab; this is how you tell
>> how *you* prefer to view your Windows filesystem in the pseudo-POSIX
>> filesystem space which MSYS provides, and the installer can't make
>> choices. This is entirely consistent with the manner in which
>> mount points are configured in a real POSIX system, and IIRC, this
>> configuration will *not* be overwritten during a subsequent MSYS
I neglected to mention that /etc/fstab is provided entirely for the end
convenience; you can run a basic MSYS installation without ever looking at
or indeed, without it even existing in the first place.
> Well, if the user can put the "custom.bat" file along side
> the "msys.bat" file, without a new MSYS deleting it, then
> you might have something there. At least you should know
> where to look for it if you have a conditional test within
This is exactly what I have in mind.
[concerning the use of environment variables to specify configuration]
>> I don't like this approach either. Since *all* normal Win32
>> variables are unconditionally exported, I have no way to set local
>> definitions in msys.bat, in a manner which will be portable to all
>> variants, without needlessly and unnecessarily polluting the MSYS shell
>> environment; IMHO, there's already way too much junk in there already,
>> from the standard Windows set up.
> That's why I have extra code in my $HOME/.profile.
> It's the only way to get rid of all that junk
> once it is set in Windows.
Earnie seems to favour just the use of environment variables, to provide
user configuration hooks. With all due respect to him, for without his
effort we would not have MSYS in the first place, I don't like the idea
of making such hooks a permanent feature of the Windows master
particularly when they relate to only one specific application. I accept
that environment variables may be necessary to provide the `glue' between
a user configuration file/script and the actual application, but I would
prefer to localise those application specific variables within the process
which launches the application; I just wish that Windows had provided a
suitable mechanism for me to select those which I want to export to
Maybe the distributed /etc/profile should include unset commands, to clean
up the environment mess resulting for the export of variables which should
be needed only within the start up context. Any thoughts?
[concerning the use of separate configuration files vs. msys.bat hacking]
>> Well, this is the way I would prefer to see things done; if you are too
>> to adopt such a configuration strategy, then again, you have only
>> blame if you come unstuck, as a result.
> lazy??? - Double ouch! It happens to be my personal
> preference [to hack e.g. msys.bat] when presented with multiple options.
> The lack of true User Data area for most of
> the life of Windows has made user customizations
> difficult. I actually prefer not to customize
> anything within an installed application tree.
> For my needs, I see no option available to get
> around modifying "fstab" and "msys.bat".
If you don't want to customise, then you should be happy to work with the
system defaults. As noted above, /etc/fstab is provided specifically to
support user customisation -- part of which is to specify *your* choice
of installation directory for MinGW, if you use it. OTOH, you really
should *not* be customising msys.bat to suit your own preferences; that
function properly belongs in some other configuration file, which is
specifically intended for user customisation. I accept that msys.bat
may need some modifications, which should be standardised within the
distributed package, to make it more amenable to such customisation.
It really shouldn't be any more difficult for you to edit a file which
is specifically provided for that purpose, than it is to hack a file
which you aren't supposed to modify. When you find that you need to
do this, that indicates a flaw in the core system. Ok, the accusation
of laziness may be unwarranted, sorry, but you could have submitted a
bug report, or better still, a patch.