GetComponents places KadathThorn inside repos/KadathThorn instead of Cactus/repos/KadathThorn

[Zach Etienne]

Checking out the latest development ET, via

curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/master/GetComponents
chmod a+x GetComponents
./GetComponents --parallel --shallow https://bitbucket.org/einsteintoolkit/manifest/raw/master/einsteintoolkit.th

without errors, I get the following directory listing:

Cactus  einsteintoolkit.th  GetComponents  repos

notice the repos at the end. Looks strange! Listing the directories in it, I find:

KadathThorn/

‌

There’s clearly something wrong with GetComponents.

[Roland Haas]

Grr. The issue is very confusing. It boils down to how cd acts. One would assume that it just passes its given path to the os’s cwd call. But no. That is not what is does. It tries to first contract the string (acts on .../). To get reproducible behaviour one must pass the -P option to a (POSIX confirming) cd command. See https://unix.stackexchange.com/a/55715 and https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html Otherwise (depending on the shell that actually provides sh) one can end up with:

$ ls Cactus/arrangements/Fuka/KadathThorn/src/fuka/../../../../repos/KadathThorn/src/fuka/
foo
$ cd Cactus/arrangements/Fuka/KadathThorn/src/fuka/../../../../repos/KadathThorn/src/fuka/
sh: 23: cd: can't cd to Cactus/arrangements/Fuka/KadathThorn/src/fuka/../../../../repos/KadathThorn/src/fuka/
$ cd -P Cactus/arrangements/Fuka/KadathThorn/src/fuka/../../../../repos/KadathThorn/src/fuka/
$ ls
foo

Not sure how to fix this without changing GetComponents code. I am somewhat reluctant to change GetComponent’s code to add an (obscure?) option to its cd which then eg BSD cd on OSX does not support…

[Roland Haas]

Not a bug in Kadath but one in GetComponents

[Roland Haas]

I could not find a way that would avoid using cd -P and also needed to add a realpath call to the code that computes relative paths (thankfully at that point all directories are in place I think).

Pull request is here:

https://github.com/gridaphobe/CRL/pull/12

[Roland Haas]

Please review.

[Roland Haas]

This will require a full test on all clusters. Might just as well then also include #2721 which I would actually expect to be less likely to cause issues.

[Roland Haas]

Tested on OSX and Linux and seems to work ok there. This should cover all relevant OS (only other that would come to mind might be Windows with mingw but that is not really workable anyway due to failing to compile the code for other reasons).

[Roland Haas]

If someone could review this, please? This is urgent and would block the release.

[Roland Haas]

@Samuel Cupp @Leonardo Werneck @Steven R. Brandt could you take a look, please?

[Roland Haas]

@Steven R. Brandt says “Please apply” in pull request.

Applied as git hash b870f78 "GetComponents: construct relative paths based on physical location" of CRL