[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems building coreutils HEAD against gnulib HEAD
From: |
Jim Meyering |
Subject: |
Re: Problems building coreutils HEAD against gnulib HEAD |
Date: |
Wed, 20 Feb 2008 22:18:17 +0100 |
Eric Blake <address@hidden> wrote:
> According to Andreas Schwab on 2/19/2008 2:32 PM:
> |> 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.
>
> POSIX requires "find -L . -type l" to print all broken symlinks, but has
> the drawback, as you mention, of following symlinks into other
> directories, as well as the drawback that not all finds are
> POSIX-compliant (Solaris 8 find, for example, does not understand -L).
> POSIX also requires "-exec ... {} +" to work, but not all finds support
> that (and since you seem to be stuck on the ancient GNU find 4.1, that is
> one of the programs that lacks it). Without "-exec ... {} +", you run the
> risk of a poorly named symlink containing metacharacters which won't work
> nicely with xargs, or you suffer a slowdown of "-exec ... {} \;", or you
> fall back to extensions like -print0.
>
> Everything else mentioned in this thread (-xtype, -delete, -lname,
> -print0) is a GNU extension; and while BSD find has some of the same
> extensions, it does not have them all. And Solaris find is just too poor
> in features to find broken symlinks in the first place. So once you
> assume GNU find, you might as well assume it in multiple aspects. I'll
> leave it up to Jim what to put in the bootstrap script.
I like the idea of avoiding -L, even if the penalty for using it -- escaping
the tree to delete other dangling symlinks -- might be a *good* thing :-)
Here's what I've added to coreutils' bootstrap script:
# Remove dangling symlinks in gnulib-populated directories, since
# a dangling m4/*.m4 symlink would cause aclocal to fail.
# 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 m4 lib build-aux -depth -type l -xtype l -delete > /dev/null 2>&1
Re: Problems building coreutils HEAD against gnulib HEAD, Ralf Wildenhues, 2008/02/19