runlogwatch.sh seems broken by pyinotify in at least some jobs

[dtantsur]

The logs in https://github.com/metal3-io/baremetal-operator/actions/runs/13370277135/job/37696054576?pr=2113 look wild:

************ Contents of �[0m<�[0m�[31m�[1mEvent�[0m/�[34mmask�[0m�[0m=�[0m�[35m0x8�[0m �[34mmaskname�[0m�[0m=�[0m�[35mIN_CLOSE_WRITE�[0m �[34mname�[0m�[0m=�[0m�[35m4725b55f-e696-403b-8c43-d2bbff8d5e0f_inspection-rmtsnx~inspection-inspect_inspect_2025-02-24-08-34-12.tar.gz�[0m �[34mpath�[0m�[0m=�[0m�[35m/shared/log/ironic/deploy�[0m �[34mpathname�[0m�[0m=�[0m�[35m/shared/log/ironic/deploy/4725b55f-e696-403b-8c43-d2bbff8d5e0f_inspection-rmtsnx~inspection-inspect_inspect_2025-02-24-08-34-12.tar.gz�[0m �[34mwd�[0m�[0m=�[0m�[35m1�[0m �[0m>�[0m ramdisk log file bundle **************
sed: -e expression #1, char 258: unknown option to `s'
tar (child): \033[0m<\033[0m\033[31m\033[1mEvent\033[0m/\033[34mmask\033[0m\033[0m=\033[0m\033[35m0x8\033[0m \033[34mmaskname\033[0m\033[0m=\033[0m\033[35mIN_CLOSE_WRITE\033[0m \033[34mname\033[0m\033[0m=\033[0m\033[35m4725b55f-e696-403b-8c43-d2bbff8d5e0f_inspection-rmtsnx~inspection-inspect_inspect_2025-02-24-08-34-12.tar.gz\033[0m \033[34mpath\033[0m\033[0m=\033[0m\033[35m/shared/log/ironic/deploy\033[0m \033[34mpathname\033[0m\033[0m=\033[0m\033[35m/shared/log/ironic/deploy/4725b55f-e696-403b-8c43-d2bbff8d5e0f_inspection-rmtsnx~inspection-inspect_inspect_2025-02-24-08-34-12.tar.gz\033[0m \033[34mwd\033[0m\033[0m=\033[0m\033[35m1\033[0m \033[0m>\033[0m: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now

[metal3-io-bot]

This issue is currently awaiting triage.
If Metal3.io contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[dtantsur]

/cc @elfosardo
/kind bug

[elfosardo]

that looks like it's not getting the correct values from the read command, plus some colorized text

I'll have a look