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/
|\ _,,,---,,_ [EMAIL PROTECTED]
ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED]
|,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
