Re: Does [ -f FILE ] have a bug on testing a symlink ?

[Jonathan Hankins]

The OP's issue isn't bash-specific.

The behavior of test WRT symbolic links is specified in POSIX, cf. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

Specifically:

"With the exception of the -h pathname and -L pathname primaries, if a pathname argument is a symbolic link, test shall evaluate the _expression_ by resolving the symbolic link and using the file referenced by the link."

-Jonathan Hankins

On Tue, Feb 10, 2015 at 3:25 PM, Stephane Chazelas <stephane.chazelas@gmail.com> wrote:

2015-02-09 14:59:06 -0700, Bob Proulx:
[...]
> The idea is that symlinks should be completely transparent and
> invisible to most applications.  The idea is that when normal things
> are run they don't realize they are using a symlink.  Behavior would
> be exactly the same as if it were a regular file system link.  That is
> what is happening in your test case.  The symlink references an
> existing file, is a regular file and exists, therefore the status is
> true.
[...]

Note the discrepancy with "find" though.

With find, -type f will not match on symlinks to regular files
(unless you also use -L/-follow).

If you actually want to find regular files after resolving
symlinks, without resolving symlinks when walking down the
directory tree, that's where it becomes cumbersome.

POSIXly, you have to resort to the test command:

find . -exec test -f {} \; -print

With GNU find, you can use -xtype:

find . -xtype f

GNU find's -printf still doesn't give information on the target
of  the symlink.

--
Stephane

--

------------------------------------------------------------------------

Jonathan Hankins    Homewood City Schools

The simplest thought, like the concept of the number one,

has an elaborate logical underpinning. - Carl Sagan

jhankins@homewood.k12.al.us

------------------------------------------------------------------------