Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


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.