find -not -type d

Forum: DSL Tips and Tricks
Topic: find -not -type d
started by: jpeters

Posted by jpeters on Oct. 06 2007,09:09

I just ran across this way of automatically removing directories from the find list, and thought it might be a good addition to Mikshaws excellent WIKI article on creating an extension from source. (I tried adding the option using the edit function, but the change disappeared.) (e.g., "find /file -not -type d > file.list" ) (note: I think it requires gnu-utils)

(p. 204 , Damn Small Linux Book)

Posted by curaga on Oct. 06 2007,14:32

A simpler way of saying that:

find /file -type f > filelist

Posted by jpeters on Oct. 06 2007,15:38

Quote (curaga @ Oct. 06 2007,10:32)

A simpler way of saying that:

find /file -type f > filelist

Indeed...life just keeps getting simpler..
except now comes the question of editing both the WIKI AND
p 204, Damn Small Linux....

Posted by mikshaw on Oct. 06 2007,19:30

Personally I have no intention of editing what I wrote unless there is error in it. The reason for this is that I don't recommend your method of removing all directories indiscriminately. In most cases it should be fine to do that, but occasionally an application wants a particular directory to exist regardless of whether or not it's empty. I've actually even seen some apps that will fail to run if a particular directory is not found. This is poor programming, in my opinion, but it happens sometimes. In other cases, I think it's a good idea to keep some empty directories in select packages to help the user know where to put certain user-added files, such as plugins, codecs, themes, etc.

I think I've mentioned this before, but I believe solving the problem of file clobbering by removing all directories is similar to opening windows with a hammer. It works, but if you find out later that you needed to keep some of those windows closed you end up making more work for yourself. The only time directories cause problems is when they are pre-existing directories that have different owners/permissions than those in the extension, and typically this affects only the top few levels of the directory structure. For example, if you have an application that installs to /opt/myapp, the only directory you need to worry about taking out of the package is /opt. Any directories within myapp will not clobber anything unless "myapp" happens to be the name of a pre-existing directory (which it should *not* be unless you're making an extension just for your own use).

Existing directories in a *.dsl extension are of course much more common, so perhaps omitting them all (at least initially) would be much more efficient in that case. I haven't made a *.dsl myself in a couple of years, though, so my personal thought on that is "I don't care what you want to write about that type". Since nearly everything I do now is *.uci, the only directories that I need to watch are in user.tar.gz...a very minor task. Nothing else has even the slightest chance of clobbering.

Posted by jpeters on Oct. 07 2007,07:51

I was thinking it of including it as way of getting a list with only files, if that is what is desired (e.g., backups), not replacing the option of manually deleting folders, when that is required (e.g., an extension that requires an empty directory).

The example quoted (p.204 Damn Small Linux Book) was for compiling from souce to create a tar.gz extension, not UCI extensions (although the example installed all the files into the /opt directory).

Posted by Juanito on Oct. 07 2007,11:45

Kind of off-topic, but...

Samba and cups are examples of applications that will not work unless they find certain directories, eg /var/locks, that can be empty as long as they exist.

I've been using "touch /var/locks/placeholder" to be able to add the directory to my backup (but avoid saving all of the files that might created in the directory) and to indicate in a *.dsl extension that this directory is required.

Posted by mikshaw on Oct. 07 2007,13:13

Quote

I've been using "touch /var/locks/placeholder"

I'd say this is probably the best solution overall, of those that I've heard. I use something similar to this in one or two extensions that want certain personal configuration files in the user's home directory. Rather than include these files in user.tar.gz, they are installed to the application directory, and the application is run from a wrapper script. The wrapper checks for the existence of the needed files/directories, and copies/creates them only if necessary before running the application. This method allows you to store an original file that can be used in the event of a configuration mishap, it allows the same behavior if you happen to run the program as a different user, and allows you to indiscriminately delete all directories in a package without causing application failure. The drawback, of course, is that it requires the use of a wrapper script.

Using wrappers is a fairly common practice even outside of DSL, though. Apps such as Firefox that are intended to be essentially self-contained will often use wrappers to prepare the environment to run the app, just as we do for many uci and tar.gz mydsl packages.