bugfindutils - Bugs: bug #66568, document whether find's -execdir...

 
 

bug #66568: document whether find's -execdir option is guaranteed to produce pathnames that start with ./

Submitter:  Christoph Anton Mitterer <calestyo>
Submitted:  Tue 17 Dec 2024 01:53:21 AM UTC
   
 
Category:  documentation Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  berny
Originator Name:  Open/Closed:  Open
Release:  None Fixed Release:  4.11.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 24 Dec 2024 09:21:08 PM UTC, comment #4: 

Thanks for merging.

I think it would be good if the status of `/` in -execdir could be clarified before a release is made with my documentation patch, because now we in principle "promise" that it's the way as documented and people may actually start to rely on this.

Christoph Anton Mitterer <calestyo>
Tue 24 Dec 2024 02:15:37 PM UTC, comment #3: 

Thanks - pushed with some minor tweaks, e.g. the commit message shall state which files have been touched.
I also pushed two other minor changes:

  • [PATCH 3/3] doc: state that -execdir prepends the base names with "./"

  https://git.sv.gnu.org/cgit/findutils.git/commit/?id=a78812c62e7

  • [PATCH 2/3] doc: maint: break lines at sentences in a paragraph to change

  https://git.sv.gnu.org/cgit/findutils.git/commit/?id=1da19bdba76

  • [PATCH 1/3] maint: fix typo in comment

  https://git.sv.gnu.org/cgit/findutils.git/commit/?id=00e82f2c15f

> Just out of curiosity, why does it handle `/` specially?


Good question.

Searching in the git history, this was added (and later only modified) in commit [1]
back in 2005.  The intention was to use suffix "./" unless for absolute file names.

[1] https://git.sv.gnu.org/cgit/findutils.git/commit/?id=74a750b11fba

Then in 2010, there was then the change in commit [2] as a fix for  for bug #27563
(-L breaking -execdir).  That changed slightly the logic, as it first applies
base_name(), and then checks whether the result is starting with "/" or not.
Obviously, that is then only true for the root directory "/".

[2] https://git.sv.gnu.org/cgit/findutils.git/commit/?id=e1d0a991e96e

Maybe James would remember why exempting the root directory from
prefixing with "./" would be useful.  Looking at this test file,
there was a bug report for exactly "/" as starting point:

https://git.sv.gnu.org/cgit/findutils.git/tree/find/testsuite/find.gnu/execdir-root-only.exp?h=v4.10.0

Bernhard Voelker <berny>
Group administrator
Thu 19 Dec 2024 01:11:39 AM UTC, comment #2: 

I'd have attached a patch fir git am, which would add a small sentence for both, manpage and tex doc (I don't have tex installed, and was too lazy to do it... so please check whether my markup there is right).

This only documents the behaviour for -execdir, not for -exec (which I guess is as POSIX specifies?)... maybe that should be done, too?

Just out of curiosity, why does it handle `/` specially?

Thanks,
Chris.

(file #56706)

Christoph Anton Mitterer <calestyo>
Tue 17 Dec 2024 12:12:11 PM UTC, comment #1: 

The '{}' replacement of -execdir prefixes with "./" in cases
but this only exception:

find / -maxdepth 0  -execdir echo '{}' \;
/


See 'impl_pred_exec' in exec.c:
https://git.savannah.gnu.org/cgit/findutils.git/tree/find/exec.c?h=v4.10.0#n127

Would you like to suggest a better wording for the documentation?

Bernhard Voelker <berny>
Group administrator
Tue 17 Dec 2024 01:53:21 AM UTC, original submission:  

Hey.

I hope I haven't just overlooked it, but it's seems that it's not specified whether or not the pathnames generated by -execdir are guaranteed to start with `./`.

For -exec, POSIX defines that the resulting pathnames are (simplified) prefixed with their respective starting point, but -execdir is not POSIX and one cannot really apply the general rules for -execdir, as that obviously needs to give pathnames relative to the respective directory.

The current implementation seems to do so, i.e. it always generates relative pathnames that start with ./ but that doesn't seem to be "promised" to ever stay that way.

Would be nice if that could be mentioned, because then one can be sure that pathnames from -execdir cannot be mistaken as options (at least not with commands, that don't treat arguments that start with ./ as option).


Thanks,
Chris.

Christoph Anton Mitterer <calestyo>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by calestyo (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-12-24 berny Fixed ReleaseNone 4.11.0
    2024-12-24 berny StatusConfirmed Fixed
    2024-12-19 calestyo Attached File- Added 0001-doc-state-that-execdir-pathnames-are-prepended-with.patch, #56706
    2024-12-17 berny CategoryNone documentation
        StatusNone Confirmed
        Assigned toNone berny

    Back to the top

    Powered by Savane 3.14-9aa3.
    Corresponding source code