Created attachment 913092 [details] the fix Description of problem: -s option of realpath does not seem to work. If you have /bin -> /usr/bin, realpath -s will still resolves the symlink. Version-Release number of selected component (if applicable): coreutils-8.21-13.fc19.x86_64 How reproducible: easily Steps to Reproduce: 1. cd /bin; realpath -s . Actual results: /usr/bin Expected results: /bin Additional info: Fix attached. By the way, can someone please tell me what does -L option do? How does it differ from -P?
This is a subtle one, and essentially due to the difference between "cwd" and "pwd". realpath is working on the path provided correctly, with "." referring to "cwd". With /bin symlinked to /usr/bin, after one changes to /bin you really are in the /usr/bin directory. I.E. the current working directory '.' refers to /usr/bin $ cd /bin $ readlink /proc/$$/cwd /usr/bin Other ways to determine the real path are: $ pwd -P /usr/bin $ realpath . /usr/bin $ echo "import os; print os.getcwd()" | python /usr/bin Now what you're suggesting is that realpath should be aware of "pwd", i.e. the $PWD env variable of the current shell. The portable way to determine that is: $ pwd -L /bin You're implying that realpath -L should also honor $PWD. The readlink -P and -L options currently only affect the symlink and .. resolution order, matching the functionality of cd -P and -L: /$ cd / /$ cd -P /bin/.. usr$ cd / /$ cd -L /bin/.. /$ I suppose one could also make -L honor $PWD ? I.E. prepend $PWD to relative paths before further processing. That also matches the current symlink resolution order behavior. With that in place you could get what you wanted with: $ realpath -sL . /bin Now you really wouldn't want to complicate the interface and implementation of realpath unless there was a good use case for resolving relative paths like this. That would only be needed if you wanted to resolve a mixture of relative and absolute paths, as you can already resolve multiple relative paths like this quite easily: $ realpath -s $PWD/{one,two} /bin/one /bin/two Could you give more details on your use case? thanks
This is a discussion we should be having upstream BTW. Stas, could you copy you're initial query to coreutils and I'll respond there.
Thanks for the detailed explanation. In fact I wasn't properly realizing that getcwd() and readlink /proc/$$/cwd all return not what was provided to chdir() because the symlink is already dereferenced by chdir(). > The readlink -P and -L options currently only affect the symlink and .. I guess you mean realpath, not readlink. > Could you give more details on your use case? There is currently none. And I agree that -s alone should not use $PWD, but -sL may. Feel free to close this if you think -sL is unimportant.
Tracking this upstream. Though not sure yet if we'll change
Just pointer to the upstream thread : http://lists.gnu.org/archive/html/coreutils/2014-06/msg00087.html .