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

Wrong path name when installing packages on Git Bash for Windows(zsh shell) #121

Closed
benwilburn opened this issue Apr 14, 2023 · 15 comments
Closed

Comments

@benwilburn
Copy link

When attempting to install packages via antidote in Git Bash for Windows, it fails to install packages due to path errors (seems to work fine in WSL). It would be nice to be able to use Antidote in Git Bash

@mattmc3
Copy link
Owner

mattmc3 commented Apr 14, 2023

Git Bash is, by default, Bash. I hate to ask, but can you confirm you are you running Zsh from bash before running antidote, or are you just hoping antidote will work in straight git bash? Antidote is, and will always be, a Zsh-only plugin manager, so I just need to confirm.

@benwilburn
Copy link
Author

benwilburn commented Apr 14, 2023

Yes, I even mentioned it in the title of the issue. I have used oh-my-zsh in git bash (zsh shell) but it is brutally slow.

When I echo the $SHELL variable, it says bash but I have it set to open zsh upon load.

image

@mattmc3
Copy link
Owner

mattmc3 commented Apr 23, 2023

I'm open to see if we can get things working in git bash. I just don't have a Windows machine handy at the moment, so it'll take me a bit to get a test scenario set up to see if I can reproduce this. If so, and it's something that can be addressed within antidote, I'll consider coding a fix.

@DiegoMagdaleno
Copy link

Without any promises I am able to use windows and have some experience with shell programming.

I am on finals but I am pretty sure this is an easy fix.

I'll see if I can fix the issue and submit a pr :)

@DiegoMagdaleno
Copy link

One question to speed things up. Per my understanding it seems like the path used when antidote generates zsh_plugins.zsh is $ANTIDOTE_HOME?

It would be helpful to know this information, as I can just make it point to the right location when on Mingw64

@mattmc3
Copy link
Owner

mattmc3 commented May 15, 2023

This is the function that determines the home: https://github.com/mattmc3/antidote/blob/main/functions/antidote-home

@DiegoMagdaleno
Copy link

Submited a PR!

mattmc3 added a commit that referenced this issue Jun 1, 2023
Use backslash directories when $LOCALAPPDATA uses them
@mattmc3 mattmc3 closed this as completed in e204d91 Jun 7, 2023
@benwilburn
Copy link
Author

benwilburn commented Jun 8, 2023

@mattmc3 I just tried to set it up again and am getting the same issue:
image

In this case, I just tried to utilize the zdotdir project as a template. Not sure if something needs to be done there?

EDIT: did some more experimentation.. and it appears to work fine within git bash but if you're trying to use git bash within vscode, it does not work.

@mattmc3 mattmc3 reopened this Jun 8, 2023
@DiegoMagdaleno
Copy link

@benwilburn can you try using my fork and see if that works?

@marovira
Copy link

marovira commented Jul 19, 2023

I'm also having the same issue as @benwilburn when trying to use antidote in zsh invoked from git bash. If I add the __fix_windows_path function to functions/__antidote_get_cachedir and use it like this:

  local result
  if [[ "${OSTYPE}" == darwin* ]]; then
    result=$HOME/Library/Caches
  elif [[ "${OSTYPE}" == (cygwin|msys)* ]]; then
    result=$(__fix_windows_path ${LOCALAPPDATA:-$LocalAppData}) # <--- Note the change for the path
  elif [[ -n "$XDG_CACHE_HOME" ]]; then
    result=$XDG_CACHE_HOME
  else
    result=$HOME/.cache
  fi

Then the issue is fixed and antidote works correctly. Could the fix by @DiegoMagdaleno be merged in @mattmc3?
I can also make a fork with my fix and submit a PR if that works better

@mattmc3
Copy link
Owner

mattmc3 commented Jul 19, 2023

I can't merge that in without a good way to test it into the future, so what I'm really held up by is making sure there's a CI workflow to verify this works. I don't run Windows personally, so I have no way to see that this is working without that workflow, which wasn't part of the PR.

@marovira
Copy link

There may be a way to have the GitHub runners handle this, since they do come with git bash installed by default. @mattmc3, if I figure out a way to hook it into a Windows runner, would you be open to a PR?

@mattmc3
Copy link
Owner

mattmc3 commented Jul 19, 2023

Yes, definitely.

@DiegoMagdaleno
Copy link

DiegoMagdaleno commented Jul 19, 2023

I can take full responsability for maintaining all of the Windows related bugs. If you wish :)

@mattmc3
Copy link
Owner

mattmc3 commented Sep 22, 2023

If v1.9.2 doesn't fix it, please re-open. I was able to properly test on an old Windows clunker, so I'm reasonably confident I can support this without CI working for Windows yet. No reason to hold up the feature. Thanks for the cygpath implementation @marovira.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants