This is the mail archive of the
mailing list for the Cygwin project.
Re: Portable Cygwin on a CD
- From: Ronald Landheer-Cieslak <ronald at landheer dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 7 May 2003 17:50:15 +0200 (CEST)
- Subject: Re: Portable Cygwin on a CD
On Wed, 7 May 2003, Igor Pechtchanski wrote:
> Comments inline below...
> > On Tue, 6 May 2003 email@example.com wrote:
> > > 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?
> > As Setup knows whether Cygwin is installed or not, the autorun program
> > should find that out too (and possibly in the same way - this is all open
> > source software, so you can just reap the source ;)
> "Reaping the source" can take many forms. I'd prefer to have that program
> as part of setup's distribution (or, at least, part of its source tree),
> so they are always kept in lock-step.
Actually, the only reason you might want to know is to save the mount
table, so there's no real reason to reap code from Setup..
I just didn't get this far in my thinking when I wrote thos yet (and I
didn't re-read the message before sending it to find out)
> > [snip]
> > And if you do the same thing in an automated fashion? What does mount -m
> > say if there's no mount table?
> Nothing. You can still save the output and "run" it afterwards -- after
> all, an empty batch file will not do any harm.
Right, in that case there's no need to reap code from Setup..
> > As I see it, the steps to do are:
> > ? is Cygwin running?
> > + * bail out
> > * lock CD drive
> > ? does a mount table exist?
> > + * save it (or remember it)
> > \ * hose it
> > * install a new mount table
> > * run rxvt, bash or whatever
> > o ? is Cygwin still running
> > \ - * break loop
> > * hose the mount table
> > * restore the old mount table (if there was one)
> > * unlock the CD drive
> > But that would mean:
> > 1. developing a way to make sure Cygwin is either running, or it isn't.
> > Cygwin itself knows how to do this, so we can just reap it from there.
> > I think the easiest way to do this is to use Cygwin's shared memory
> > region - see if it's there.
> See if Cygwin's installed (has a mount table), and if so, run /bin/ps?
That would definitely be a cleaner way to do it :)
Perhaps also look for cygwin1.dll in the PATH, just to make sure (try a
LoadLibrary of cygwin, for example) - there may be cygwin apps around
without there being an actual installation..
..but in that case ps would still find them, so just running ps should be
If Cygwin is already running, and ps is on the CD next to cygwin1.dll,
will the one in memory be used, or will Windows try to load the one next
to ps? (I don't know all that much about Windows' runtime loader sematics)
If the former, the whole thing basically boils down to:
? is Cygwin running? (run ps)
+ * bail out
* lock CD drive
* save the mount table (mount -m)
* hose it (umount -A)
* install a new mount table (a couple of well-placed mount commands, using
argv as the drive)
* run rxvt, bash or whatever
o ? is Cygwin still running (ps)
\ - * break loop
* hose the mount table (umount -A)
* restore the old mount table (contents of output of mount -m)
* unlock the CD drive
which is more or less a blessed batch file.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html