live-build/scripts/build.sh

62 lines
1.5 KiB
Bash
Raw Permalink Normal View History

#!/bin/sh
## live-build(7) - System Build Scripts
## Copyright (C) 2016-2020 The Debian Live team
## Copyright (C) 2006-2015 Daniel Baumann <mail@daniel-baumann.ch>
##
## This program is free software: you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation, either version 3 of the License, or
## (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program. If not, see <http://www.gnu.org/licenses/>.
##
## The complete text of the GNU General Public License
## can be found in /usr/share/common-licenses/GPL-3 file.
set -e
move auto colouring decision ...from the `Set_config_defaults` function, to being done directly in `build.sh` (the component which is also responsible for loading functions, loaded at the start of every script, including the front end). thus the colouring decision will now correctly... - apply to the frontend, such as to the 'root privileges needed' error, the 'no such script' error, and the command name colouring that I want to add (the most significant issue). - apply to error messages generated by the `Arguments` and `Read_conffiles` functions, which are called before `Set_config_defaults` by scripts. as things were, due to the comparison with "false", colour would _always_ be used in these places (unless _COLOR_ERR=false or _COLOR_OUT=false wrt. the new command highlight, were set in the environment when executing a script throught the frontend). this would not be a problem for normal terminal use of course, besides being inconsistent where color were turned off, but would be a bit of a problem if redirected to a file. a re-evaluation of _COLOR is performed in `Set_config_defaults` to adjust _COLOR_OUT and _COLOR_ERR where necessary, to correctly respond to _COLOR being set in saved config files (disabled by default but a user could always enable), after the point of config files being loaded. _COLOR can still be controlled from the environment just as before, overriding both _COLOR_OUT and _COLOR_ERR. note that this does not address the fact that --color|--no-color do not work in the frontend and thus will not impact the colouring of to-be-introduced command highlighting. this needs to be addressed separately. Gbp-Dch: Short
2020-03-18 00:28:58 -01:00
if [ -z "${_COLOR}" ]; then
_COLOR="auto"
_COLOR_OUT="true"
_COLOR_ERR="true"
if [ ! -t 1 ]; then
_COLOR_OUT="false"
fi
if [ ! -t 2 ]; then
_COLOR_ERR="false"
fi
else
_COLOR_OUT="${_COLOR}"
_COLOR_ERR="${_COLOR}"
fi
if [ -e local/live-build ]
then
LIVE_BUILD="${LIVE_BUILD:-${PWD}/local/live-build}"
export LIVE_BUILD
fi
for _DIRECTORY in "${LIVE_BUILD}/functions" /usr/share/live/build/functions
do
if [ -e "${_DIRECTORY}" ]
then
for _FILE in "${_DIRECTORY}"/*.sh
do
if [ -e "${_FILE}" ]
then
. "${_FILE}"
fi
done
break
fi
done