On Fri, 2004-09-03 at 08:10, Nicholas Jones wrote: > functions.sh (from baselayout) dependence needs to go away. > All used functions need to be logged/rewritten to not use those > functions, and instead maintain its own. I propose overriding einfo/... after sourcing functions.sh in ebuild.sh. > All said functions must be rewritten, for portage, with the > capability to handle colors and terminals and the like as > portage does currently. (People don't want ANSI in their logs.) Logfiles are handled seperately while screen output uses ANSI. If portage could relay the color decision onwards to bash, it would take only a small change to enforce that. > ${T}/notices.${PF}.${TYPE} I'd rather use a single file - notices.${PF} as the code shows: (should be inserted in ebuild.sh after functions.sh is sourced) ### Code start ### einfo() { enotice info "${*}" } ewarn() { enotice warn "${*}" } eerror() { enotice error "${*}" } enotice() { local color local type type="${1}" case "${type}" in "info") color="${GOOD}" ;; "warn") color="${WARN}" ;; "error") color="${BAD}" ;; esac shift echo "[${type}] ${*}" >> ${T}/notices.${PF} echo " ${color}*${NORMAL} ${*}" } ### Code End ### You can also merge the notice file into the package inself: (inside dyn_install, just after calling src_install) #enotice if [ -n ${PORT_ENOTICE_DIR} && -r ${T}/notices.${PF} ] then install -d ${D}${PORT_ENOTICE_DIR} cp ${T}/notices.${PF} ${D}${PORT_ENOTICE_DIR} fi or any other way you think is best. If this is acceptable, I can write a matching notice reader. -- Eldad Zack Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93