[lfs-support] Using 'find' to Help Make Package Users Simpler

Dan McGhee beesnees at grm.net
Wed Oct 16 11:43:45 PDT 2013


This may come close to or straddle the "off topic" line for this list.  
I thought I'd ask my question anyway since there are some who use the 
More Control hint and who run into some of the same frustrations that I 
do.  There is a question about the use of find in this post.  If you 
don't want to read the reasoning behind doing this and some history skip 
the following three paragraphs.

The "install directory" is an important concept in this system.  It is a 
directory in which any package user can write, but that files in it can 
be changed only by the owner of that file--ug=rwx,o=rxt. The initial set 
of these directories is listed in a file called "installdirs.lst."  This 
file is used to set the permissions of all directories to which 
different package users could write.  The most frustrating, naggy and 
"four letter word" evoking event is trying to write to a directory made 
by a different package user and in which the current package user cannot 
write.  This is the purpose of the auxiliary "install" group.  The 
trick, then, is to identify all the "new" directories from a package and 
make them "install" directories.  This used to be a really "down-in 
-the-trenches" manual job.

Rob Taylor did some great work in scripting the search for new 
directories.  He has a series of 'find' statements that step through the 
directory tree--/usr, /bin, /lib, et.al.--finding all directories and 
sending them to "installdirs.lst."  He then has a sed command that 
removes /usr/src/ tree directories--this is the tree in which the 
package users have their home directories and these should not be group 
writable. He then has two statements 'chown' and 'chmod' whose input is 
$(cat installdirs.lst).

This system works and is really a nice addition to package users' 
support.  The first 'find' statement re-creates "installdirs.lst" and 
the remaining 6 append to it. And sed removes /usr/src each time.  I 
thought it would be more "economical" to not over write installdirs.lst 
each time, and to use 'find' to identify only the new directories, 
change their group ownership, then their permissions, and finally append 
them to installdirs.lst.  I know that find is powerful enough to ignore 
/usr/src, so the need for the sed statement goes away.

Here's the find statement:
<find / -xdev -type d -gid $(id -g <packageuser name>) \! -path /usr/src 
\! -path /tools -print>

This statement achieves all the parameters stated above with the 
addition that it ignores /tools also.  Now I would like to change group 
ownership and permissions and redirect the output to installdirs.lst.  I 
know I could do that using an intermediate file:

find > tmpfile
chown $(cat tmpfile)
chmod $(cat tmpfile)
tmpfile >> installdirs.lst
rm tmpfile

But, and here's the real question of this post, can I do this with one 
statement?  Here's my first idea:

'find' | 'chown' | 'chmod' >> installdirs.lst

Or, can I use more than one -exec option in 'find'? The statement would 
look something like this

find (stuff) -exec chown :install {} \; -exec chmod ug=rwx, o=rxt {} \; 
 >> installdirs.lst

The reason I'm asking this question is that one of my references says 
"[-exec] will execute the program once per file while xargs can handle 
several files with each process."  I've never been successful with xargs 
and I don't know if 'find' will, then ignore the second -exec.  I 
haven't been able to glean anymore from wandering around on the internet 
and wading through man pages.

I have "piped" the output of find only once many times, but I don't know 
if the output would survive two pipes.

I guess that it's just one question after all.  Can I use "chained" 
pipes or -execs before I redirect?

Anyone have any comments or suggestions.  In the meantime, I'll just 
play.  What can I do, but screw things up, and I've done that twice this 
week already.

Sorry for the long post.  I appreciate your patience.

Thanks,
Dan




More information about the lfs-support mailing list