On Wed, Jul 3, 2013 at 6:28 AM, shawn wilson <ag4ve...@gmail.com> wrote:
> On Tue, Jul 2, 2013 at 5:14 PM, Lisi Reisz <lisi.re...@gmail.com> wrote:
> > On Tuesday 02 July 2013 22:06:17 Yaro Yaro wrote:
> >> On Jul 2, 2013 3:49 PM, "Hendrik Boom" <hend...@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
