RFC: path display and path filtering features.

[Grant Edwards]

On 2011-02-18, Roland McGrath <roland at redhat.com> wrote:
>> For my use cases, it's acceptable to expect the user to enter a
>> canonical path and expect the program to open the file with a
>> canonical path. I expect that there are other common use cases where
>> that's not acceptable.
>
> That seems fine enough to start out with, and worry about more later.
>
> It might be that what users really want is just to be able to give
> fnmatch-style patterns (w/o FNM_PATHNAME) so it's easy to match multiple
> different ways to find a file name.

That does sound useful, but I think I'll put that on the list of
enhancements for later.

> That doesn't help with symlinks in the final component, of course.
> For that, you might really want to canonicalize both the
> name-to-match and traced names.

What I have now is:

 1) Store the arg to -P both as-is and as canonicalized by realpath().

 2) Display syscall if a path arg matches either or if (for an fd arg)
    /proc/$pid/fd/$fd matches either.

 3) Return-value file-descriptors are not checked.

I'm going to try to clean up a few loose ends, and I'll post another
set of pathces later today.

If I have time, I may try to construct a canonical path from the
fd,path tuple passed to calls like openat().

It would be nice if descriptor return-values could also be matched,
but since we've already skipped the display of most of the syscall
info, it's difficult to decide to print a syscall after it has exited.

-- 
Grant Edwards               grant.b.edwards        Yow! My EARS are GONE!!
                                  at               
                              gmail.com