Mail Archives: cygwin/2009/05/05/09:07:58
> That's very odd.
> Those files are created by the postinstall script,
> which is run by setup.exe in a "real" cygwin shell.
> That is, it's just a bash script that runs
> ..
> BUT, because it's in a bash shell, it OUGHT to know
> about all of the mount points, especially
> cygwin-1.7 (cat /etc/fstab): !!!!
> .. C:/cygwin-1.7 / some_fs binary 0 0
> .. C:/cygwin-1.7/bin /usr/bin some_fs binary 0 0
> .. C:/cygwin-1.7/lib /usr/lib some_fs binary 0 0
OK, thank you very much. Your account of what goes on reveals the cause
of the problem, which is local to *my machine* as you anticipated. (See
the line ending !!!!)
Running Cygwin [1.7] from a mobile drive whose driveletter might vary
from host to host or usage to usage, and which I won't necessarily know,
and don't want to have to find out, I do not have a /etc/fstab file.
Every instance of Cygwin is initiated by a Windows batch command file
that discovers the driveletter for itself and uses it to write a bespoke
/etc/fstab. Only then is the shell started. At the end of the session
the tailored file /etc/fstab is deleted.
(Cygwin [1.5] is also run from a mobile drive with the same requirement
to identify and utilise its driveletter at each usage. But for 1.5
mounts are handled differently and at updating this problem does not arise.)
In future I can precede [1.7] updates by using the same idea: run a
batch file to create /etc/fstab but which then runs setup.exe rather
than starting a shell.
Thank you very much. (This behaviour - mobile drive - is probably viewed
as eccentric minority behaviour requiring no special attention in
setup.exe, but I think I am not the only one using Cygwin in this way,
as very recent posts have shown.)
Fergus
--
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 -