This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Upload: bash-3.0-3 [test]
Eric, please make sure your mailer respects the Reply-To: header -- I set
it for a reason. Also, <http://cygwin.com/acronyms/#PCYMTWLL>. Thanks.
On Sat, 2 Jul 2005, Eric Blake wrote:
> > This is supposing /bin/sh can only be "ash" or "bash". There may be
> > another /bin/sh implementation (e.g., zsh) that does support the
> > --version flag.
>
> Unless somebody uses a POSIX-compatible /bin/sh that is not one of the
> cygwin distributions, the installed shell is distinguishable (although
> its version is not always discernable):
>
> $ ash --version
> Illegal option --
> $ ksh --version
> ksh: ksh: --: unknown option
> $ pdksh --version
> pdksh: pdksh: --: unknown option
> $ zsh --version
> zsh 4.2.4 (i686-pc-cygwin)
> $ bash --version
> GNU bash, version 3.00.16(2)-release (i686-pc-cygwin)
> Copyright (C) 2004 Free Software Foundation, Inc.
> $
I agree, the point I was making that just testing for whether the shell
accepts the --version option isn't enough -- you need to also look at the
output (both stdout and stderr).
> > Actually, setup will unlink /bin/bash and then install a new /bin/bash
> > over it. Thus, /bin/sh won't be upgraded even on filesystems that
> > support hard links. So *it* is a showstopper of sorts...
> >
> > I'd suggest doing a binary compare on /bin/sh and /bin/bash in a
> > preremove script, and deleting /bin/sh if they are the same (as is
> > done with config files). This will work on both Win9x and NT-based
> > systems.
>
> OK. Currently, I named the postinstall 00bash.sh to ensure it runs
> first (since ! is legal in filenames and sorts before 0, should I change
> it to !!bash.sh?). I guess the corresponding thing would be as you
> suggest, and create a preremove named ~~bash.sh that removes /bin/sh iff
> it is identical to /bin/bash. I agree with your analysis that 3.0-3
> will not cleanly uninstall; I will have to make a 3.0-4 before moving
> bash out of test (but that can wait until I have an assurance that ash
> will be repackaged to move to /bin/ash). Meanwhile, it is still worth
> uploading 3.0-3 to try it out through setup.exe.
What we really need is have setup run postinstall/preremove scripts in
some dependence-driven order. Until then, the alphanumeric tricks should
suffice.
> > FWIW, there was talk about a "configure-shell" script that sets the
> > shell at the user's request. Given the recent discussion of the
> > alternatives package (and Buzz's executable wrappers instead of
> > symlinks) this sounds like an interesting thing to try.
>
> Is bash something that can/should be alternativized with the other
> sh-variants? What would I need to do to make it work cleanly?
I would guess that bash itself won't need to do anything special -- it's a
question of the alternatives package having reasonable defaults. Whatever
the case, whatever sets this up will need to run before other postinstall
scripts. It may even be worth it to get setup.exe to recognize and treat
the alternatives postinstall/preremove scripts specially.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT