bug#62385: POSIX behavior of readlink, realpath

Hi,

On Sat, Aug 02, 2025 at 09:33:15PM -0700, Collin Funk wrote:
> Hi Eric,
> 
> You said:
> 
> > Among other things, I can see the following changes that coreutils
> > will need to make to become compliant, or else we need to push back on
> > the POSIX folks if we have strong reasons to complain that their
> > specification will break things:
> >
> > POSIX wants 'readlink non-symlink' to output a diagnostic; that is, it
> > looks like POSIX wants us to behave like '-v' is enabled by default
> > (our current behavior of -q by default will be non-compliant).
> 
> I have attached a patch that I think is correct for readlink.
> 
> It is a bit more complex than just behaving the same as 'readlink -v'
> previously would. This is because the behavior of non-POSIX
> options. Here are some commands:
> 
>     $ touch file
>     $ ln -s symlink file
>     
>     # Example 1
>     $ readlink -v file
>     readlink: file: Invalid argument
> 
>     # Example 2
>     $ readlink -v -f file 
>     /home/collin/file
> 
> If 'readlink -v' where 'POSIXLY_CORRECT=1 readlink' then example 1 would
> conform. I think that example 2 would violate POSIX.

Given that -f is not in POSIX, I don't see why the example 2 would violate
it.

> So, when POSIXLY_CORRECT is enabled we can call 'readlink', check for
> errors, and then canonicalize if it is successful.

I'd argue that such a change of readlink -e/-f/-m behaviour makes little
sense as it defeats the purpose of these options.


-- 
ldv