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

 
 

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

Submitted by:  Ruvim <ruv>
Submitted on:  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:  James Youngman <jay>
Originator Name:  Open/Closed:  Open
Release:  None Fixed Release:  None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( 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>
Project AdministratorIn charge of this item.
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'

and

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>
Project AdministratorIn charge of this item.
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:
   
   
Comment:
   

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    Thu 30 Nov 2017 05:14:04 PM UTC jay StatusNone => Working as Intended
        Assigned toNone => jay

    Back to the top


    Powered by Savane 3.3