Mail Archives: cygwin-developers/2000/04/13/09:29:55
Ron, the env space problems I was running into on Win 95 have
gone away with the most recent installer.
Thanks.
Mo Dejong
Red Hat Inc.
On Fri, 31 Mar 2000, Parker, Ron wrote:
> 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 -