Mail Archives: cygwin/2003/05/07/08:36:46
On Tue, 6 May 2003, Igor Pechtchanski wrote:
> On Tue, 6 May 2003 fergus AT bonhard DOT uklinux DOT net wrote:
>
> > The contributions over the past few days have helped a lot to make things
> > clearer, and better. Thank you.
> >
> > 1. There was a suggestion that the CD might usefully start with a
> > autorun.inf file. I feel a bit nervy about this. Two reasons: a. if the host
> > machine has Cygwin available then I would be inclined first to investigate
> > using that version, as the platform for any application I might be
> > interested in running; b. and if the host machine may even be _running_
> > Cygwin at the time the CD is inserted, what would be the potential confusion
> > arising from an autorun script which would be something like "\bin\rxvt -e
> > /bin/bash --login -i" or whatever?
> >
> > So the way I've got things set up at the moment is rather meagre on the
> > automation. But it works (well, I think) as follows:
> >
> > 2. If the host machine does not have Cygwin, then insert the CD and
> >
> > Start -> Run -> f:\bin\rxvt {switches}-e /bin/bash --login -i
> > mount -bfu f:/ /
> > {do stuff}
> > umount -A
> > ^D
> >
> > 3. If the host machine does have Cygwin, then try starting it up, inserting
> > the CD, and
> >
> > cd f:/usr/local/
> > {do stuff}
> > ^D
> >
> > which might work well, or not ...
> >
> > 4. In my case (and maybe others) this doesn't work at all well because when
> > I attempt to {do stuff}, things are in the wrong place. So instead I start
> > the host version of Cygwin with the intention of immediately (though
> > temporarily) disabling it and utilising the CD-bound "local" resource as
> > follows:
> >
> > Start the host version of Cygwin
> > mount -m > a:/mount.tmp # or somewhere convenient
> > umount -A
> > {insert the CD}
> > f:/bin/mount -bfu f:/ /
> > {do stuff}
> > umount -A
> > f:/bin/bash a:/mount.tmp # to recover the host setup
> > ^D
> >
> > Personally I do not mind the explicit mount-ing and umount-ing, explicit
> > references to the CD driveletter f:, etc. Actually the thought of
> > irretrievably (or even retrievably) hosing the host Cygwin installation is
> > frightening enough to make this explicit rather mechanical approach
> > preferable to something automated, however elegant that approach would
> > undeniably be.
> >
> > Fergus
>
> Fergus,
>
> FYI, you don't have to run the host version of Cygwin mount; you might as
> well run the one on the CD. The rationale is that if there are host
> processes running, the host version of cygwin1.dll is loaded and you won't
> be able to hotswap your version in, and if there aren't any processes
> running, the mount from the CD can read the mount table just as well as
> the one on the host drive. So you can skip that step (hope this makes
> sense).
>
> So, the correct procedure seems to be the following:
>
> Run a Windows program (i.e., the one that doesn't use cygwin1.dll) to
> detect whether there is a cygwin installation on the system[*]. If there
> is Cygwin installed on the host, run the "ps -ef" from the host to make
> sure there are no Cygwin processes already running on the host (including
> services). If there are, you'll have to use the host Cygwin anyway,
> 'cause you can't have two versions of cygwin1.dll loaded at the same time.
>
> If there are no host Cygwin processes, you can run "mount -m" from the CD
> to save the host mounts, and, after you're done, run the saved batch file
> using mount from the CD (by changing directory to F:\bin before running
> the batch file). As pointed out by Sam Edge, you should also check that
> you aren't leaving any Cygwin processes behind before you run "umount
> -A"...
>
> Most of the above can be done by an autorun program.
> Igor
> [*] This looks like a good use of setup's functionality. Perhaps there
> could be a small helper tool distributed with setup sources that uses
> setup's capability of reading the mount points... I'll look into writing
> one in a month or so, unless someone beats me to it (*nudge*, *nudge*,
> *wink*, *wink*).
>
IMHO, you don't want to know whether Cygwin is installed or not - there's
no need to know. Just knowing whether there are Cygwin processes is
enough.
The tool would be cool for other reasons, though :)
rlc
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -