prepended [Verbose] to vecho, and [Debug] to vvecho.

[pccasto]

added the prepended level information to help make better sense of the console output.

Simplified logic used to debug a single special case, and removed decho

This is the first pass to deal with issues 1 and 2 as described in #45.

decho was only used for one very niche debug case:
when setting the command line option -z to enable CDROMREADERSYNTAX=debug
simplified the logic and eliminated (commented out) the unneeded decho() function.
Not a complete solution as it does an echo [DEBUG], but that can later be turned into log debug if/when the log function is expanded to handle that case. -- a POSSIBLE way of handling the output in a more controlled fashion... but that might also need a local override of the EXTRAVERBOSE variable to ensure the output.

I think this might be a reasonable first pass.

[poddmo]

I haven't tested it yet but this commit looks ok to me. I'd be more inclined to remove deprecated code rather than commenting it. Once I test it (maybe not today) I will take this.

[poddmo]

I tested this patch:

• I really like the prepended text to identify the verbose level that generated it. [Verbose] is fine but [Debug] is not consistent with abcde's existing "debug" modes (ie -D and -z). [Verbose2] would be more accurate.
• decho changes need to be moved to a separate patch. The decho function redirects FD4 and the new patch removes that - I've had hours of pain because I strayed from the existing file descriptor template/maze. This change also only seems to be functional on the PIPE branch and I've never used that myself so this would need extra care for review.

[poddmo]

so.. abcde. Pull one thread and many bells ring. I've ripped a few more CDs have tweaked the patch along the way. I still haven't tested the PIPE work but think changing from decho to vvecho and retaining the redirect to FD4 is safer (though it's not exactly the same, not sure if it matters whether redirection happens before the command).
If you want to take this patch and split it into two pull requests, I'd take them or are you happy for me to push this? Let me know what you think please.

diff abcde-2.12.3 abcde-2.12.4-DEV
15c15
< VERSION='2.12.3'
---
> VERSION='2.12.4-DEV'
1500c1500
< 						vecho -n "DISTMP3:"
---
> 						vecho "DISTMP3:"
2243c2243
< 		vecho -n "Getting CD track info... "
---
> 		vecho "Getting CD track info... "
3123c3123
< 			vecho -n "Retrieving multiple matches... "
---
> 			vecho "Retrieving multiple matches... "
3145c3145
< 			vecho "done."
---
> 			vvecho "Retrieving multiple matches done."
4080c4080
< 		*) >&4 echo "$@" ;;
---
> 		*) >&4 echo "[Verbose] $@" ;;
4093c4093
< 		*) >&4 echo "$@" ;;
---
> 		*) >&4 echo "[Verbose2] $@" ;;
4098,4112d4097
< # decho [message]
< #
< # decho outputs a debug message if DEBUG is selected
< decho ()
< {
< if [ x"$DEBUG" != "x" ]; then
< 	if echo "$1" | grep "^\[" > /dev/null 2>&1 ; then
< 		DEBUGECHO=$(echo "$@" | tr -d '[]')
< 		echo >&4 "[DEBUG] $DEBUGECHO: $(eval echo \\$${DEBUGECHO})"
< 	else
< 		echo >&4 "[DEBUG] $1"
< 	fi
< fi
< }
<
4634c4619
< 		z) DEBUG=y ; CDROMREADERSYNTAX=debug ; EJECTCD="n" ;;
---
> 		z) CDROMREADERSYNTAX=debug ; EJECTCD="n" ;;
5425c5410
< 	decho "PIPERIPPERSVARCHECK: $( eval echo "\$$PIPERIPPERSVARCHECK" )"
---
> 	vvecho "PIPERIPPERSVARCHECK: $( eval echo "\$$PIPERIPPERSVARCHECK" )"
5432c5417
< 	decho "PIPEENCODERSVARCHECK: $( eval echo "\$$PIPEENCODERSVARCHECK" )"
---
> 	vvecho "PIPEENCODERSVARCHECK: $( eval echo "\$$PIPEENCODERSVARCHECK" )"
5522c5507
< 	vecho -n "Executing customizable pre-read function... "
---
> 	vecho "Executing customizable pre-read function... "
5526c5511
< 	vecho "done."
---
> 	vvecho "Pre-read done."

[pccasto]

I'll remove the decho part from this one, focusing this on just the prepending of [Verbose] or [Verbose2].

I take it from your diff above that the vecho -n does not have the intended effect of suppressing the new line.
Looking at the code, I can see it would not... and I failed to consider that invocation.
but I can include handling for that case, so that function is not lost.

The redirect to FD4 seems immaterial, given this:
# fd for when vecho and log info called with redirected stdout
exec 4>&1

But I will try some testing to see if I can better understand that as part of a pull request focused on the decho change.

[pccasto]

Pull request updated with changes as descibed in the commit. And sorry about the 'mac-ism' in the shebang line...