Fix incorrect escape sequences during Loads under git-bash#1085
Conversation
|
Any chance to get this reviewed and merged? |
zimbatm
left a comment
There was a problem hiding this comment.
Thanks!
Do you know if direnv edit is affected by the same issue? There is another instance of path escaping in internal/cmd/cmd_edit.go:60
direnv#975 had the unintended consequence of causing the `RC::Load` call to sometimes fail when running under git-bash (and some others Windows specific configs). The `RC::Load` -> `cmd.Output()` calls end up interpreting characters like \b or \t as escape sequences, which is problematic if for paths like 'myProject\buckets\test'. This patch addresses this by forcing the use of `/` as a separator, even on Windows. This works fine in my testing in git-bash. This shouldn't impact systems where `/` is already in use. This also adds a test case that covers the behaviour being adjusted. In order to run the bash tests on Windows, I had to disabled a number that appear to not play nice -- but after hacking those out I was able to verify the new test case. Fixes: - direnv#1020 - direnv#1079
819e11c to
dd16693
Compare
Just had a look and it doesn't seem to cause a bustage there. Example of me dumping the string during edit usage (after which I get an editor as expected): Generally the escaping of Using |
Yes, I think that is correct conclusion. |
|
thanks |
|
I've just packaged the latest release for winget, microsoft/winget-pkgs#107614, and installed it locally. Thanks for the fix! |
|
thanks, can you also try |
|
@zimbatm AFAICT, it works like a charm! I've created path such that if Git.Bash.2023-05-21.22-14-26.mp4 |

#975 had the unintended consequence of causing the
RC::Loadcall to sometimes fail when running under git-bash (and some others Windows specific configs).The
RC::Load->cmd.Output()calls end up interpreting characters like \b or \t as escape sequences, which is problematic for paths like 'myProject\buckets\test'.This patch addresses this by forcing the use of
/as a separator, even on Windows. This works fine in my testing in git-bash. This shouldn't impact systems where/is already in use.This also adds a test case that covers the behaviour being adjusted. In order to run the bash tests on Windows, I had to disable a number that appear to not play nice -- but after hacking those out I was able to verify the new test case.
Fixes: