manuel
/
live-build
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
live-build/functions/echo.sh

91 lines
1.4 KiB
Bash
Raw Permalink Normal View History

Adding live-helper 1.0~a4-1.
2007-09-23 08:04:49 +00:00
#!/bin/sh
Updating copyright headers for live-build.
2010-09-02 11:12:37 +00:00
## live-build(7) - System Build Scripts
amend copyright & licensing blocks Current versions of the project files are built upon versions published and licensed by Daniel Baumann, but are modified copies of those files and thus need to be marked as such per licensing requirements (afaik he did not pass along ownership / licensing rights to anyone when he left the project). We should also be careful to not be misrepresenting such modified copies as being attributed to Daniel. Adding a new copyright line referring to "The Debian Live team" should suffice for this. The authorship block in man pages has also similarly been updated. Notes: - tweaked a copy of daniel copyright lines stating 2014 instead of 2015. both of these cases were in files that i had personally introduced in some of my past merged commits that moved some code around. i don't know why they stated 2014. - binary_onie was introduced in 2018, so that has a 2018 date instead of 2016 unlike the rest. - 'efi-image' is a 3rd-party (Canonical Ltd) work that we bundle, but it has been modified by 674794a8f4d61a729d2dbd6d99385d2826138694 and 36a3ba76347ef72df1c316312ed3a26aa4b0c816 so I similarly added a debian live copyright line. - 'grub-cpmodules' is similar. it was only changed by the indentation fix of 36a3ba76347ef72df1c316312ed3a26aa4b0c816 but modification is modification, and this does help cover any possible future changes that might be made.
2020-03-11 09:07:21 -01:00
## Copyright (C) 2016-2020 The Debian Live team
Updating year in copyright notices to 2015.
2015-01-04 18:05:39 -01:00
## Copyright (C) 2006-2015 Daniel Baumann <mail@daniel-baumann.ch>
Updating copyright headers for live-build.
2010-09-02 11:12:37 +00:00
##
Updating GPL standard header in all files.
2012-07-29 23:59:00 +00:00
## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
Updating copyright headers for live-build.
2010-09-02 11:12:37 +00:00
## This is free software, and you are welcome to redistribute it
## under certain conditions; see COPYING for details.
echo: really ensure log messages go to stdout all echo helpers are used as logging functions with output to go to the terminal. when used in functions that are designed to return a string though the message printed would get incorrectly captured. the previous fix done in e3a987d977aaa417afe74349fa4d97dd6afc1c94 was stupidly flawed; somehow my testing led me to mistakenly believe that was adequate, but retesting proves that it was not. here we create a new FD #3 linked to stdout to output the messages on, which testing shows works as I had actually intended it. e.g. here: ``` Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; } ``` we get: ``` ~$ Foo a foo ~$ Foo b error ~$ XX="$(Foo a)" ~$ echo "${XX}" foo ~$ XX="$(Foo b)" ~$ echo "${XX}" error ``` and as demonstrated, "error" got incorrectly captured by in the variable whereas here: ``` exec 3>&1 Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; } ``` it is different in the last case: ``` ~$ XX="$(Foo b)" error ~$ echo "${XX}" ``` the error successfully makes it to the terminal, and the variable is an empty string (with a newline automatically printed). Gbp-Dch: Short
2020-03-07 01:33:08 -01:00
exec 3>&1
Adding live-helper 1.0~a4-1.
2007-09-23 08:04:49 +00:00
Adding generic echo function.
2008-08-14 18:25:29 +00:00
Echo ()
{
use local scope for private function vars all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short
2020-02-20 05:58:11 -01:00
local STRING="${1}"
Adding generic echo function.
2008-08-14 18:25:29 +00:00
shift
echo: really ensure log messages go to stdout all echo helpers are used as logging functions with output to go to the terminal. when used in functions that are designed to return a string though the message printed would get incorrectly captured. the previous fix done in e3a987d977aaa417afe74349fa4d97dd6afc1c94 was stupidly flawed; somehow my testing led me to mistakenly believe that was adequate, but retesting proves that it was not. here we create a new FD #3 linked to stdout to output the messages on, which testing shows works as I had actually intended it. e.g. here: ``` Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; } ``` we get: ``` ~$ Foo a foo ~$ Foo b error ~$ XX="$(Foo a)" ~$ echo "${XX}" foo ~$ XX="$(Foo b)" ~$ echo "${XX}" error ``` and as demonstrated, "error" got incorrectly captured by in the variable whereas here: ``` exec 3>&1 Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; } ``` it is different in the last case: ``` ~$ XX="$(Foo b)" error ~$ echo "${XX}" ``` the error successfully makes it to the terminal, and the variable is an empty string (with a newline automatically printed). Gbp-Dch: Short
2020-03-07 01:33:08 -01:00
printf "${STRING}\n" "${@}" >&3
Adding generic echo function.
2008-08-14 18:25:29 +00:00
}
Adding live-helper 1.0~a4-1.
2007-09-23 08:04:49 +00:00
Echo_debug ()
{
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
if [ "${_DEBUG}" = "true" ]; then
use local scope for private function vars all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short
2020-02-20 05:58:11 -01:00
local STRING="${1}"
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
shift
echo: really ensure log messages go to stdout all echo helpers are used as logging functions with output to go to the terminal. when used in functions that are designed to return a string though the message printed would get incorrectly captured. the previous fix done in e3a987d977aaa417afe74349fa4d97dd6afc1c94 was stupidly flawed; somehow my testing led me to mistakenly believe that was adequate, but retesting proves that it was not. here we create a new FD #3 linked to stdout to output the messages on, which testing shows works as I had actually intended it. e.g. here: ``` Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; } ``` we get: ``` ~$ Foo a foo ~$ Foo b error ~$ XX="$(Foo a)" ~$ echo "${XX}" foo ~$ XX="$(Foo b)" ~$ echo "${XX}" error ``` and as demonstrated, "error" got incorrectly captured by in the variable whereas here: ``` exec 3>&1 Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; } ``` it is different in the last case: ``` ~$ XX="$(Foo b)" error ~$ echo "${XX}" ``` the error successfully makes it to the terminal, and the variable is an empty string (with a newline automatically printed). Gbp-Dch: Short
2020-03-07 01:33:08 -01:00
printf "D: ${STRING}\n" "${@}" >&3
Adding live-helper 1.0~a4-1.
2007-09-23 08:04:49 +00:00
fi
}
Echo_error ()
{
use local scope for private function vars all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short
2020-02-20 05:58:11 -01:00
local STRING="${1}"
Adding last modifications in order to have localization fully working in live-helper. This commit goes with some pt_BR translations just for testing. Thanks to Antonio Terceiro for helping and coding in some shell stuff.
2008-08-11 20:28:54 +00:00
shift
Adding live-helper 1.0~a7-1.
2007-09-23 08:04:51 +00:00
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
local PREFIX="${RED}E${NO_COLOR}"
split stdout & stderr auto colouring thus for some reason if one is connected to a tty and the other a file, we still get colour in the tty by default. in terms of options, --color and --no-color override both, no granular ones added since it's not worth it imo. this is backwards compatible with custom configs setting `_COLOR`. it could be argued that setting $_COLOR to "false" for the auto non-tty cases is redundant, which it is, but it doesn't hurt to do so; it ensures that if anything (inc. 3rd-party hooks and such) rely on it that it remains correct; and ensures that if anything in the future mistakenly uses $_COLOR instead of $_COLOR_OUT|$_COLOR_ERR that at least that will only be broken for the use case of only one of stdout|sdterr being a tty. Gbp-Dch: Ignore
2020-03-13 17:36:26 -01:00
if [ "${_COLOR_ERR}" = "false" ]; then
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
PREFIX="E"
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
fi
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
printf "${PREFIX}: ${STRING}\n" "${@}" >&2
Adding live-helper 1.0~a4-1.
2007-09-23 08:04:49 +00:00
}
Echo_message ()
{
For consistency, using true|false instead of enabled|disabled in configuration options.
2009-12-13 19:17:45 -01:00
if [ "${_QUIET}" != "true" ]
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
then
use local scope for private function vars all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short
2020-02-20 05:58:11 -01:00
local STRING="${1}"
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
shift
Adding live-helper 1.0~a7-1.
2007-09-23 08:04:51 +00:00
fix colouring of notice type message prefixes previously this was white+bold. the white aspect was dropped since this would not be sensible for users with a white background for their terminal. bold however does not have any effect for me at least so effectively there is no highlighting at all. here we reintroduce a colour, one that will work for both black and white backgrounds of course. purple looks good to me - significantly different to that used for errors and warnings, and works well with command highlighting (as enabled separately).
2020-03-11 21:05:27 -01:00
local PREFIX="${PURPLE}P${NO_COLOR}"
split stdout & stderr auto colouring thus for some reason if one is connected to a tty and the other a file, we still get colour in the tty by default. in terms of options, --color and --no-color override both, no granular ones added since it's not worth it imo. this is backwards compatible with custom configs setting `_COLOR`. it could be argued that setting $_COLOR to "false" for the auto non-tty cases is redundant, which it is, but it doesn't hurt to do so; it ensures that if anything (inc. 3rd-party hooks and such) rely on it that it remains correct; and ensures that if anything in the future mistakenly uses $_COLOR instead of $_COLOR_OUT|$_COLOR_ERR that at least that will only be broken for the use case of only one of stdout|sdterr being a tty. Gbp-Dch: Ignore
2020-03-13 17:36:26 -01:00
if [ "${_COLOR_OUT}" = "false" ]; then
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
PREFIX="P"
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
fi
echo: really ensure log messages go to stdout all echo helpers are used as logging functions with output to go to the terminal. when used in functions that are designed to return a string though the message printed would get incorrectly captured. the previous fix done in e3a987d977aaa417afe74349fa4d97dd6afc1c94 was stupidly flawed; somehow my testing led me to mistakenly believe that was adequate, but retesting proves that it was not. here we create a new FD #3 linked to stdout to output the messages on, which testing shows works as I had actually intended it. e.g. here: ``` Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; } ``` we get: ``` ~$ Foo a foo ~$ Foo b error ~$ XX="$(Foo a)" ~$ echo "${XX}" foo ~$ XX="$(Foo b)" ~$ echo "${XX}" error ``` and as demonstrated, "error" got incorrectly captured by in the variable whereas here: ``` exec 3>&1 Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; } ``` it is different in the last case: ``` ~$ XX="$(Foo b)" error ~$ echo "${XX}" ``` the error successfully makes it to the terminal, and the variable is an empty string (with a newline automatically printed). Gbp-Dch: Short
2020-03-07 01:33:08 -01:00
printf "${PREFIX}: ${STRING}\n" "${@}" >&3
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
fi
}
Adding live-helper 1.0~a4-1.
2007-09-23 08:04:49 +00:00
Echo_verbose ()
{
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
if [ "${_VERBOSE}" = "true" ]; then
use local scope for private function vars all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short
2020-02-20 05:58:11 -01:00
local STRING="${1}"
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
shift
echo: really ensure log messages go to stdout all echo helpers are used as logging functions with output to go to the terminal. when used in functions that are designed to return a string though the message printed would get incorrectly captured. the previous fix done in e3a987d977aaa417afe74349fa4d97dd6afc1c94 was stupidly flawed; somehow my testing led me to mistakenly believe that was adequate, but retesting proves that it was not. here we create a new FD #3 linked to stdout to output the messages on, which testing shows works as I had actually intended it. e.g. here: ``` Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; } ``` we get: ``` ~$ Foo a foo ~$ Foo b error ~$ XX="$(Foo a)" ~$ echo "${XX}" foo ~$ XX="$(Foo b)" ~$ echo "${XX}" error ``` and as demonstrated, "error" got incorrectly captured by in the variable whereas here: ``` exec 3>&1 Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; } ``` it is different in the last case: ``` ~$ XX="$(Foo b)" error ~$ echo "${XX}" ``` the error successfully makes it to the terminal, and the variable is an empty string (with a newline automatically printed). Gbp-Dch: Short
2020-03-07 01:33:08 -01:00
printf "I: ${STRING}\n" "${@}" >&3
Adding live-helper 1.0~a4-1.
2007-09-23 08:04:49 +00:00
fi
}
Echo_warning ()
{
use local scope for private function vars all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short
2020-02-20 05:58:11 -01:00
local STRING="${1}"
Adding last modifications in order to have localization fully working in live-helper. This commit goes with some pt_BR translations just for testing. Thanks to Antonio Terceiro for helping and coding in some shell stuff.
2008-08-11 20:28:54 +00:00
shift
Adding live-helper 1.0~a7-1.
2007-09-23 08:04:51 +00:00
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
local PREFIX="${YELLOW}W${NO_COLOR}"
split stdout & stderr auto colouring thus for some reason if one is connected to a tty and the other a file, we still get colour in the tty by default. in terms of options, --color and --no-color override both, no granular ones added since it's not worth it imo. this is backwards compatible with custom configs setting `_COLOR`. it could be argued that setting $_COLOR to "false" for the auto non-tty cases is redundant, which it is, but it doesn't hurt to do so; it ensures that if anything (inc. 3rd-party hooks and such) rely on it that it remains correct; and ensures that if anything in the future mistakenly uses $_COLOR instead of $_COLOR_OUT|$_COLOR_ERR that at least that will only be broken for the use case of only one of stdout|sdterr being a tty. Gbp-Dch: Ignore
2020-03-13 17:36:26 -01:00
if [ "${_COLOR_ERR}" = "false" ]; then
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
PREFIX="W"
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
fi
echo: tidy Gbp-Dch: Ignore
2020-03-01 02:49:57 -01:00
printf "${PREFIX}: ${STRING}\n" "${@}" >&2
Adding live-helper 1.0~a4-1.
2007-09-23 08:04:49 +00:00
}
Add Echo_breakage for messages preceeding often-breaking stages and use before {c,}debootstrap calls
2008-06-14 17:25:05 +00:00
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
Echo_file ()
{
use local scope for private function vars all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short
2020-02-20 05:58:11 -01:00
local LINE
echo: don't mangle backslashes for file printing
2020-03-07 04:57:15 -01:00
while read -r LINE
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
do
echo: really ensure log messages go to stdout all echo helpers are used as logging functions with output to go to the terminal. when used in functions that are designed to return a string though the message printed would get incorrectly captured. the previous fix done in e3a987d977aaa417afe74349fa4d97dd6afc1c94 was stupidly flawed; somehow my testing led me to mistakenly believe that was adequate, but retesting proves that it was not. here we create a new FD #3 linked to stdout to output the messages on, which testing shows works as I had actually intended it. e.g. here: ``` Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; } ``` we get: ``` ~$ Foo a foo ~$ Foo b error ~$ XX="$(Foo a)" ~$ echo "${XX}" foo ~$ XX="$(Foo b)" ~$ echo "${XX}" error ``` and as demonstrated, "error" got incorrectly captured by in the variable whereas here: ``` exec 3>&1 Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; } ``` it is different in the last case: ``` ~$ XX="$(Foo b)" error ~$ echo "${XX}" ``` the error successfully makes it to the terminal, and the variable is an empty string (with a newline automatically printed). Gbp-Dch: Short
2020-03-07 01:33:08 -01:00
echo "${1}: ${LINE}" >&3
Implementing colorful output (currently disabled by default, though).
2008-11-01 14:31:26 -01:00
done < "${1}"
}