Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
As shown below, /bkup/bkup/common is linked (symbolic) to /comm. Two search commands (with or without tailing slash at search path) work differently. Without slash, empty result. With slash, correct result.
I think it is a kind of symlink related rule. I am looking for the documentation.
I have found in wikipedia (under symbolic link) following:
The POSIX directory listing application, ls, denotes symbolic links with an arrow after the name, pointing to the name of the target file (see following example), when the long directory list is requested (-l option). When a directory listing of a symbolic link that points to a directory is requested, only the link itself will be displayed. In order to obtain a listing of the linked directory, the path must include a trailing directory separator character ('/', slash).
It looks related.
Can anybody direct me to correct documentation? So that I will not have further confusion in future. Also, I can avoid error-prone directory structure.
Thank you for your reading my post and I apologyze my disorganized directory tree.
Last edited by kaz2100; 05-29-2012 at 01:58 AM.
Here is something that may be relevant in the documentation:
If the named file is in fact a symbolic link, and the -P option is in effect (or if neither -H nor -L were specified), the information used for the comparison will be taken from the properties of the symbolic link. Otherwise, it will be taken from the properties of the file the link points to.
To me, this says that if you haven't used -H or -L, then the symbolic link will not be followed. Of course, when you added a tailing / then it was followed, I can't find exact documentation to know this behavior though.
Last edited by CincinnatiKid; 05-28-2012 at 10:00 PM.
For that case, the find command never sees the symlink. When find calls lstat("/bkup/bkup/common/"), the trailing '/' tells the kernel that a directory is required, so the kernel follows the symlink and returns the data for the target directory. Without that trailing '/', the lstat() call returns the data for the symlink itself, and to get to the directory the find command would have to ask for the symlink to be followed (calling stat() instead of lstat()), and find won't do that unless you've used the "-L" flag.
Probably, in fact almost certainly -- just not anywhere that I know of. Some time ago I did some poking around with strace and wrote some simple test programs to piece together how it all appears to work.
Thanks a lot. This behavior may change in future, I guess. I will keep my eyes open.
Have a nice Penguin!
It makes since how it works, because one might want to know the attributes of the soft link itself and not what it links to, this is precisely why it behaves like it does. There are other commands that work exactly the same way, for example, what would you expect this to do?
ln -s test/ link
rm -rf link
obviously this will remove the link, not what it links to. But if you add a trailing slash, it will delete what it links to, for example this:
ln -s test/ link
rm -rf link/
In the example above, because of the trailing slash, it will delete what is linked to, and not the symlink. So, this is normal behavior with pretty much all of the GNU/Linux utilities.