My initial thought was to simply add a leading indicator to the vecho and vvecho to identify the level of verbosity/debugging. ( #42 )
But then you had to mention a concern with line length :-), which sent me down an entire rabbit warren of discovery...
I really should be ripping my CDs, but now I'm having some fun 'yak shaving.'
Much of this could be corrected prior to refactor, since consistent logging might make it easier to detect issues/gaps when the code is moved to your new architecture.
I can take a swipe at some cleanup, but if and only if it will help toward your refactor. The logging to the console is ugly, but it functions as it is.
Potential action items first, followed by rational, and some data.
If you think it would help, I would do the cleanup with the following priorities:
1) add the [V] and [D] to vecho and vvecho -- the initial thought. (Or [Verbose] and [Debug], in keeping with the general approach already established in the log() function. If the output is to be verbose, then not much need to be terse in the leading characters :-)
2) remove decho, and convert those calls to vvecho (along with changing the debug command line option to set EXTRAVERBOSE)
3) change any vecho or vvecho warnings to log warning
4) change some of the obvious echo output to log info - and some to log warning where the current call is echo "[WARNING] ..."
5) see if I have any other insights along the way....
Let me know how far down this path it makes sense to go, based on your follow-on plans.
If this makes sense, I'd probably break this into a pull requests focused on 1&2, then 3, then 4, to keep this in bite-size chunks.
In checking the max length of the various output strings, I started looking at all the various ways the code had been structured to accomplish console output: echo, log, vecho, vvecho, decho. It appears that there might have been incomplete efforts to migrate from echo=> log, and from decho => vecho/vvecho.
-
in addition to vvecho and vecho there is also a decho function (debug echo) that is only called two times
- presumably this predates the logic from EXTRAVERBOSE which feeds vvecho and vecho
-
there is a log function
- has handling to prepend the output with [ERROR], [WARNING] (both going to. stderr)
- or [INFO] going to stdout
- ERROR and WARNING are routinely invoked and INFO is only used 3 times
-
there is considerable inconsistency in the use of vecho and vvecho
- some feed stdout and some stderr on their invocation line, but why
- since both functions provide a redirect to FD 4,
- unless called with the term 'warning'
- this in turn invokes log() which prepends WARNING are redirects to stderr
- but if there are warnings, why would that be hidden unless running verbosely?
- which really doesn't make any difference, because of this call
exec 4>&1
- lots of 'historical' code that could be simplified.
-
echo is used for several different purposes, some of which can be ascertained programatically from a single line inspection, others can not.
- some of the echo commands feed stderr, rather than stdout on their invocation lines.
- some are redirects to a file (e.g. status), so are obviously not for console use.
- some are embedded in sections of code where echo will go to a file (e.g. abcde.mkcue), but that can't be determined from the individual line.
- some are fairly obvious queries for user interaction, rather than console logging.
My first cut trying to understand the scope of console logging - these greps give some idea as to the scope, but are not comprehensive - just a first pass approximation.
grep -P '[^v]vecho' abcde | grep -P -v '^\s*#' | grep -P -v '(\se' | grep -P -v '( >> | > )' | sed 's/^[[:space:]]//'
(73 lines, 39 of which are redirects to stderr) not counting the vecho ()
grep -P 'vvecho' abcde | grep -P -v '^\s*#' | grep -P -v '(\se' | grep -P -v '( >> | > )' | sed 's/^[[:space:]]//'
(13 lines, 5 of which are redirects to stderr) not counting the vvecho ()
grep -P 'decho' abcde
(2 invocations)
grep -P 'log ' abcde | grep -P -v '^\s*#' | grep -P -v '(\se' | grep -P -v '( >> | > )' | sed 's/^[[:space:]]//'
(43 error, 20 warning, and 3 are info)
grep -P '[^v]echo' abcde | grep -P -v '^\s*#' | grep -P -v '(\se' | grep -P -v '( >> | > )' | sed 's/^[[:space:]]//'
(197 times - but this is a mix of output to console for logging, output for interaction, and output to build cue-files or other non-console activity.)
My initial thought was to simply add a leading indicator to the vecho and vvecho to identify the level of verbosity/debugging. ( #42 )
But then you had to mention a concern with line length :-), which sent me down an entire rabbit warren of discovery...
I really should be ripping my CDs, but now I'm having some fun 'yak shaving.'
Much of this could be corrected prior to refactor, since consistent logging might make it easier to detect issues/gaps when the code is moved to your new architecture.
I can take a swipe at some cleanup, but if and only if it will help toward your refactor. The logging to the console is ugly, but it functions as it is.
Potential action items first, followed by rational, and some data.
If you think it would help, I would do the cleanup with the following priorities:
1) add the [V] and [D] to vecho and vvecho -- the initial thought. (Or [Verbose] and [Debug], in keeping with the general approach already established in the log() function. If the output is to be verbose, then not much need to be terse in the leading characters :-)
2) remove decho, and convert those calls to vvecho (along with changing the debug command line option to set EXTRAVERBOSE)
3) change any vecho or vvecho warnings to log warning
4) change some of the obvious echo output to
log info- and some tolog warningwhere the current call isecho "[WARNING] ..."5) see if I have any other insights along the way....
Let me know how far down this path it makes sense to go, based on your follow-on plans.
If this makes sense, I'd probably break this into a pull requests focused on 1&2, then 3, then 4, to keep this in bite-size chunks.
In checking the max length of the various output strings, I started looking at all the various ways the code had been structured to accomplish console output: echo, log, vecho, vvecho, decho. It appears that there might have been incomplete efforts to migrate from echo=> log, and from decho => vecho/vvecho.
in addition to vvecho and vecho there is also a decho function (debug echo) that is only called two times
there is a log function
there is considerable inconsistency in the use of vecho and vvecho
exec 4>&1echo is used for several different purposes, some of which can be ascertained programatically from a single line inspection, others can not.
My first cut trying to understand the scope of console logging - these greps give some idea as to the scope, but are not comprehensive - just a first pass approximation.
grep -P '[^v]vecho' abcde | grep -P -v '^\s*#' | grep -P -v '(\se' | grep -P -v '( >> | > )' | sed 's/^[[:space:]]//'
(73 lines, 39 of which are redirects to stderr) not counting the vecho ()
grep -P 'vvecho' abcde | grep -P -v '^\s*#' | grep -P -v '(\se' | grep -P -v '( >> | > )' | sed 's/^[[:space:]]//'
(13 lines, 5 of which are redirects to stderr) not counting the vvecho ()
grep -P 'decho' abcde
(2 invocations)
grep -P 'log ' abcde | grep -P -v '^\s*#' | grep -P -v '(\se' | grep -P -v '( >> | > )' | sed 's/^[[:space:]]//'
(43 error, 20 warning, and 3 are info)
grep -P '[^v]echo' abcde | grep -P -v '^\s*#' | grep -P -v '(\se' | grep -P -v '( >> | > )' | sed 's/^[[:space:]]//'
(197 times - but this is a mix of output to console for logging, output for interaction, and output to build cue-files or other non-console activity.)