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: Upload: bash-3.0-4 [test]


On Tue, 5 Jul 2005, Eric Blake wrote:

> > In theory.  I'm just wondering if your script is safe enough.
> >
> >   test -x /bin/sh.exe || link /bin/bash.exe /bin/sh.exe
> >
> > The point is, if somebody wants to upgrade bash but not ash for
> > whatever reason ("Gee, *nobody* needs ash, right?"), this person
> > will get stuck with ash as sh. without noticing.  So, well, why
> > not forcing users to have sh == bash, *if* bash is installed?
>
> My intent was to allow someone (presumably only those with more
> experience would attempt this) to replace /bin/sh with ksh or zsh, to
> match their preferences.  After all, just because Linux has /bin/sh as
> bash doesn't mean that other systems do, and IIRC, MacOS prefers
> zsh as /bin/sh.

Right.

> Would adding a dependency on bash to ash help?  Then again, if
> someone is stupid enough to deselect ash (since it is part of Base)
> when doing their upgrade, then adding a bash dependency on ash
> won't do any good.  It seems like it would be nice if dependency
> tracking could allow a package to require a minimum version of the
> packages it depends on.

Well, the newer setup versions (snapshots) will warn if dependencies are
unselected.

> At any rate, you are probably right that a postinstall script may be
> all that is needed (no preremove script) if it ensures that /bin/sh
> always exists, and that if it is missing, is ash, or is an older version
> of bash, that it gets upgraded.  But I would still like to leave it alone
> if it does not fit those three categories.  How about this for the
> postinstalls?
>
> 00ash.sh:
>
> #!/bin/ash
> # If /bin/sh is missing or is ash, upgrade to bash.  If that fails, set
> # it to the latest ash (so that /bin/sh always exists after this script).
> case `(/bin/sh.exe --version) 2>&1` in
>     *not\ found* | GNU\ bash* | Illegal\ option\ --*)
>         ln -f /bin/bash.exe /bin/sh.exe || ln -f /bin/ash.exe /bin/sh.exe ;;
>     *) # User must have modified /bin/sh; leave it alone
>         ;;
> esac
>
> #!/bin/bash
> # If /bin/sh is missing, ash, or bash, upgrade it to the current bash.
> case `/bin/sh.exe --version 2>&1

FYI, this is missing a closing backtick and the "in".

>     *No\ such\ file* | GNU\ bash* | Illegal\ option\ --*)
>         ln -f /bin/bash.exe /bin/sh.exe ;;
>     *) # User must have modified /bin/sh; leave it alone
>         ;;
> esac
>
> Note that the two postinstalls are not quite interchangeable - missing
> files have different behaviors (in ash, you must run the check in a
> subshell to capture the "not found" error for parsing in the case
> statement, while in bash, running in the current shell captures the
> "No such file" error).  Furthermore, bash doesn't need a fallback,
> since /bin/bash must exist for the script to even be running.

This isn't good enough -- I think you do need a preremove script.  I've
been trying to figure out why the no-preremove solution seems wrong, and
came up with the following scenario: suppose bash is linked against an
older libreadline, and the user upgrades both bash and libreadline to
newer versions.  /bin/sh will be a copy of the old version of bash, but
after the upgrade it won't have the necessary DLLs.  So, running the
postinstall script (with "/bin/sh --version") will result in a "Can't
locate DLL" popup, which should be a no-no in a postinstall script.
	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


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