On 10/08/2025 02:04, Collin Funk wrote:
Collin Funk <collin.fu...@gmail.com> writes:
Pádraig Brady <p...@draigbrady.com> writes:
Done, v2 attached.
Looks good.
Pushed, thanks to you and Dmitry for the review.
Leaving this bug open for realpath. I'll have a look at that as well,
just requires some more reading than readlink did. :)
It looks like 'realpath -E' is the same as Coreutils 'readlink -f', and
default behavior of Coreutils 'realpath'. POSIX us to keep our default
behavior [1]:
If no options are specified, realpath shall canonicalize the specified
pathname in an unspecified manner such that the resulting absolute
pathname does not contain any components that refer to files of type
symbolic link and does not contain any components that are dot or
dot-dot.
Here is a proposed patch.
I don't love having 'realpath -E' and 'readlink -f' with the same long
option name, but having the same functionality with a different long
option name seems worse.
Collin
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/realpath.html
Logic looks good.
The --help for -E is too wordy I think.
I would squash this in instead.
thanks!
Padraig
diff --git a/src/realpath.c b/src/realpath.c
index b06e5e845..1f7882b49 100644
--- a/src/realpath.c
+++ b/src/realpath.c
@@ -72,11 +72,8 @@ usage (int status)
Print the resolved absolute file name.\n\
"), stdout);
fputs (_("\
- -E, --canonicalize canonicalize by following every symlink in\n\
- every component of the given name recursively;\
+ -E, --canonicalize all but the last component must exist (default)\
\n\
- all but the last component must exist\n\
- (this is the default)\n\
-e, --canonicalize-existing all components of the path must exist\n\
-m, --canonicalize-missing no path components need exist or be a directory\
\n\
