bugfindutils - Bugs: bug #61501, find -execdir wrong root item path

 
 

bug #61501: find -execdir wrong root item path

Submitter:  None
Submitted:  Wed 17 Nov 2021 04:39:21 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Working as Intended
Privacy:  Public Assigned to:  berny
Originator Name:  Skeleton Zombie Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  None
Fixed Release:  4.8.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 27 Nov 2021 11:55:18 PM UTC, comment #3: 

Thanks for confirming.  I'm hereby closing this issue in our bug tracker.

Have a nice day,
Berny

Bernhard Voelker <berny>
Group administrator
Thu 18 Nov 2021 05:45:41 PM UTC, comment #2: 

You are right,
the result is correct.

Maybe the man-page confused me, saying
"command is run from the SUBdirectory containing the matched file",
since "/" is not a subdirectory of "/foo".

I have forgotten to look at the working directory, too.

I expected the paths to be normalized somehow,
but apparently only correctness by function is intended.
(Well, only the root item has an awkward path.)

Thanks for clarifying it.

Skeleton Zombie <zombie>
Wed 17 Nov 2021 11:12:23 PM UTC, comment #1: 

Thanks for the report, but what is exactly wrong with those entries?

For a better comparison, here's the complete reproducer.
The 'find' command line prints out 4 lines per item:
1. the full argument (%p),
2. the working directory for -execdir,
3. the replacement value for the argument '{}' for -execdir, and
4. the replacement value for the argument '{}' for -exec.


$ mkdir /foo && cd /foo && touch apple banana

$ find . -printf '1:%p\n'  -execdir pwd ';' -execdir printf '2:%s\n' '{}' ';' -exec printf '3:%s\n\n' '{}' ';'
1:.
/foo
2:./.
3:.

1:./banana
/foo
2:./banana
3:./banana

1:./apple
/foo
2:./apple
3:./apple

$ find /foo -printf '1:%p\n'  -execdir pwd ';' -execdir printf '2:%s\n' '{}' ';' -exec printf '3:%s\n\n' '{}' ';'
1:/foo
/
2:./foo
3:/foo

1:/foo/banana
/foo
2:./banana
3:/foo/banana

1:/foo/apple
/foo
2:./apple
3:/foo/apple


In the first find(1) invocation, it's maybe debatable whether '.' or './.'
is better, still both are correct and properly resolve to the current directory.

The second find(1) invocation shows that the output of './foo' is also correct,
as the working directory is '/'.

Would you please explain what is the problem with that behavior?

Bernhard Voelker <berny>
Group administrator
Wed 17 Nov 2021 04:39:21 PM UTC, original submission:  

find -execdir gives the wrong path for the root item

$ find . -execdir printf '%s\n' '{}' ';'
./.       # expect "."
./apple
./banana

$ find /foo -execdir printf '%s\n' '{}' ';'
./foo     # expect "."
./apple
./banana


for -exec the result is correct

$ find . -exec printf '%s\n' '{}' ';'
.
./apple
./banana

$ find /foo -exec printf '%s\n' '{}' ';'
/foo
/foo/apple
/foo/banana


Thanks and Greetings

Anonymous

 

(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 zombie (Posted a comment)
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by None (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-11-27 berny StatusNeed Info Working as Intended
        Open/ClosedOpen Closed
    2021-11-17 berny StatusNone Need Info
        Assigned toNone berny

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code