윈도우즈에서 win32/64vim이면 "&shell"을 "$COMSPEC"로 변경하십시오.exe 또는 gvim.exe는 bash 내부에서 실행됩니다

묘사

vim Sensive의 보완 사항으로 간주하십시오.
불행하게도, 많은 플러그인들이 has("win32") || has("win64") || has("win16")이 사실이라면, 셸 명령은 cmd.exe에서 실행될 것이다.
참고: $COMSPEC은 cmd.exe의 전체 경로입니다.
cygwin bash셸 내부에서 이 컴퓨터의 윈도우즈 gvim (win32 또는 win64) 을 시작하면, &shell은 /bin/bash이다.이것은 플러그인에 여러 가지 문제를 초래할 수 있다.gvim.exe의 윈도우즈 바이너리 파일은 &shell=$COMSPEC을 사용하는 것이 가장 좋다.
Bash가 좋아요...단,cygwin 사용자가 bash를 그들의 &shell으로 사용하기를 원한다면,cygwin의vim를 사용해야 한다.
이 컴퓨터는 윈도우즈 gvim입니다.exe는 보통 xwindows 서버가 필요하지 않기 때문에 cygwin gvim보다 인기가 있습니다.따라서 이 컴퓨터의 윈도우즈 gvim을 실행하는 것은 매우 흔한 일이다.cygwin 내부에서 온 exe.따라서vim에 대한 이런 첨가는 합리적이다.

토론 #1

주의: 이 변경은vim이나 gvim을 실행하는cygwin 바이너리 파일의cygwin 사용자에게 영향을 주지 않습니다.이것은 이 컴퓨터의 윈도우즈 gvim에만 적용됩니다.exe는 bash 내부에서 실행됩니다. 예를 들어cygwin의 bash입니다.

토론 #2

좋은 생각일 수도 있다고 생각합니다.저는 방금 msysgit vim과cygwin 주민vim에서 검사를 받았습니다. 말씀하신 바와 같이 이것은 정확하게 0으로 돌아왔습니다.

( has("win32") || has("win64") || has("win16") ) && &shell =~# 'bash$'

아마도 has('gui_running')도 조사할 가치가 있을 것이다.

토론 #셋

나는 has('gui_running')이 필요하다고 생각하지 않는다. 이런 보기 드문 상황에서 다칠 수 있다.
- 누군가 이 컴퓨터의 윈도우즈 vim을 시작하면.cygwin bash 내부에서 실행됩니다. 원인은 이 컴퓨터의 윈도우즈 gvim와 같습니다.exe, 너도 &shell을 bash로 만들고 싶지 않아.
주: msys, $SHELL=/bin/sh, msys의vim에서.exe :echo &shell 반환 sh...(케이스 echo $SHELL 내부와 msys의vim.exe 내부가 다르다는 사실이 놀랍습니다.)msys에서 윈도우즈 gvim을 시작하면그럼 &shell은 $COMSPEC.msys/bin/sh에서 $SHELL에서 그 값을 얻지 못한 것 같습니다. 저는 각종 msys 버전(mingw32와mingw-w64-msys 포함)을 시도해 보았습니다.모든 사람은 내가 위에서 묘사한 동일한 행위를 가지고 있다.

토론 #4

감사합니다.나는 Git가 덧붙인 Vim 버전이 왜 set shell=\"Program\ Files\Git\usr\bin\bash.exe"과 함께 사용할 수 있는지 알아보는 데 오랜 시간이 걸렸지만, 본 컴퓨터에 설치된 Vim은 그것에 걸렸다.(솔직히 말해서, 나는 여전히 이것이 왜 그런지 확실하지 않지만, 당신의 $COMSPEC은'유효하다'고 건의합니다.) Windows의

토론 #5

Vim은 명확하게 지원하거나 최소한 지원을 시도합니다.)UNIX 셸: :help 'shellslash' 을 참조하십시오.어떤 사람들은 심지어 이런 방식으로 그것을 배치한다. 비록 결점이 있지만.나는 이것이 그들의 설정을 취소하기 위한 우리의 위치라고 생각하지 않는다.주의해라, 이것은

토론 #6

에 관한 것이 아니다.이것은 &shellslash과 sh에 사용할 수 있는 명령입니다.하면, 만약, 만약...그러나 윈도우즈+cygwin에서 cmd.exe은 cmd.exe입니다. 문제가 발생할 수 있습니다.대부분의 플러그인은 항상 has("win32") || has("win64") || has("win16")을 가정하고 &shell을 실제로 테스트한 적이 없기 때문에 이것은 플러그인 문제이다.만약 bash이라면, 그들은 항상 cmd.exe을 가정한다.
나는 오늘 이 문제에 그다지 관심이 없다. 왜냐하면 나는 오늘vim과cygwin을 사용하지 않기 때문이다.&shell 저는 cmd.exe을 제시하여 Vim 자체가 Windows의 Bash를 지원한다고 지적했습니다.Cygwin Bash를 사용하는 사용자로 Vim을 구성하는 것은 아무 잘못도 없으며 결정을 번복할 수도 없습니다.Vim이 기존 값을 전혀 지원하지 않을 때 has("win32") || has("win64") || has("win16")을 다시 쓰는 것이 합리적이다.하나의 예는

토론 #7

덮어쓰기이며 이전 버전의 Vim은 지원되지 않습니다.
https://github.com/tpope/vim-sensible/blob/2d9f34c09f548ed4df213389caa2882bfe56db58/plugin/sensible.vim#L66-L68

Its a plugin issue because most plugins always assume cmd.exe and never actually test &shell. They always assume cmd.exe if has("win32") || has("win64") || has("win16").

그럼 플러그인이 틀렸어.물론 그들은 정확하게 하기가 매우 어렵다.그러나 나는 이 초보자의 오류를 피하기 위해 여러 개의 플러그인을 유지했다.
나는 'shellslash'의 플러그인을 사용하는 것을 본 적이 없다고 생각한다.나는 네가 아마도 아주 오래 전의 한두 번의 좋지 않은 경험에서 너무 많은 것을 추단했을 것이라고 생각한다.