Fix validate_for_chd and unquoted log line

[reyemxela]

compression.sh line 37:

if [[ $(validate_for_chd "$1") == "true" ]] && ...

is currently broken. validate_for_chd has several log calls, and the log function echoes to stdout as well as logging to file, which causes things like this to have problems. Running find_compatible_compression_format with set -x shows what's happening:

...
++ IFS=
++ read -r line
++ echo true
+ [[ [2024-05-14 13:24:42.662] [INFO] Validating file: /home/alexmeyer/retrodeck/roms/psx/Disney-Pixar Toy Story 2 - Buzz Lightyear to the Rescue! (USA) (Rev 1).cue
[2024-05-14 13:24:42.667] [INFO] .cue/.iso/.gdi file detected
[2024-05-14 13:24:42.674] [INFO] Validating .cue associated .bin files
[2024-05-14 13:24:42.678] [INFO] Associated bin files read:
[2024-05-14 13:24:42.681] [INFO] Disney-Pixar
[2024-05-14 13:24:42.681] [WARN] Log file not found in "Toy", creating it
[2024-05-14 13:24:42.693] [INFO] Looking for /var/home/alexmeyer/retrodeck/roms/psx/Disney-Pixar Toy Story 2 - Buzz Lightyear to the Rescue! (USA) (Rev 1).bin
[2024-05-14 13:24:42.695] [INFO] .bin file found at /var/home/alexmeyer/retrodeck/roms/psx/Disney-Pixar Toy Story 2 - Buzz Lightyear to the Rescue! (USA) (Rev 1).bin
true == \t\r\u\e ]]
...

That whole log section is the string that's being compared to 'true', which obviously fails. The easy fix is what I added, which is just comparing to *true so the rest of that string doesn't affect it, but this definitely needs some re-working on a deeper level.

The other thing I fixed is one unquoted log on line 69 that breaks if the target filename has spaces in it.

[XargonWan]

I never thought about *true, that is pretty smart.

Basically "[DEBUG] Logging this linetrue" will be evaluated as *true.

How much testing you did on this?
Is it "solid enough" for the moment?

[reyemxela]

I didn't do a ton of debugging, but as a temporary fix, this should be solid enough. The validate_for_chd function prints true/false as the very last output, so there shouldn't really be any false positives/negatives.

As it is right now, chd compression just plain doesn't work because that comparison statement will never match.

But honestly, no, this isn't the BEST fix. Trying to capture output from any other function that itself that uses the log function will have the same problem, the log messages all get eaten up and captured along with the "expected" output from the function in question. We'd need a different setup to keep log output separate from "return" values of functions.

So yeah, I think this works for now, for this instance. If it would be of help, I could try digging in to the scripts and see if I can see a more solid way to do logging within value-returning functions. For something like this function where it only needs a true/false, it could actually just do a return 0 or return 1, and then the if is just checking the return code instead of capturing the output and comparing it.

[XargonWan]

That is why some functions are not logged yet. I missed this one apparently, good catch.

We might include this as an hotfix, however I personally never found a solution to the logging yet.
If you can find one for sure we will evaluate that.

Thanks a lot!

[reyemxela]

I just realized a pretty simple solution to this, just make log output to stderr for its output. This allows it to still write to the console perfectly fine, while keeping log messages out of function outputs. I just did some testing and it seems to work fine.