On Sep 16, 1:22 pm, Alessandro Antonello <antonello....@gmail.com>
wrote:
>>>AndyHancock wrote:
>>>> This problem dogged me for many years, and I finally hunkered
>>>> down to chase it down.
>>>>
>>>> Here is the solution that I found works for me:
>>>>
>>>> "set shell=c:\cygwin\bin\bash.exe\ -i
>>>> "Won't always find ~/.bashrc cuz depending on how vim is
>>>> "launched, ~ doesn't always resolve to
>>>> "c:/cygwin/home/$USERNAME
The full code was:
"set shell=c:\cygwin\bin\bash.exe\ -i
"Won't always find ~/.bashrc cuz depending on how vim is launched,
"~ doesn't always resolve to c:/cygwin/home/$USERNAME
"let &shell='c:\cygwin\bin\bash.exe\ --rcfile c:\cygwin\home\' .
" \ $USERNAME . '\.bashrc'
"Backslashes are hated by bash. Also needs -i to ensure bash is
"interactive so that .bashrc is sourced
let &shell='c:\cygwin\bin\bash.exe --rcfile c:/cygwin/home/' .
\ $USERNAME . '/.bashrc -i'
" Depending on how vim is launched, c:/cygwin/home/$USERNAME
" will sometimes be equivalent to ~. If so, then it will be
" replaced by ~ in &shell.
I said in my response to Linda that this only looks complicated
because I also included the ones that didn't work (for me) to save
experimenters the trouble of finding that out themselves. Hence there
are comments explaining what didn't work, what did, and my best
rationalization of why.
>> I don't know if setting the environment variable SHELL would
>> propagate its value into the vim option "shell". However, even if
>> it did, I would feel more comfortable with the command in my code
>> because just setting the shell alone left the rc file un-executed,
>> even with the interactive flag was provided as part of the "shell"
>> option (which is suppose to cause the rc file to run). It's all
>> kind of foggy to me now, but I believe that one of the possible
>> causes was that $HOME was being set to different things depending
>> on how vim was invoked. So it wasn't finding the rc file in many
>> cases.
>
> I never tried to shelling using cygwin bash on Windows GVim. I will
> give a shot. In respect to '~' to be recognized as $HOME you will
> need to create an environment variable, in Windows, targeting that
> path. Be prepared that if you have any other cross platform software
> it probably will use that %HOME% path to write temporary and
> configuration specific files (Inkscape, GIMP, Dia, etc.).
>
> The best thing about this configuration is that both Windows
> Vim/Gvim and cygwin vim uses the same user runtime path (~/.vim)
> with save me for synchronizing plugins, syntaxes, colors, etc.
I suspect that the lack of a defined Windows %HOME% variable (and
hence, the automatic predefinition of unix $HOME) could very have been
the cause of the problems I described above. I haven't experimented
how robust is the solution of setting %HOME%. For example, what
happens if you were logged into a non-administrator account and ran
Windows gvim as MyAdminAccount, and administrator account.
And in Windows 7, there is another way to invoke apps, "As
Administrator", where Administrator isn't necessarily an account.
Somehow, it knows that you are referring to MyAdminAccount, but
running "As Administrator" further runs with elevated privileges,
which simply running as MyAdminAccount does not. Environment
variables also seem to differ. Not sure if either method of running
as MyAdminAccount would pick up that account's %HOME% variable, since
you don't actually log onto that account. (Not something I can test
right now cuz I'm scanning a slow stick, which has taken more than a
week).
I'll wait until I get more info about the robustness of the solution
of setting %HOME%, either from myself, you, or someone else.
Thanks for the added knowledge, though, of how the problem could be
circumvented.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Sunday, September 16, 2012
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment