Re: Wrong behavior of ``readlink -f''?
Hello! On Wed, Feb 13, 2008 at 08:53:01AM +0100, Jim Meyering wrote: Thomas Schwinge [EMAIL PROTECTED] wrote: $ readlink -f a/../a/f $ echo $? 1 ... readlink (GNU coreutils) 5.97 Why doesn't it resolve the latter case just as the previous ones? Because there are two symbolic links involved? Or two times the same one? Strange. Thanks for the report. That's because the code concluded it had encountered a cycle. The bug was fixed for coreutils-6.9.90 via a change to gnulib's canonicalize module. For posterity. I need this functionality in a somewhat portable build environment, so this is what I'm using in `configure.ac' now: #v+ [...] [# Test for a readlink bug, see # http://lists.gnu.org/archive/html/bug-coreutils/2008-02/msg00126.html.] AC_MSG_CHECKING([for a suitable ``readlink -f'' program]) [mkdir readlink-test mkdir readlink-test/a-long : readlink-test/a-long/f ln -s a-long readlink-test/a for READLINK_F in \ 'readlink -f' \ realpath \ false do if $READLINK_F /dev/null 21 \ readlink-test/a/../a/f then break fi done rm -rf readlink-test if [ $READLINK_F = false ] then] AC_MSG_RESULT([none found, using own replacement]) [READLINK_F='perl -e '\''use Cwd qw(abs_path); print abs_path $$ARGV[0];'\' else] AC_MSG_RESULT([$READLINK_F]) [fi] AC_SUBST([READLINK_F]) [...] #v- Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Wrong behavior of ``readlink -f''?
Hello! I'm a bit stumped with this behavior of ``readlink -f'', as it doesn't match what I had expected. #v+ [EMAIL PROTECTED]:~/tmp $ mkdir a-long [EMAIL PROTECTED]:~/tmp $ touch a-long/f [EMAIL PROTECTED]:~/tmp $ ln -s a-long a [EMAIL PROTECTED]:~/tmp $ readlink -f a/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a-long/../a/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a/../a-long/f /home/thomas/tmp/a-long/f [EMAIL PROTECTED]:~/tmp $ readlink -f a/../a/f [EMAIL PROTECTED]:~/tmp $ echo $? 1 #v- Why doesn't it resolve the latter case just as the previous ones? Because there are two symbolic links involved? Or two times the same one? Strange. #v+ [EMAIL PROTECTED]:~/tmp $ readlink --version | head -n 2 readlink (GNU coreutils) 5.97 Copyright (C) 2006 Free Software Foundation, Inc. [EMAIL PROTECTED]:~/tmp $ apt-cache policy coreutils | grep Installed Installed: 5.97-5.3ubuntu3 #v- I even decided to give the git master branch an try, but: ``configure.ac:35: require Automake 1.10.1, but have 1.10''. There I decided to stop and not begin upgrading my whole toolchain. Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Wrong behavior of ``readlink -f''?
Thomas Schwinge [EMAIL PROTECTED] wrote: $ readlink -f a/../a/f $ echo $? 1 ... readlink (GNU coreutils) 5.97 Why doesn't it resolve the latter case just as the previous ones? Because there are two symbolic links involved? Or two times the same one? Strange. Thanks for the report. That's because the code concluded it had encountered a cycle. The bug was fixed for coreutils-6.9.90 via a change to gnulib's canonicalize module. Regarding your attempt to build from checked-out sources, you might want to try the latest stable release: http://article.gmane.org/gmane.comp.gnu.core-utils.announce/44 ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.10.tar.gz ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.10.tar.lzma or a snapshot (post-6.10) tarball: http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/12611 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
