More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty

Charles Wilson
Tue May 12 16:58:00 GMT 2009

Corinna Vinschen wrote:
>On May 12 09:51, Charles Wilson wrote:
>> 2009/05/11 14:55:58 running: C:\cygwin-1.7\bin\bash.exe -c
>> /etc/postinstall/
>> Huh?  No /etc/fstab file in \??\C:\cygwin-1.7\etc\fstab.d\cwilso11? 
>> Using default root and cygdrive prefix...
> See this message?  That means, at the time
> was called the Cygwin DLL didn't find an fstab file.

Sortof. Part of's JOB is to create that file
-- and it did so.  So the file exists for the rest of the postinstall
scripts. However, I wonder if there is a caching problem or something --
sure, it was created, but doesn't get used until the next time
cygwin1.dll is loaded into memory?

>> 2009/05/11 14:56:07 running: C:\cygwin-1.7\bin\bash.exe -c
>> /etc/postinstall/
> No such "Huh?" message anymore.  So at this point the /etc/fstab file
> already exists.

Sure, but there's still SOME issue with the mount path, because:

2009/05/11 14:56:37 running: C:\cygwin-1.7\bin\bash.exe -c
/etc/postinstall/ line 4: cd: /usr/bin: No such file or

Now, this is interesting.  /etc/postinstall/ looks like this:


cd ${bindir}

for prog in autoconf autoheader autom4te autoreconf autoscan autoupdate
	rm -f ${prog}
	ln -sfn ${wrapper} ${prog}

That's right: NO shebang line. (I don't remember deliberately ommitting
that. I'll check what's up with that when I get home).  I wonder if all
of the failing postinstall scripts have a similar "mistake", seems ok (except it is missing the usual space between '#!'
and '/bin/sh').  Also, the error is in a () subshell?

2009/05/11 14:56:28 running: C:\cygwin-1.7\bin\bash.exe -c
/etc/postinstall/ line 9: cd: /usr/lib: No such file or

# This script will create a symbolic link for old curses apps
# with a hardcoded TERMINFO search path. Also, ensure that all
# database files are readable.

(cd ${libdir} && rm -f terminfo && ln -fs ${terminfodir} terminfo)

for d in ${terminfodir}/* ; do
	if [ -d ${d} ]; then
		(cd $d && chmod 644 *)
		chmod 755 ${d}
chmod 755 ${terminfodir}

for f in ${prefix}/share/tabset/* ; do
	chmod 644 $f
chmod 755 ${prefix}/share/tabset

Hmmm...more thoughts, below...

>> /cygdrive/h/.bashrc
> But I don't get what this .bashrc pathname is doing here every time.

That's just my ~/.dotfiles being chatty.  However, I wonder if
postinstall scripts should read ~/.dotfiles at all.  When bash is used
as sh, it doesn't read ~/.stuff.  However, notwithstanding
above, many of my package's postinstall scripts make use of bashisms, so
I put /bin/bash in the #! line.  It's probably not a good idea for setup
itself to invoke the post/pre scripts using interpreter-specific flags
like -norc because some postinstall scripts might be in other
languages...Do we have a policy about this?  Should I use '#! /bin/bash
-norc' instead?

Back on topic: it's interesting, but the following "core" postinstalls
don't happen until after a number of other, failed, postinstalls. I
would have thought these needed to happen fairly early:

/etc/postinstall/ [*]

However, even after those two run, I still got postinstall failures
whenever any attempt to explicitly access /usr/bin or /usr/lib was made.
 However, as I said earlier, I think your proposed patch will avoid the
problems I saw...

[*] Should these be fixed, to avoid:

cygwin warning:
  MS-DOS style path detected: C:\WINDOWS\system32\drivers\etc
  Preferred POSIX equivalent is:
  CYGWIN environment variable option "nodosfilewarning" turns off this
  Consult the user's guide for more details about POSIX paths:
`/etc/hosts' -> `C:\\WINDOWS\\system32\\drivers\\etc\\hosts'
`/etc/protocols' -> `C:\\WINDOWS\\system32\\drivers\\etc\\protocol'
`/etc/services' -> `C:\\WINDOWS\\system32\\drivers\\etc\\services'
`/etc/networks' -> `C:\\WINDOWS\\system32\\drivers\\etc\\networks'

Or is using the win32 paths deliberate, because folks might change their
/cygdrive option?


More information about the Cygwin-developers mailing list