This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Portable Cygwin on a CD


On Tue, 6 May 2003, Igor Pechtchanski wrote:
> On Tue, 6 May 2003 fergus@bonhard.uklinux.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]