Re: Problems building coreutils HEAD against gnulib HEAD

2008-02-19 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding bug-automake] According to Jim Meyering on 2/19/2008 4:33 AM: | But I am, having seen it myself. It happens when you have a stale symlink | from an older copy of gnulib, but which now points nowhere because the | file was renamed in gnulib.

Re: Problems building coreutils HEAD against gnulib HEAD

2008-02-19 Thread Jim Meyering
Eric Blake [EMAIL PROTECTED] wrote: [adding bug-automake] According to Jim Meyering on 2/19/2008 4:33 AM: | But I am, having seen it myself. It happens when you have a stale symlink | from an older copy of gnulib, but which now points nowhere because the | file was renamed in gnulib. | |

Re: Problems building coreutils HEAD against gnulib HEAD

2008-02-19 Thread Ralf Wildenhues
Hello, * Eric Blake wrote on Tue, Feb 19, 2008 at 02:28:35PM CET: [adding bug-automake] According to Jim Meyering on 2/19/2008 4:33 AM: | But I am, having seen it myself. It happens when you have a stale symlink | from an older copy of gnulib, but which now points nowhere because the |

Re: Problems building coreutils HEAD against gnulib HEAD

2008-02-19 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Andreas Schwab on 2/19/2008 8:37 AM: | Jim Meyering [EMAIL PROTECTED] writes: | | +# Remove dangling symlinks in gnulib-populated directories. | +# This depends on GNU find, and a relatively recent version at that. | +# Ignore any

Re: Problems building coreutils HEAD against gnulib HEAD

2008-02-19 Thread Andreas Schwab
Jim Meyering [EMAIL PROTECTED] 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

Re: Problems building coreutils HEAD against gnulib HEAD

2008-02-19 Thread James Youngman
On Feb 19, 2008 8:12 PM, Eric Blake [EMAIL PROTECTED] wrote: The goal here is not to delete all symlinks, just symlinks that are broken. Under the influence of -L, does -xtype l work like -lname '*' in detecting just the broken symlinks? For that you want find . -depth -type l -xtype l