Red Hat Bugzilla – Bug 199442
Fix find(1) option order
Last modified: 2007-11-30 17:11:38 EST
I just discovered that find(1) doesn't like the order of arguments in the FE Perl spec template. The warning goes to /dev/null so it has went unnoticed. Reproducer: $ find /tmp -type d -depth >/dev/null find: warning: you have specified the -depth option after a non-option argument -type, but options are not positional (-depth affects tests specified before it as well as those specified after it). Please specify options before other arguments. I've fixed this in rpmdevtools CVS; fix against cpanspec 1.67 attached.
Created attachment 132694 [details] Fix find(1) option order
Thanks. I've applied the patch to cpanspec in CVS.
I just noticed that find has a -empty option. I wonder if we should be doing this: find $RPM_BUILD_ROOT -depth -type d -empty -exec rmdir {} \; (Not redirecting output.)
I think the reason -empty is not used is because it's not in POSIX nor LSB (note how the *.bs check uses -size 0 too). Not sure of the relevance of that though. Newer versions of find have also -delete which could be interesting. And rmdir has -p and --ignore-fail-on-non-empty, and from the pedantic POV we should possibly be using find -print0 | xargs -0 (if -delete is not used) and the chmod would be better off done immediately after make pure_install and DESTDIR probably works fine nowadays, it could be used instead of PERL_INSTALL_ROOT... There are quite a few things that could be cleaned up, but I don't know what to think of that; I haven't heard of anything being actually broken and changes *could* result in some incompatibilities with old distros which may matter to some people. Thoughts?
Making everything "perfect" would be great and all, although it probably should be saved until after FC6 is out. My thought with using -empty was that it would let us drop the "2>/dev/null", which would make it harder for problems with that line to be ignored.
Yes, I think the -empty stuff is an innocent enough change that could be done soon (in case the POSIX/LSB issue is a non-issue). About the other things, I'd like to keep things compatible with RHEL4 as long as it makes sense, so as far as I'm personally concerned, the FC6 release does not have a too significant role wrt. any cosmetic cleanups.