In my opinion people should only write scripts for posix shells, but that'd be a huge development
i guess, so just using #!/usr/bin/env bash is fine, and make bash as a dependency if it is not
already.
On (2010-10-28 01:13), Tor Lillqvist wrote:
Should we change all the shell scripts that use bashisms on the "upper" level (from the "build"
repo) to start with #!/usr/bin/env bash ? Is that then (finally) a good and reliable solution to
the problem whether to use bash or not, and where bash is in case we do want to use it? Or is
there some system on which env is not in /usr/bin ? Or does it annoy somebody to have l shell
scripts first exec env and then bash, with a (very slight) slowdown?
Presumably we do require bash to be available in PATH (the "inner" build mechanism already does
that as far as I know), and can continue doing that. But what we cannot rely on is that bash
would be at /bin/bash, and even less that /bin/sh would be bash.
A somewhat related issue is, can we require that the interactive shell used by the developer is a
Bourne-style shell? Should we continue to generate the *Env.Set scriptlet for csh or is just the
*Env.Set.sh one for Bourne-style shells enough? Do *BSD-based developers often use some csh-style
shell as their interactive shell? At least on Linux I assume it is very rare.
--tml
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.