bugfindutils - Bugs: bug #52558, find does not print symlink object...


bug #52558: find does not print symlink object in case of follow symbolic links

Submitter:  Ruvim <ruv>
Submitted:  Thu 30 Nov 2017 11:15:09 AM UTC
Category:  find Severity:  3 - Normal
Item Group:  None Status:  Working as Intended
Privacy:  Public Assigned to:  jay
Originator Name:  Open/Closed:  Open
Release:  None Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sat 02 Dec 2017 03:06:57 PM UTC, comment #8: 

It seems obvious that all the operations after -follow are affected by this -follow and are fully processed.

The question is why the operations before -follow are affected by it? It seems to be a bug.

Another question that can arise — what about parentheses? Conceptually the effect of -follow should be limited by the outer parentheses (if any).

Ruvim <ruv>
Sat 02 Dec 2017 11:33:52 AM UTC, comment #7: 

The documentation is a bit confusing. 

What it is trying to describe is that after -follow is seen, symlinks will be followed, so that for example symbolic links will be followed when setting up the test for-newer if that is after -follow.

All -printf and similar operations occur after the command line has been fully processed, so -follow always affects them even if the ordering on the command line was -follow ... -printf ...

I will clarify the documentation soon.

James Youngman <jay>
Group administrator
Fri 01 Dec 2017 08:22:39 AM UTC, comment #6: 

misprint: "if 'b' is directory" should be read as "if 'a' is directory".

Ruvim <ruv>
Fri 01 Dec 2017 08:20:06 AM UTC, comment #5: 

@worley, nevertheless in some cases the results can be different: for example, if 'b' is directory that contains another symlinks "x" and "y" that point to some files, the result with -follow could be:

./b -- a
./b/x -- x1
./b/y -- y1

It should be so because there always exists hidden action  "process the directory content", and when a symlink is dereferenced to a directory, this action should be applied.

Ruvim <ruv>
Fri 01 Dec 2017 02:38:49 AM UTC, comment #4: 

This is an odd case.  But

find . -type l -printf '%p -- %l\n'


find . -type l -printf '%p -- %l\n' -follow

should always produce the same results, since -follow only affects things after it on the command line.

But (with find 4.5.11), if I have a link ./b that points to a, I get:

$ find . -type l -printf '%p -- %l\n'
./b -- a
$ find . -type l -printf '%p -- %l\n' -follow

Dale Worley <worley>
Thu 30 Nov 2017 08:48:43 PM UTC, comment #3: 

Yes, in case of -L option the behavior conforms the documentation. I just said that it seems not so useful (and maybe unexpected without careful investigation of the documentation).

But what about -follow option that is after -print and after -type test? For me, in such case the behavior of -print and -type contradicts the documentation.

"The -daystart, -follow and -regextype options  are  different  in  this  respect,  and  have an effect only on tests which appear later in the command line"

But currently -follow option has effect on the -type and -print which appear before it in the command line!

Certainly one can say that "-print" is not a test, but an action.  Actually, it doesn't matter. General respect for the position of -follow option (for actions as well as for tests) is desirable behavior that doesn't contradict the documentation and conforms the spirit and idea of the positional options.

Ruvim <ruv>
Thu 30 Nov 2017 05:14:04 PM UTC, comment #2: 

"""%l     Object of symbolic link (empty string if file is not a symbolic link)."""

When -L is in effect, find follows symbolic links.

The %l format specifier shows the target of the symbolic link find is examining. But the file find is examining is not a symbolic link in this case, since find has already resolved the link - it is examining the file the link points to (unless the link is broken).  Hence %l must expand to the empty string:

James Youngman <jay>
Group administrator
Thu 30 Nov 2017 02:48:34 PM UTC, comment #1: 

Perhaps in case of -follow option (and without -L) the consistent way should be:
<pre>find . -type l -printf '%p -- %l\n' -follow</pre>
I.e. -type in place of -xtype  (for the moment it doesn't work).

Because the only options after -follow should consider the object of symlink, but all the options before -follow should consider the symlink itself.

Citation from the manual:

1. "any symbolic links appearing after -follow on the command line will be dereferenced, and those before it will not"

2. "Similarly, the -type predicate will always match against the type of the file that a symbolic link points to rather than the link itself."

So, -type before -follow should match against type of the file itself.

Ruvim <ruv>
Thu 30 Nov 2017 11:15:09 AM UTC, original submission:  

It seems that it is reasonable expectation that the command:

  find -L . -xtype l -printf '%p -- %l\n'

or at least the command:

  find . -xtype l -printf '%p -- %l\n' -follow

should produce the same result as the command:

  find -L . -xtype l -printf '%p -- ' -exec readlink {} \;

For the moment, %l produces empty string for any valid (non broken and reachable) symbolic link in case of -L option is given. Although it seems not useful, this behavior does not contradict the documentation.

But why does %l produce empty string for valid symlink in case when -follow option is used after -printf action? Сonceptually printf should consider not the object of symlink but the symlink itself in such case.

This issue was tested on version 4.7.0

Ruvim <ruv>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by worley (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by ruv (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-11-30 jay StatusNone Working as Intended
        Assigned toNone jay

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code