Closed tekumara closed 2 years ago
Hmm. Strange. Thanks for the bug report. Some questions:
/tmp/setup
directory, or does it occur with all repositories?$SCMPUFF_GIT_CMD
is somehow not properly set. If you get in that state, what does echo $SCMPUFF_GIT_CMD
output? (From looking at your other output, I'm guessing it will return ../../usr/local/bin/git
-- which would be indicative of a problem being a relative path rather than absolute -- but I want to confirm this before debugging further.)Thanks!
Thanks for taking a look!
$ zsh --version
zsh 5.8 (x86_64-apple-darwin20.1.0)
$ echo $SCMPUFF_GIT_CMD
/usr/local/bin/git
Okay, I think I've tracked this down. It's quite weird.
scmpuff expand --relative
. scmpuff expand --relative
takes absolute paths and converts them to relative. As we can see below, it's doing this for the $SCMPUFF_GIT_CMD
as well when it is an absolute path, which is probably undesired.$ export e1=~/src/scmpuff/scripts/benchmark.sh
$ scmpuff expand -- git blah 1
git blah /Users/mroth/src/scmpuff/scripts/benchmark.sh
$ scmpuff expand --relative -- git blah 1
git blah scripts/benchmark.sh
$ scmpuff expand --relative -- /usr/bin/git blah 1
../../../../usr/bin/git blah scripts/benchmark
I suspect since $SCMPUFF_GIT_CMD
was simply git
in the integration test environment I never noticed this?
Now, normally this wouldn't cause execution problems, but...
/tmp
on macOS is actually /private/tmp
, in a way that confuses filepath.Rel()
in Go. See #31 and #11 for additional context. Normally this isn't an issue (the messy paths resolve fine for files), but seems to be causing an issue for finding the git binary here. I believe the switch to scmpuff exec
as default in #49 may make this irrelevant when released, but I'd like to fix the underlying issue anyhow.
When in the directory /tmp/setup on the
master
branch:This works without error: