>  Nevertheless, it does appear to be fixable in a similar manner, and this might or might not be worth forwarding to the RPM upstream.

The file was removed from RPM upstream and moved to: https://github.com/rpm-software-management/python-rpm-packaging/blob/main/scripts/brp-python-bytecompile which should be more or less kept in sync with what is in redhat-rpm-config.

I'Ve opened a pull request with the proposed changes: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/127

I've tried to reproduce the issue and I can confirm that a folder with a space in its name can cause the mentioned issues:

$ ls test/
 one  'thr e e'  'tw o'

$ for dir in `find ./test -type d`; do echo $dir ; done
./test
./test/thr
e
e
./test/tw
o
./test/one

But the mentioned way with the while loop does not work for me and I honestly don't know why:

$ while IFS= read -r -d '' dir; do echo $dir; done < <(find ./test -type d)
<nothing>

but it works when I omit the delimiter specification:

$ while IFS= read -r dir; do echo $dir; done < <(find ./test -type d)
./test
./test/thr e e
./test/tw o
./test/one

Anyway, I think that better might be to make it less cryptic with just a basic read and one pipe:

$ find ./test -type d | while read dir; do echo $dir; done
./test
./test/thr e e
./test/tw o
./test/one

Do you know about any reason why the mentioned way might be worse than what you proposed?

Hello.

Are you still interested in this?

Hi - sorry, yes, still very much interested in this.

I expect the reason your test didn't work was because you didn't include "-print 0" in your find statement. The delimiter -d '' used in the read statement tells bash to expect null delimiters, and so the find statement needs to produce them to match.

The reason for my more convoluted suggestion was to avoid the pipe, so that the inside of the loop didn't run inside a new subshell (which is different from how the original code runs, and I didn't want to cause unexpected problems with things like variable assignments, exit codes and so on).  But this was just me being extra cautious, and perhaps your simpler solution that pipes the inside of the loop into a subshell works just fine.

Best regards - Ben.

^^ oops, there was a typo in comment 5 posted just now: I meant "-print0", not "-print 0", in the find statement.

Thanks for the explanation and the reasoning.

To sum it up, we have two possibilities for how to implement the loop:

The first one is more complex to read but runs all the commands in the main shell:

while IFS= read -r -d '' python_libdir;
do
  echo $python_libdir
  # do stuff
done < <(find "/usr/lib" -type d -print0|grep -z -E "/(usr|app)/lib(64)?/python[0-9]\.[0-9]+$")

The second one is shorter and easier to read but runs all the commands in a subshell:

find "/usr/lib" -type d -print0|grep -z -E "/(usr|app)/lib(64)?/python[0-9]\.[0-9]+$" | while read -d "" python_libdir;
do
  echo $python_libdir;
  # do stuff
done

I honestly don't have a favorite candidate. I don't think that running the commands in a subshell causes any issues but I also don't consider the first candidate too complex to reject it.

@mhroncok what do you think?

I'd prefer to maintain the second option, but it is not a strong opinion.

The pull request is ready from my point of view.

FEDORA-2021-d3e0183946 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-d3e0183946

FEDORA-2021-d3e0183946 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.