Re: Dotfiles

On Wed, Jul 3, 2013 at 6:28 AM, shawn wilson <ag4ve.us@gmail.com> wrote:

On Tue, Jul 2, 2013 at 5:14 PM, Lisi Reisz <lisi.reisz@gmail.com> wrote:
> On Tuesday 02 July 2013 22:06:17 Yaro Yaro wrote:
>> On Jul 2, 2013 3:49 PM, "Hendrik Boom" <hendrik@topoi.pooq.com> wrote:
>> > There are lots of .dotfiles cluttering my home directory.
>> >
>> > No doubt some of them are useful.
>> >
>> > Many, though, are probably remnants of packages of years past -- packages
>> > I installed long ago, no longer need, and have removed.
>> >
>> > Is there any way of identifying which packages are using which dotfiles?
>> >
>> > And which ones are obsolete -- the user equivalent of configuration
>> > files, which are properly tracked by the package manager?
>> >
>> > Should there be?
>> >
>> > -- hendrik
>
>> Package managers don't track .dotfiles. Those are created at runtime by
>> your software.
>
> He knows that. He wants ot know how to identify which ones are no longer
> needed.
>

Short answer - no. Long answer (and this would be fun - post the
script if you do this):

You're thinking too hard. How about

ls -lartd .*

as a first approximation? Oh, there's the options to look at different types of access timestamps, too, I'm too lazy to man ls for them.

Files, not directories, that show up at the end are active, of course. The same command without the -d option will give more information if you're just eyeballing it, but is going to be harder to interpret with a script. If you want a script, you'll need to recursively visit the dot-directories, instead.

When things get this involved, you often find that bash becomes a little unwieldy, compared to perl, etc. Good scripting languages provide the recursive search for you.

The hard parts are picking the cutoff date and figuring out what to do with the packages that haven't been accessed recently. Usually you can look inside the files or the parent directories to get clues on what applications dropped them there.

Use a tool that shows what files are being accessed (like fuser, but
you'll probably have better luck with strace or gdb) and use some
expect like language (or IPC) to fire up the command (either through
strace or gdb or quickly attach gdb to it) and see what files it looks
for.

Easiest would probably be to: find / type f -perm +111 | while read f;
do dotfile-scraper $f; done

I think the easiest is 'strace -f -s 1024 -e trace=stat64,read' and
run until the volume of output decreases and then just kill the
program (probably as a test user so you don't corrupt your own stuff).

I don't think this is the answer you were looking and doubt you'll
pursue this but, as I said, if you do I'd like to see the script /
what you find.

I think you're just looking for an excuse to use the low-level stuff. ;-)

It does sound fun, though, as a way to tie the persistent store files of apps you are using to their apps

The "real" solution kind of points to something we need to do -- sandboxing all apps, making them tell the system who they are when they want to drop persistent store, maintaining a database of legitimate apps and their persistent store.

And we need to do this for more reasons than just to keep the home directory clean of dotfiles.

--
Joel Rees