hharnisc / hypercwd

Opens new tabs with the same directory as the current tab in Hyper
MIT License
385 stars 39 forks source link

doesn't work with git bash #33

Open pikilon opened 7 years ago

pikilon commented 7 years ago

A lot of are using git bash to have a similar bash as in linux, configuring hyper like this https://github.com/zeit/hyper/issues/1252#issuecomment-267810099

But this "must to have" plugin doesn't work sadly

No errors, nothing

burnedikt commented 6 years ago

I would also love to see this and took a short look but the general problem is that I haven't found a straight-forward way to get the current working direcotry of a running git-bash session.

The windows specific code of setCwd in lines 17 - 28 assumes that the action.data will contain some information about the current directory but in my tests, it didn't.

A sample that i got for the action.data is

]0;MINGW64:/c/Users/anonymous[?25lanonymous@DESKTOP-ANONYMOUS MINGW64 ~[?25h[?25l$[?25h

which only contains the path to the home directory (in this case /c/Users/anonymous) (which appears to be the working directory of git-bash.exe) but not the actual working directory that the bash (sh.exe) uses.

Any ideas on how to get the actual working directory?

devjosh-mudbath commented 6 years ago

+1

Spiderpig86 commented 6 years ago

+1

codehearts commented 6 years ago

I was able to get the cwd using cygwin32 on Windows 7.

exec(`readlink -e /proc/${pid}/cwd`, (err, stdout) => {
  const cwd = stdout.trim();
  /* ... */
}

I'm not sure if this would work for Git Bash or MinGW

burnedikt commented 6 years ago

@codehearts Thanks! Finally found the time today to try out your solution. The good news is, the solution works in Git Bash / MinGW to get the cwd. The bad news is that it (obviously) only works if you know the exact pid of the bash (bash.exe) that is currently running within the "git-bash-wrapper" (git-cmd.exe). However, when using git-bash with hyper, as of now it is the only way to use the "wrapper" as the shell and have it launch the bash internally as shown in the sample configuration. So I guess we're back to square one here...

rofrol commented 6 years ago

@burnedikt I don't use wrapper on Windows 10.

    shell: 'C:\\Program Files\\Git\\bin\\bash.exe',

    // for setting shell arguments (i.e. for using interactive shellArgs: `['-i']`)
    // by default `['--login']` will be used
    shellArgs: ['--login'],
burnedikt commented 6 years ago

@rofrol Thanks, didn't know that worked. Either way, it did not help with the problem per se. Nevertheless, I've got a few steps further. Maybe this helps someone else:

  1. Whenever a tab is cloned or split vertically / horizontally, what we get from hyper is the PID of the git-bash. This may be either git-cmd.exe, git-bash.exe, or as in @rofrol's case bash.exe. However, it is never the PID of the actual bash process (usr/bin/bash) which we need to find out the current working directory using the method @codehearts posted above.
  2. To get the actual bash process (/usr/bin/bash) from the wrapping git-bash process's PID, we can use wmic which allows us to find child processes of the wrapping git-bash process, i.e. the /usr/bin/bash process.
  3. As soon as we got the actual bash process's PID, we can use readlink -e on /proc/${processId}/cwd to find the cwd of this bash

Coming this far, I've noticed some flaws in the current windows-specific code of hypercwd, namely that the code in windowsActionHandler.js#L30-L34 never passes the original bash session's PID to the windowsSetCwd function but only the PID of the newly created bash process. Obviously, the PID of the newly created bash session is irrelevant, since we need the cwd of the previous session. The fix for this is easy enough, though I am not sure as to what the side effects are regarding non-git-bash-shells.

Even then, we face one last problem: We know the running bash processes (both of git-bash and actual bash) and we know the cwd we want to set for this bash process but how do we set the current working directory for a bash process that is already running? There are some approaches but it seems more reasonable to pass the cwd already, before the session is even started / the new tab is created. Needless to say, the Action SESSION_SET_CWD does not work as expected.