Description of problem: Dan... you're probably getting sick of my bug reports but here is another one... If you run: fixfiles check "File with spaces" you get: find: File: No such file or directory find: with: No such file or directory find: spaces: No such file or directory The problem is in the loop begining: for d in ${DIRS} This can be fixed by surrounding the entire 'for' loop by: ( IFS=$'\n' ... ) You probably don't need to do this for the loop that loops on the list of $RPMFILES since rpm packages don't typically include spaces, but it probably wouldn't hurt to do this either. I'm surprised though that no one else has run into this problem yet... but then again maybe I'm more anal than most on checking individual files to see what policy changes have been made before doing a blanket 'restore' at the root directory level :)
While your at it, there are probably some other variables that should for safety be protected with quotes -- though I am not a bash expert and it may not be necessary. For example: for d in $DIRS; do find $d You might want to quote the $d.
Oops... you need to change IFS also where you set DIR=$* or else it breaks having multiple [file/dir] entries on the command line. I did it the following 'safe' way: oldIFS=$IFS IFS=$'\n' DIRS=$* IFS=$oldIFS
I fixed a little differently so that fixfiles check "this is a test" /etc/dan will work Fixed in policycoreutils-2.0.34-4.fc8
OK, but... fixfiles check "this is a file" /etc/dan works also with my version :) unless you are saying that you don't like the error message "find /etc/dan: No such file or directory" which occurs even if you just type "fixfiles check /etc/dan" Just for my education, please help me understand what I am missing. Thanks.
When I tried your fix. I was only getting one file "this is a file" /etc/dan Instead of "this is a file" /etc/dan Of course I might or applied it incorrectly. If you had an alternate fix. please send it as a patch.
Created attachment 290592 [details] Patch for fixfile I don't know my (simple) patch works perfectly well for me on a wide range of multiple file and/or directory cases...
Ok I did not wrap the DIRS line with your change. So maybe that is why it did not work for me.
Yeah - I posted the DIRS wrap as comment #3 since I realized the same thing you did and wrote: "Oops... you need to change IFS also where you set DIR=$* or else it breaks having multiple [file/dir] entries on the command line." In any case as long as your fix works, that's good enough for me - though I like mine because it is short and sweet :)
Are you planning on releasing your fixed version (or mine :) so we can close out this bug?