On 16/10/2017 12:28, João Eiras wrote:
On 16 October 2017 at 13:23, João Eiras <joao.ei...@gmail.com> wrote:
Howdy.
An issue bit me recently. Consider the following:
$ cd
$ mkdir -p realfolder/subfolder
$ ln -s realfolder linkedfolder
$ cd linkedfolder
$ realpath --no-symlinks blah
/home/.../realfolder/blah
$ cd subfolder
$ realpath --no-symlinks blah
/home/.../linkedfolder/subfolder/blah
The first call to realpath resolves the relative path to "blah" to be
an absolute path, but it is resolving symlinks for the current working
folder (.) even though --no-symlinks is given.
The second call happens inside a subfolder, not directly inside the
linked folder and realpath is no longer resolving the symlinks for
that one.
I forgot to tell, I tried the above in cygwin with coreutils 8.26
Meanwhile I tried in linux with coreutils 8.25 and I get
$ cd linkedfolder
$ realpath --no-symlinks blah
/home/.../realfolder/blah
$ cd subfolder
$ realpath --no-symlinks blah
/home/.../realfolder/subfolder/blah
So, in this case (linux and coreutils 8.25) the behavior is
consistent, but it still resolves symlinks against the --no-symlinks
option.
Is this by design ?
I agree that it is confusing.
What's happening is that for relative paths realpath(1)
is getting the physical rather than logical current working dir.
I.e. it's using getcwd() rather than getenv("PWD").
This issue was also mentioned in:
https://github.com/coreutils/coreutils/issues/49
One can get the behavior you want by passing appropriate absolute paths to
realpath(1):
realpath -s $(pwd -L)/blah
Though that's not ideal as pwd could fail,
or one might want to process many paths like:
find ... | realpath
So how might we provide such control to realpath(1)?
It already has -L and -s options that could control this.
Currently -L and -s are separate options, with the last one taking precedence.
It would be great if we could use (a combination of) existing options
to behave as you want, though I don't see a way to cater for all
cases with existing options.
For e.g. we could adjust when both -L and -s are specified to
use the logical cwd and behave as you expect.
But then there would be no option if one wanted to use a physical cwd,
with current behavior of -L.
Also if we adjusted --no-symlinks to imply using the logical cwd,
while it has some merit, there is no option if you wanted to not resolve
symlinks relative to the physical cwd.
So to support this we would need new options I think. Perhaps:
--logical-cwd
Base relative paths on PWD from environment, even if it contains symlinks
--physical-cwd
Base relative paths on the resolved working directory (default)
thanks,
(and sorry for the delay).
Pádraig
