Re: [PATCH] ls - colorize files with capabilities

[Kamil Dudka]

Thank you for patience. I have made improvements you suggested.

On Saturday 19 July 2008 06:16:20 pm you wrote:
> Thanks for working on this.
> Sounds worthwhile, though maybe worth
> giving it a separate attribute rather than
> sharing the one currently used for set-user-ID programs.
Ok, added new color indicator for file with capability.

> Have you considered enabling it by default, when the library is usable?
Now enabled by default, can be disabled by --disable-libcap configure option.

> It's better to use AC_HELP_STRING:
Ok, now using AC_HELP_STRING for configure help.

> Re LIB_CAP2,
> if you don't embed the library version number in the symbol name,
> then we won't have to change it when libcap3 comes along.
Ok, renamed to LIB_CAP (and HAVE_CAP).

> Use underscores, (i.e., has_capability, has_cap), not mixed case.
Sorry for that - now using underscores.

> > +    cap_free(cap_d);
>
> Move this cap_free call "up".  Then you can remove
> the repeated call below.
>
> > +    return false;
> > +  }
> > +
> > +  /* check if human-readable capability string is empty */
> > +  hasCap = *result;
I am not sure about this change. libcap API is not well documented, so I 
decided to take code directly from getcap.c(do_getcap) - this utility is 
already tested by users. In other case I am afraid of possible premature free 
of libcap resource.

> I seem to recall that this idiom is slightly better
> from a portability standpoint, e.g., when bool is simulated
> with an 8-bit type:
>
>     hasCap = !!*result;
Ok, fixed.

> Remove these in-function #ifdefs.
> Instead, define has_capability to return false when the library
> is not available.
Ok, no problem.

Kamil

coreutils-libcap.patch
Description: Text Data