How to set USERNAME in RHS of "set" command

[AndyHancock]

I'm trying to get the PC-based vim to shell out to cygwin's bash
interpetter.

That way, I can issue commands like

!!cal " Gets a calendar

:2,3 w !bash " sends line 2 & 3 to a bash shell

This is the behaviour I'm use to from cygin's gvim.

I've have the following in my vimrc to try to get bash functionality:

set shell=c:\cygwin\bin\bash.exe -i

According to bash man pages, -i should force bash to run the startup
file .bashrc in the user's home directory, setting up paths, shortcut
command aliases, functions, etc.. Unfortunately, the home directory
is the Windows home directory, not the cygwin home directory. So I
wish to forcibly use the cygwin home directory:

set shell=c:\cygwin\bin\bash.exe --rcfile\ c:\cygwin\home\USER
\.bashrc

I want to do this rather than create a copy of .bashrc in the Windows
home directory because it's one less copy of .bashrc to update when
changes are made. Furthermore, all users accounts benefit from the
global vimrc.

Here's the sticky part. In place of USER, I've tried %USERNAME%,
expand('$USERNAME'), and ${USERNAME}. None of them work. Could
someone please respond with the proper syntax?

Thanks.

[Tim Chase]

On 06/22/12 23:33, AndyHancock wrote:
> I've have the following in my vimrc to try to get bash functionality:
>
> set shell=c:\cygwin\bin\bash.exe -i

I'm surprised this doesn't give an error. Using ":set", spaces are
treated as delimiters between options, so it should give an error
something like "E518: Unknown option -i"

> set shell=c:\cygwin\bin\bash.exe --rcfile\ c:\cygwin\home\USER
> \.bashrc

which I would expect to happen here too (you escape the one after
"--rcfile", but not the one after "exe").

There are a couple of options, as you can escape the spaces with "\"
(though using Windows "\" as the path separator may then cause
issues; since Vim understands both, I'd stick to using "/" for
portability). You can also use Vim's ability to use :let do more
complex evaluations which is what I expect you want in this case:

:let &shell='c:\cyg�'.$USERNAME.'/.bashrc'

which you can read about at

:help :let-option

I might use "$HOME" instead of the full-path-with-username-replaced
as that should be more portable.

-tim

[AndyHancock]

On Jun 23, 7:49 am, Tim Chase <v...@tim.thechases.com> wrote:
> On 06/22/12 23:33, AndyHancock wrote:
>
>> I've have the following in my vimrc to try to get bash
>> functionality:
>>
>> set shell=c:\cygwin\bin\bash.exe -i
>
> I'm surprised this doesn't give an error. Using ":set", spaces are
> treated as delimiters between options, so it should give an error
> something like "E518: Unknown option -i"
>
>> set shell=c:\cygwin\bin\bash.exe --rcfile\ c:\cygwin\home\USER
>> \.bashrc
>
> which I would expect to happen here too (you escape the one after
> "--rcfile", but not the one after "exe").

You're right. I was handraulically trying to copy the bashrc
statements into my posting. Foolish me. Humans stopped typing error
free the moment computer editors and word processors became
widespread.

> There are a couple of options, as you can escape the spaces with "\"
> (though using Windows "\" as the path separator may then cause
> issues; since Vim understands both, I'd stick to using "/" for
> portability). You can also use Vim's ability to use :let do more
> complex evaluations which is what I expect you want in this case:
>

> :let &shell='c:\cyg '.$USERNAME.'/.bashrc'

>
> which you can read about at
>
> :help :let-option
>
> I might use "$HOME" instead of the full-path-with-username-replaced
> as that should be more portable.

I was starting to much around with the following in my vimrc:

let &shell='c:\cygwin\bin\bash.exe\ --rcfile c:\cygwin\home\'.
$USERNAME.'\.bashrc'

Then I found the *real* source of my problem. There is nothing wrong
with

set shell=c:\cygwin\bin\bash.exe\ -i

The problem is that it was enclosed

if has("win32")
" etc.
endif

I was running on a 64-bit Windows 7. Heh. Heh heh. (I smack my
forehead).

However, your example is still highly educational, for which I thank
you.

[AndyHancock]

Just a word of warning, now that I got it running and had a chance to
try it out...the Windows-based vim defaults to a filetype of dos. I
wrote scripts that used "mv" to rename a bunch of files and sent them
to bash using

:w !bash

This ended up embedding invisible ^M characters at the end of each
filename. Extremely hard to figure out. At first, I thought it was
the new-fangled Windows 7 UAC Virtualization that was causing
recursive diff to report differences in my file tree. Not so, it was
the invisible characters in the filenames.

Anyway, I'm going to google around to find out how to set the default
filetype in order to avoid this. Mind you, having a filetype of unix
carries consequences too. You tend to lose track of the fact that
you're writing text files or source code using filetype=unix. When
you send these files to others (most of whom don't know or care about
unix), all they get is gibberish. Maybe I should keep the default
filetype=dos and use something like:

:w !dos2unix|bash

I'll have to figure out the escaping for the piping, but we'll see.

[John Little]

On Wednesday, June 27, 2012 6:48:21 AM UTC+12, AndyHancock wrote:
> ...the Windows-based vim defaults to a filetype of dos...

> Anyway, I'm going to google around to find out how to set the default
> filetype in order to avoid this.

Before googling, vim's help is usually the first place to go, and then the vim FAQ http://vimhelp.appspot.com/vim_faq.txt.html and the Vim tips wiki http://vim.wikia.com/wiki/Vim_Tips_Wiki.

In particular, you should read

:help file-formats

if you haven't already.

> ... You tend to lose track of the fact that

> you're writing text files or source code using filetype=unix.

I have an expression in my status line option

%1*%{&ff=~'u'?'':&ff}%*

which shows me the file format if it's not my usual unix, in a different colour to the rest of the status line (which I always have on with :set ls=2).

Regards, John Little

[AndyHancock]

On Jun 27, 1:38 am, John Little <John.B.Lit...@gmail.com> wrote:
> Before googling, vim's help is usually the first place to go, and
> then the vim FAQhttp://vimhelp.appspot.com/vim_faq.txt.htmland the
> Vim tips wikihttp://vim.wikia.com/wiki/Vim_Tips_Wiki.

I find the vim help and vim-specific FAQs/wikis helpful if I now the
right words. Google helps me find the right words, and often points
me to relevant pages.

> In particular, you should read
>
> :help file-formats
>
> if you haven't already.

Thanks. That was quite helpful.

>> ... You tend to lose track of the fact that
>> you're writing text files or source code using filetype=unix.
>
> I have an expression in my status line option
>
> %1*%{&ff=~'u'?'':&ff}%*
>
> which shows me the file format if it's not my usual unix, in a
> different colour to the rest of the status line (which I always have
> on with :set ls=2).

It never ceases to amaze me how deep the vim coding can be for
seemingly simple things that the casual user takes for granted. In
trying to understand the help for the statusline option, a few helpful
pages I found were:

http://vim.wikia.com/wiki/Showing_syntax_highlight_group_in_statusline
http://got-ravings.blogspot.ca/2008/10/vim-pr0n-conditional-stl-highlighting.html
http://www.vim.org/scripts/script.php?script_id=3383
http://vim.runpaint.org/display/changing-status-line

Currently, I use only the simplest concepts from the 2nd last link:

highlight StatusLineNC guibg=tan
highlight StatusLine guibg=white

The first link is great for illustrating the curly brace expression
evaluation that you use.

My brain started to disconbobulate when reading about highlight group
1 in "%1*", but I get the idea. Different suites of highlight
colours.

Anyway, I think the use of cautionary colours to bring attention to
the fileformat is a great idea, especially since I often use a scratch
file for manipulating text that is meant for others as well as for
piping to bash. However, I like the items shown on the default
statusbar, so I'll look into cobbling together a statusline that
incorporates this feature along with the standard items. It's a bit
of a longer term to-do.

I also confirmed that there is no special escaping needed to pipe text
through dos2unix prior to bash. For example, to execute everything
from the mark 'a to . (current insertion point), I would do:

:w !dos2unix|bash

Thanks!

[Bee]

On Jun 26, 10:38 pm, John Little <John.B.Lit...@gmail.com> wrote:
> I have an expression in my status line option
>
> %1*%{&ff=~'u'?'':&ff}%*

I have wondered about coloring the statusline. Thank you John.

These work the way I would like.
Is it possible to make it a one liner?
That is conditionally color the ff?
I could not get the %1* to work inside the false part,
so split into two statusline commands.

set statusline+=%{&ff=~'u'?'u':''} " unix fileformat
set statusline+=%1*%{&ff=~'u'?'':strpart(&ff,0,1)}%* " not unix
fileformat

Bill

[John Little]

On Tuesday, July 3, 2012 7:34:55 AM UTC+12, Bee wrote:

> Is it possible to make it a one liner?

Perhaps I should have given all the details, the way Tony M does.

My 'statusline' is set to

%<%f%1*%{&ff=~'u'?'':&ff}%* %h%m%r%=%-16.(%l,%2c %L%) %P

so I've got the usual stuff, with the dos or mac warning sitting right by the file name. My colour scheme has, amongst others,

hi Normal guifg=white guibg=black
hi StatusLine guifg=green guibg=DarkSlateGrey gui=underline,bold
hi StatusLineNC guifg=darkgreen gui=underline,italic

So the status line for the current window has a grey background, quite different from the black of the file I'm editing. The ff bit is coloured with highlight group User1, which I don't usually bother to define, so it comes out as Normal, white on black, not bold green underline on grey, quite distinct.

Now the bit in the %{ ... } is a vim expression, not a status line specifier, so status line specifiers won't work in it. However, if the %{ ... } has zero length, you don't see it, so just include both of them:

set statusline+=%{&ff=~'u'?'u':''}%1*%{&ff=~'u'?'':strpart(&ff,0,1)}%*

Regards, John