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 tremendously... Brian -- 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/
