Skip to content
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

Closed
laszlocsomor opened this issue Sep 15, 2016 · 7 comments
Closed
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-CPP Issues for C++ rules type: bug

Comments

@laszlocsomor
Copy link
Contributor

If we have the following directory tree:

./a/a.sym -> ../hello.txt
./a/b/b.sym -> ../a.sym
./a/b/c/c.sym -> ../b.sym
./hello.txt

Then all symlinks ultimately point to hello.txt, yet get_realpath a/b/c/c.sym will return ../b.sym.

I have a fix for this as part of opensourceing some shell integration tests.

@laszlocsomor laszlocsomor added type: bug P2 We'll consider working on this in future. (Assignee optional) category: misc > misc labels Sep 15, 2016
@laszlocsomor laszlocsomor self-assigned this Sep 15, 2016
@laszlocsomor
Copy link
Contributor Author

@damienmg : FYI

bazel-io pushed a commit that referenced this issue Sep 15, 2016
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
@damienmg damienmg added this to the 0.6 milestone Nov 11, 2016
@laszlocsomor laszlocsomor changed the title os_cc_wrapper.sh:get_realpath is buggy for relative uplevel symlinks osx_cc_wrapper.sh:get_realpath is buggy for relative uplevel symlinks Jul 25, 2017
@hlopko
Copy link
Member

hlopko commented Sep 4, 2017

To clarify, does this issue say that osx_cc_wrapper should use get_real_path from cf773d2?

@laszlocsomor
Copy link
Contributor Author

That'd be better, yes, though it wouldn't be perfect. The get_real_path in is not a real realpath: get_real_path just follows symlinks until it can't any further, resolving only the last segment of the path and may leave upper-level components as symlinks. The real realpath resolves all segments of a path so the result doesn't contain any symlinks.

@hlopko
Copy link
Member

hlopko commented Sep 5, 2017

I see. Thanks for clarification.

@hlopko hlopko modified the milestones: 0.7, 0.6 Sep 13, 2017
@laszlocsomor
Copy link
Contributor Author

laszlocsomor commented May 16, 2018

Status update: I'm not working on this issue and probably won't work on it in Q2'18.

@hlopko hlopko added team-Rules-CPP Issues for C++ rules and removed category: rules > C++ labels Oct 11, 2018
@meisterT
Copy link
Member

Is this still an issue?

@meisterT meisterT removed this from the 0.7 milestone May 12, 2020
@c-mita c-mita added P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed P2 We'll consider working on this in future. (Assignee optional) labels Nov 24, 2020
@sgowroji
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Rules-CPP Issues for C++ rules type: bug
Projects
None yet
Development

No branches or pull requests

6 participants