This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]