-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
osx_cc_wrapper.sh:get_realpath is buggy for relative uplevel symlinks #1776
Comments
@damienmg : FYI |
Neither `realpath` nor `readlink -e` are available on Mac OS X, so I implemented one using basic Bash utilities: `readlink`, `basename`, and `dirname`. I also implemented a `normalize_path` method that can normalize relative or absolute path strings (remove and resolve "." and ".." references). It uses simple string processing and doesn't touch the file system. This will help fixing #1776 and also opensourcing some shell tests that rely on `realpath`. -- MOS_MIGRATED_REVID=133249912
To clarify, does this issue say that osx_cc_wrapper should use get_real_path from cf773d2? |
That'd be better, yes, though it wouldn't be perfect. The |
I see. Thanks for clarification. |
Status update: I'm not working on this issue and probably won't work on it in Q2'18. |
Is this still an issue? |
Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so. |
If we have the following directory tree:
Then all symlinks ultimately point to
hello.txt
, yetget_realpath a/b/c/c.sym
will return../b.sym
.I have a fix for this as part of opensourceing some shell integration tests.
The text was updated successfully, but these errors were encountered: