Mail Archives: cygwin-developers/2000/03/31/15:08:39
In an attempt to steer the whole "Mo" discussion back to the original
problem, here is what I intend to do. (I am not mad, nor am I upset. It may
just read that way.)
I am _not_ setting up a full Unix-style environment for this release. I was
told that the release would be "soon" and I see a lot of suggestions for
feature creep. If DJ or Chris want to authorize some serious changes to the
KISS philosophy that I was applying to the installer, then I will consider
it.
Did or did we not want to leave it up to the end-user to decide which
packages to install? Was I not told to save a more sophisticated installer
for a later date? As much as I would like to have MS-GINA replaced with xdm
and an inetd that is loaded before even logging on, I am taking the simplest
route I can find for now.
So, with that in mind, here is how I am going to attempt to correct the
out-of-environment-space issue. I will add a file to setup's resources. This
will be a preset shortcut that has the "Initial Environment" set at the
upper limit of 4096. I will copy it to the proper location on the machine
and then modify the paths and other settings in this shortcut. For now, it
will still call the same batch file that setup is creating. I used this
technique with success on the "Solutioner" project at work about 3 years
ago.
Now the rationale.
Why a preset shortcut? There is no API or COM Interface in Windows that
allows you to programmatically change this value. After much searching, I
even broke down and loaded the 1997 MSDN Library Archive to look at the
Program Manager DDEML interface, then I recalled doing this on the other
project.
Why not a setting in /etc/profile or similar? There are numerous ways a
shell may be started. Not all of them read the same initialization files and
there is no initialization file that bash reads under all cirumstances, I
checked the info file. Also this presents the chicken or the egg scenario,
the user must know the location of the shell file in the Windows file
system, because it is not in the path, and they must call it with the
--login switch to source /etc/profile, so that bash can set PATH. Yuck.
Why not modify autoexec.bat or the NT registry? There are a few reasons.
* It requires a system reboot. Who doesn't hate software installs that
make them reboot?
* It is very difficult to uninstall properly and fully.
* There is an issue with Windows find program versus /usr/bin/find.
Don't laugh but batch file programmers tend to expect the brain-dead version
of find to be called. You can also bet that they would expect bash to call
/usr/bin/find.
* In NT the user would get the Cygwin tools when they call one from
the command prompt. This might be a problem if what they really wanted was
one of the NT POSIX subsystem programs <insert wretching sound effect>. ;^)
While it is not ideal, and nothing is, having a batch file that contains all
of the necessary changes provides a nice starting point for the user if they
want to alter the system environment or make changes to how bash is started.
Also, if they screw up their environment, they are responsible, not us. (Yes
I know we'll hear about it on the cygwin list.)
- Raw text -