URL: <https://savannah.gnu.org/bugs/?66568>
Summary: document whether find's -execdir option is
guaranteed to produce pathnames that start with ./
Group: findutils
Submitter: calestyo
Submitted: Tue 17 Dec 2024 01:53:21 AM UTC
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: None
Fixed Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Tue 17 Dec 2024 01:53:21 AM UTC By: Christoph Anton Mitterer <calestyo>
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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66568>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
