This is the mail archive of the
mailing list for the Cygwin project.
ash/bash postinstall dance [Was: Cygwin doesn't install on Windows Server 2008 (x64).]
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin at sourceware dot org
- Cc: cygwin-apps at cygwin dot com
- Date: Fri, 14 Mar 2008 22:56:24 -0700
- Subject: ash/bash postinstall dance [Was: Cygwin doesn't install on Windows Server 2008 (x64).]
- References: <E6F7A586E0A3F94D921755964F6BE00601674268@EXCHANGE2.cs.cornell.edu>
- Reply-to: cygwin at cygwin dot com
Krzysztof Ostrowski wrote:
> What is the purpose of "00ash.sh", and what kind of system calls does it
> attempt at making? Surely, it must be something very unusual because I've got
The strange thing about this is that 00ash should be totally superfluous
on a new system. And syscalls? It's a shell script, it's just invoking
programs, it doesn't really know waht a syscall is.
A bit of background: For a long time in the past /bin/sh was really ash
-- the ash package simply provided /bin/sh.exe, the bash package
provided /bin/bash.exe, and that was that. There was no confusion or
contention between the two.
Except that ash sucks. It's not actively maintained, it's sort of
buggy, not very POSIX compliant, and there are lots of shell scripts in
the wild that start with #!/bin/sh but use bash-specific features since
/bin/sh is bash on Linux. The reason for having ash as sh was because
at some point in the very distant past it had been determined that
because of ash's simplicity it was also faster than bash, which matters
for Cygwin because process creation is really slow.
We revisited this thinking a few years ago, sometime in mid 2005 I
think. We determined that the fact that bash had a lot more builtins
than ash compensated for any potential increase in complexity such that
it was not in fact slower. We decided to change the packaging so that
/bin/sh was bash. This was some time around mid-2005, so this is by far
not a new change.
Only we couldn't just stop providing ash as we needed a way of running
the rebaseall script, which attempts to re-layout the ImageBase of all
DLLs from Cygwin packages, which requires writing the new ImageBase to
the .dll, which requires it not be in use. But bash links dynamically
with libintl, libiconv, libreadline, and libcurses so those would be in
use if bash were running the rebaseall script. ash only links with the
Cygwin DLL so it is immune to this problem, so we decided to keep it
around for that purpose.
Under the new system, the ash package extracts /bin/ash.exe, the bash
package extracts /bin/bash.exe and no package extracts /bin/sh.exe.
That is handled between the ash and bash postinstall scripts. The
reason for doing this was to make the upgrade safer: you could in thoery
release a new ash that unpacks a /bin/ash.exe and a new bash package
that unpacks both a /bin/sh.exe and a /bin/bash.exe. However, this
leaves a potential route for the user having a broken system unless they
install both updates at the same time.
In the new system, the job of making sure there is a /bin/sh.exe (as
well as keeping it updated) is covered by the postinstalls: 00bash.sh
and 00ash.sh both try to ensure that if there is no /bin/sh.exe, or the
/bin/sh.exe that exists is ash, that bash.exe is copied to sh.exe. The
bash postinstall also does the copy if bash is newer than sh, so that
when bash is upgraded the copy will be updated. (Note that it would be
a lot easier to use a hard or soft link, but those won't work for
various other reasons.)
Anyway, the point of all this is that these postinstalls really only
have one function: make sure /bin/sh is correct. And since you're not
updating a system from 2005, you can simulate this entirely by "copy
c:\cygwin\bin\bash.exe c:\cygwin\bin\sh.exe" at a Command Prompt if for
any reason it is not working correctly.
That brings up an interesting, and I think valid question -- Why are we
still catering to systems that might be stuck in 2005 with an ash
/bin/sh? If we change the bash binary package to extract both /bin/sh
and /bin/bash (the setup program expands hard links in the tarball as
copies, so we can use a hard link there to save space) then that means
that we don't have to worry about copying anything to sh.exe anymore, it
will always be in sync with bash.exe. The ash postinstall could go away
entirely and the bash postinstall (and startup!) could be simplified
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html