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: findSeverity: 3 - Normal
Item Group: NoneStatus: Working as Intended
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Open/Closed: Open
Release: NoneFixed 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 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to 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 UTCjayStatusNone=>Working as Intended
      Assigned toNone=>jay

    Back to the top


    Powered by Savane 3.1-cleanup1