bugfindutils - Bugs: bug #10952, find lacks support for POSIX -L...

 
 

bug #10952: find lacks support for POSIX -L and -H options

Submitted by:  Geoff Clare <geoffclare>
Submitted on:  Tue 09 Nov 2004 11:50:18 AM UTC  
 
Category:  find Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  James Youngman <jay>
Originator Name:  Open/Closed:  Closed
Release:  4.2.4 Fixed Release:  4.2.5

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Fri 12 Nov 2004 12:11:42 AM UTC, comment #4: 

I've also now implemented BSD's -P option (which in any case corresponds to the default behaviour).

James Youngman <jay>
Project AdministratorIn charge of this item.
Thu 11 Nov 2004 09:10:56 PM UTC, comment #3: 

I have now implemented this as specified in the POSIX standard, I believe.   This includes a change in functionality.   Up to now, symlinks specified as arguments (e.g. to -newer) were not dereferenced unless they came after -follow.  With this change they will always be dereferenced (since -H makes an exception for items on the command line)

James Youngman <jay>
Project AdministratorIn charge of this item.
Thu 11 Nov 2004 03:13:00 PM UTC, comment #2: 

Regarding "--", yes you are right.  The point is to be able to use e.g. "find -- -L -print" to search a directory called -L.

Your description of how to handle -H seems right as far as the treatment of dangling symlinks goes, but it sounds like you missed the significance of the words "on the command line" in POSIX.  With -H, only symlinks specified on the command line are followed; symlinks encountered when reading directories are not followed.  (With -L, all symlinks are followed.)

Geoff Clare <geoffclare>
Wed 10 Nov 2004 11:31:38 PM UTC, comment #1: 

Thanks for this.  Re-reading the POSIX spec I can't see for sure how "--" should be interpreted.  Should I interpret anything following the first occurrence of "--" as being the first path argument?

I believe that we can implement -H by writing a special function hstat() which first tries stat() and then calls lstat() iff the stat() call fails for any reason.  We then just point xstat at hstat() to implement -H.  Or did I miss a subtlety?

James Youngman <jay>
Project AdministratorIn charge of this item.
Tue 09 Nov 2004 11:50:18 AM UTC, original submission:  

The current POSIX standard specifies -L and -H options for find, to control handling of symbolic links.

For now I imagine you will just want to document the omission, as you have done for "-exec command {} +".  It would be good if support could be added in a later release.  The command line argument parsing will need to change (these are "real" options that come before the pathnames to be searched, and the "--" delimiter will also need to be supported).  Once that is done, supporting -L would be trivial (just set the dereference and xstat globals as for -follow), but supporting -H would need more work.  Note that these options override each other, e.g. -H -L is equivalent to just -L, and -LH is equivalent to -H.

Geoff Clare <geoffclare>

 

(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

 

CC list is empty

 

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.

 

 

 

Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-11-19 jay Open/ClosedOpen => Closed
    Fixed ReleaseNone => 4.2.5
2004-11-12 jay StatusNone => Fixed
    Assigned toNone => jay

Back to the top


Powered by Savane 3.5