Description of problem: test -f return true for symlinks Version-Release number of selected component (if applicable): coreutils-8.12-2.fc16.src.rpm How reproducible: always Steps to Reproduce: 1.With xen installed, for F in /boot/xen*; do if /usr/bin/test -f ${F}; then echo ${F} is a file.; fi; done 2. 3. Actual results: /boot/xen-4.1.1.gz is a file. /boot/xen-4.1.gz is a file. /boot/xen.gz is a file. /boot/xen-syms-4.1.1 is a file. Expected results: /boot/xen-4.1.1.gz is a file. /boot/xen-syms-4.1.1 is a file. Additional info: # ll /boot/xen* -rw-r--r--. 1 root root 729540 Aug 14 09:29 /boot/xen-4.1.1.gz lrwxrwxrwx. 1 root root 12 Sep 19 12:57 /boot/xen-4.1.gz -> xen-4.1.1.gz lrwxrwxrwx. 1 root root 12 Sep 19 12:57 /boot/xen.gz -> xen-4.1.1.gz -rw-r--r--. 1 root root 12958461 Aug 14 09:29 /boot/xen-syms-4.1.1 This prevents, for example, grub2-mkconfig from working properly - it uses the two symlinks and creates extra boot menus.
This is a regression from coreutils-5.x.
Well, I think this is not a bug but expected behaviour - if the symlink points to regular file, it is dereferenced and recognized as regular file by test -f (or shell builtin -f ) ... However, if the symlink is broken, it is not recognized as regular file. Check: [Reset@dhcp-24-196 ~]$ ln -s broken brokenlink [Reset@dhcp-24-196 ~]$ test -f brokenlink && echo is file In Debian, similar bugzilla was wontfixed see e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231267 ... However, there is one argument for improving manpage/info documentation - find behaves differently in that case... [Reset@dhcp-24-196 ~]$ find /lib -name libz.so.1 -type f [Reset@dhcp-24-196 ~]$ find /lib -name libz.so.1 /lib/libz.so.1 [Reset@dhcp-24-196 ~]$ test -f /lib/libz.so.1 && echo is file is file [Reset@dhcp-24-196 ~]$ /usr/bin/test -f /lib/libz.so.1 && echo is file is file Leaving it opened for a while (upstream is on bugzilla watch) ...
POSIX ( http://pubs.opengroup.org/onlinepubs/000095399/utilities/test.html ) states : -f pathname True if pathname resolves to a file that exists and is a regular file. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a regular file. So it is all about definition of "pathname resolving" ...
(In reply to comment #1) > This is a regression from coreutils-5.x. For the record, that is untrue. My mistake, sorry.
Cleanup ... closing NOTABUG based on comment #3.