This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] Re: missing sh.exe in coreutils
- From: ericblake at comcast dot net (Eric Blake)
- To: cygwin-apps <cygwin-apps at cygwin dot com>
- Date: Mon, 15 Aug 2005 14:35:14 +0000
- Subject: Re: [PATCH] Re: missing sh.exe in coreutils
>
> Setup does support .bat files, and does support multiple postinstall
> scripts in a package. However, I just noticed something that will make
> life a lot easier - it sets the CYGWINROOT environment variable when
> running a script. This means that we should be able to just have a
> single .bat file containing
>
> @copy /y %CYGWINROOT$\bin\bash.exe %CYGWINROOT%\bin\sh.exe
>
> This needs testing, but it should work.
But it will obliterate /bin/sh if a user wanted it to be ksh or zsh. The
whole reason that 00bash.sh first checks what sh is currently, is
because I only want the upgrade to take place if it is ash or an
outdated bash, but to not penalize users who like ksh or zsh when
they call system() (Mac, for example, does sh == zsh, unlike Linux with
sh == bash). I'm really thinking more along the lines of:
@%CYGWINROOT%\bin\bash.exe -c %CYGWINROOT%\etc\profile.d\00bash.sh
The problem is that the user is free to remount /bin, /etc, or
/etc/profile.d, so that this naive .bat fails. The two-stage
(00bash.sh generates 01bash.bat) approach is starting to sound
more appealing as I think about it more. /bin/sh really is a special
case, since adding /usr/local/bin/sh will not affect system(); you
really have to replace /bin/sh.
--
Eric Blake