Re: Does [ -f FILE ] have a bug on testing a symlink ?
$ touch foo $ ln -s foo bar $ [[ -f foo ]] [[ ! -h foo ]] echo exists and is not a symlink exists and is not a symlink $ [[ -f bar ]] [[ ! -h bar ]] echo exists and is not a symlink $ -Jonathan Hankins On Mon, Feb 9, 2015 at 6:00 PM, Cheng Rk crq...@ymail.com wrote: On Monday, February 9, 2015 3:13 PM, Andreas Schwab sch...@linux-m68k.org wrote: Cheng Rk crq...@ymail.com writes: Then the builtin test help need a documentation fix, right? You're addressing different lines but I am saying this line is inaccurate, right? -f FILETrue if file exists and is a regular file. Is there really a simple regular file test existing? test: test [expr] Evaluate conditional expression. Exits with a status of 0 (true) or 1 (false) depending on the evaluation of EXPR. Expressions may be unary or binary. Unary expressions are often used to examine the status of a file. There are string operators and numeric comparison operators as well. The behavior of test depends on the number of arguments. Read the bash manual page for the complete specification. -- Jonathan HankinsHomewood City Schools The simplest thought, like the concept of the number one, has an elaborate logical underpinning. - Carl Sagan jhank...@homewood.k12.al.us
Re: Does [ -f FILE ] have a bug on testing a symlink ?
The current behaviour is according to the intended functionality of symlinks when they first appeared, i e to create first-rank local references across få boundaries. cf hard links. Hans J. Albertsson From my Nexus 5 Den 10 feb 2015 10:04 skrev Jonathan Hankins jhank...@homewood.k12.al.us : $ touch foo $ ln -s foo bar $ [[ -f foo ]] [[ ! -h foo ]] echo exists and is not a symlink exists and is not a symlink $ [[ -f bar ]] [[ ! -h bar ]] echo exists and is not a symlink $ -Jonathan Hankins On Mon, Feb 9, 2015 at 6:00 PM, Cheng Rk crq...@ymail.com wrote: On Monday, February 9, 2015 3:13 PM, Andreas Schwab sch...@linux-m68k.org wrote: Cheng Rk crq...@ymail.com writes: Then the builtin test help need a documentation fix, right? You're addressing different lines but I am saying this line is inaccurate, right? -f FILETrue if file exists and is a regular file. Is there really a simple regular file test existing? test: test [expr] Evaluate conditional expression. Exits with a status of 0 (true) or 1 (false) depending on the evaluation of EXPR. Expressions may be unary or binary. Unary expressions are often used to examine the status of a file. There are string operators and numeric comparison operators as well. The behavior of test depends on the number of arguments. Read the bash manual page for the complete specification. -- Jonathan HankinsHomewood City Schools The simplest thought, like the concept of the number one, has an elaborate logical underpinning. - Carl Sagan jhank...@homewood.k12.al.us
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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
Re: Does [ -f FILE ] have a bug on testing a symlink ?
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.chaze...@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 HankinsHomewood City Schools
The simplest thought, like the concept of the number one,
has an elaborate logical underpinning. - Carl Sagan
jhank...@homewood.k12.al.us
Re: Does [ -f FILE ] have a bug on testing a symlink ?
On 02/09/2015 02:00 PM, Cheng Rk wrote: To bug-bash@gnu.org: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? Read the rest of the docs: Unless otherwise specified, primaries that operate on files follow sym‐ bolic links and operate on the target of the link, rather than the link itself. $ [ -f tmp/sym-link ] echo true true which means tmp/sym-link resolved to a regular file. You need test -h to determine if you have a symlink. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Does [ -f FILE ] have a bug on testing a symlink ?
Cheng Rk wrote: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? $ [ -f tmp/sym-link ] echo true true Symlinks originated in BSD. GNU is implementing previously existing behavior. It is a BSD feature that migrated to System V and then to GNU and elsewhere. The behavior is now standardized by POSIX so that it will always be the same everywhere and it is possible to write portable scripts that behavior the same everywhere. 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. If you have an application that needs to know if something is a symlink then then you will need to test for that case explicitly. Since this is a question and not a bug in bash it would be better discussed in the help-b...@gnu.org mailing list instead. Please send future use discussion there. Thanks. Bob
Re: Does [ -f FILE ] have a bug on testing a symlink ?
On Mon, Feb 09, 2015 at 09:00:12PM +, Cheng Rk wrote: To bug-bash@gnu.org: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? $ [ -f tmp/sym-link ] echo true true Symlinks are transparent for most purposes, and in your case the test is against the file pointed to by the symlink. If you want to test the symlink itself you can use the -h or -L test operators.
Re: Does [ -f FILE ] have a bug on testing a symlink ?
from bash(1): Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself. On Mon, Feb 9, 2015 at 1:00 PM, Cheng Rk crq...@ymail.com wrote: To bug-bash@gnu.org: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? $ [ -f tmp/sym-link ] echo true true
Re: Does [ -f FILE ] have a bug on testing a symlink ?
On Mon, Feb 09, 2015 at 09:00:12PM +, Cheng Rk wrote: -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? $ [ -f tmp/sym-link ] echo true true It's supposed to work this way. -f resolves symlinks and tests the target location. If you want to determine whether something is a symlink, you need to test that explicitly with -L or -h. imadev:~$ ln -s /etc/passwd linktopasswd imadev:~$ [ -f linktopasswd ] echo true true imadev:~$ [ -L linktopasswd ] echo true true Similarly, to test for a dangling symlink, you need to apply at least two separate tests: imadev:~$ ln -s nosuchthing dangling imadev:~$ [ -f dangling ] echo true imadev:~$ [ -L dangling ] echo true true
Re: Does [ -f FILE ] have a bug on testing a symlink ?
Cheng Rk crq...@ymail.com writes: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? (bash) Bash Conditional Expressions:: Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: Does [ -f FILE ] have a bug on testing a symlink ?
2015-02-09 22:00 GMT+01:00 Cheng Rk crq...@ymail.com: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? $ [ -f tmp/sym-link ] echo true true The manual has this in addition: «Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself.» http://www.gnu.org/software/bash/manual/bashref.html#Bash-Conditional-Expressions Probably wouldn't hurt to include that in the help text for the test builtin as well. -- Geir Hauge
Does [ -f FILE ] have a bug on testing a symlink ?
To bug-bash@gnu.org: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? $ [ -f tmp/sym-link ] echo true true
Re: Does [ -f FILE ] have a bug on testing a symlink ?
On 2/9/15 4:00 PM, Cheng Rk wrote: To bug-bash@gnu.org: According this documentation `help test`, I am expecting it should return false on anything other than a regular file, -f FILETrue if file exists and is a regular file. but why it returned true on a symlink to a regular file? $ [ -f tmp/sym-link ] echo true true This is fundamental to how symbolic links work. Unless you test specially for a symlink and use system calls like lstat and readlink to obtain values, system calls that operate on filenames follow symbolic links (open, stat, etc.). The bash man page notes this: Unless otherwise specified, primaries that operate on files follow symbolic links and operate on the target of the link, rather than the link itself. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Does [ -f FILE ] have a bug on testing a symlink ?
On Monday, February 9, 2015 3:13 PM, Andreas Schwab sch...@linux-m68k.org wrote: Cheng Rk crq...@ymail.com writes: Then the builtin test help need a documentation fix, right? You're addressing different lines but I am saying this line is inaccurate, right? -f FILETrue if file exists and is a regular file. Is there really a simple regular file test existing? test: test [expr] Evaluate conditional expression. Exits with a status of 0 (true) or 1 (false) depending on the evaluation of EXPR. Expressions may be unary or binary. Unary expressions are often used to examine the status of a file. There are string operators and numeric comparison operators as well. The behavior of test depends on the number of arguments. Read the bash manual page for the complete specification.
Re: Does [ -f FILE ] have a bug on testing a symlink ?
On Monday, February 9, 2015 1:59 PM, Andreas Schwab sch...@linux-m68k.org
wrote:
According this documentation `help test`, I am expecting it should return
false on anything other than a regular file,
-f FILETrue if file exists and is a regular file.
but why it returned true on a symlink to a regular file?
(bash) Bash Conditional Expressions::
Unless otherwise specified, primaries that operate on files follow
symbolic links and operate on the target of the link, rather than the
link itself.
Andreas.
Then the builtin test help need a documentation fix, right?
For some purpose, I need to make sure the file is regular (like for creating
archives); will have to do something like this?
[ -f tmp/sym-link ] {
[ -h tmp/sym-link ] echo do something to break the symlink
}
do something to break link
Re: Does [ -f FILE ] have a bug on testing a symlink ?
Cheng Rk crq...@ymail.com writes: Then the builtin test help need a documentation fix, right? test: test [expr] Evaluate conditional expression. Exits with a status of 0 (true) or 1 (false) depending on the evaluation of EXPR. Expressions may be unary or binary. Unary expressions are often used to examine the status of a file. There are string operators and numeric comparison operators as well. The behavior of test depends on the number of arguments. Read the bash manual page for the complete specification. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
