Builder for live images based on Debian
39dae8cdc7
...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 |
||
|---|---|---|
| data/debian-cd | ||
| debian | ||
| examples | ||
| frontend | ||
| functions | ||
| manpages | ||
| scripts | ||
| share | ||
| COPYING | ||
| Makefile | ||