Re: Problems building coreutils HEAD against gnulib HEAD

[Andreas Schwab]

Eric Blake <address@hidden> writes:

> According to Andreas Schwab on 2/19/2008 8:37 AM:
> | Jim Meyering <address@hidden> writes:
> |
> |> +# Remove dangling symlinks in gnulib-populated directories.
> |> +# This depends on GNU find, and a relatively recent version at that.
> |> +# Ignore any failure for now, since it's only to avoid the relatively
> |> +# unusual case in which a symlinked-to file in gnulib/ or gl/ is removed.
> |> +find -L m4 lib build-aux -depth -lname '*' -delete > /dev/null 2>&1
> |
> | Why do you need -depth?  Also, find 4.1 does not support -L nor -delete.
>
> Because -delete implies -depth, and new enough findutils warns and does
> nothing rather than deleting a possibly different set of files than what
> you tested with (the use case that prompted the change was something like
> "find -name '*.txt'" as the dry run, then "find -delete -name '*.txt'"
> which proceeded to delete everything in `.').

I don't understand how -depth would have made any difference here.

> | A more portable predicate is -xtype l.
>
> The goal here is not to delete all symlinks, just symlinks that are
> broken.

That is exactly what -xtype l does.

> Under the influence of -L, does -xtype l work like -lname '*' in
> detecting just the broken symlinks?

You don't use -L of course (it isn't supported by find 4.1 anyway).
Note that with -L you would risk walking out of the base directory.

Andreas.

-- 
Andreas Schwab, SuSE Labs, address@hidden
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."