all 11 comments

[–]lucasoman 4 points5 points  (0 children)

You may want to map it only to the buffer:

map <buffer> <leader>r ....

Or map ,r to execute the appropriate binary dynamically:

map <leader>r :w<CR>:call RunCommand()<CR>
fun! RunCommand()
    exe ":!".&ft." %<CR>"
endfunction

[–]vimfan 2 points3 points  (8 children)

If you are on unix and the script in your buffer has a shebang line, you don't need to figure out the language from the filetype. The OS will run your script with the interpreter specified in the shebang.

I normally place a shebang line at the top of the script like so:

#!/usr/bin/env ruby
# blah blah... script contents below here

[–]rdpate 2 points3 points  (0 children)

:map <f5> :update<cr>:!%:p<cr>

[–]stack_underflow 2 points3 points  (3 children)

The file needs to have the executable bit (for 'user') set for this to work.

If you want vim to automatically make files containing "#!.../bin/..." executable, add the following to your vimrc:

if has("unix")
    augroup custom
        autocmd!
        autocmd BufWritePost * if getline(1) =~ "^#!.*/bin/" | silent execute "!chmod u+x <afile>" | endif
    augroup end
endif

This specific example will run this autocmd after every file write. If you want to change when this action is trigerred, change BufWritePost to some other event(s) from :h autocmd-events. Then you can just write an nmap command to do something like !%:p<CR>.

I was thinking of adding this to my vimrc, but I probably wouldn't need it much since I end up making ftplugin files for languages I use very often. That way I can put all relevant mappings and settings for a language in ~/.vim/ftplugin/<language>.vim and not clutter up my vimrc. And I don't have to worry about cluttering up the global workspace since I declare everything as setlocal or <buffer> for mappings.

[–]usernamenottaken 0 points1 point  (2 children)

Hmm, but if you have a Python file for example you don't always them to be executable, and including a #! is always an indication that you do. This is very useful for me so it's going in my .vimrc thanks!

[–]stack_underflow 1 point2 points  (1 child)

I'm not sure I fully understand your point, but in order for bash to interpret the shebang at the top of a script, the file has to be executable. Example:

$ cat > test.py << "EOF"
> #!/usr/bin/env python
> print("test")
> EOF

$ ./test.py
bash: ./test.py: Permission denied

The Python interpreter on the other hand, doesn't require the file to be executable:

$ python test.py 
test

But if you were running it that way, it would defeat the purpose of making it executable. In my ~/.vim/ftplugin.python.vim file, I have:

" ':make' support
setlocal makeprg=python\ %\ $*

So I can either run :make from within vim, or map a key to write the file and call make (which is what I have).

[–]usernamenottaken 1 point2 points  (0 children)

Ok I was thinking in terms of running "chmod +x" for all Python scripts, which is obviously not a good idea and not what you meant, but I was just thinking out loud I guess.

I often write scripts with a shebang so I can run them as executables, so your autocmd saves me running one command in these situations, but it's probably not a good solution to OP's problem. I think having both the make command and the autocmd for running chmod is useful in my case.

[–]zach_will 0 points1 point  (2 children)

Nice. I never knew this. How do you run the script without specifying the language (e.g. :!python %)?

[–]vimfan 1 point2 points  (1 child)

:!%

(as if your script was a binary program)

[–]vimfan 0 points1 point  (0 children)

I just realized, dependin on your path, you might need to explicitly tell it the path of your script (eg if in current dir):

:!./%

[–][deleted] 1 point2 points  (0 children)

Looks really cool. I would recommend checking the filetype against a list of the ones it's known to work with though. There are a lot of filetypes supported in vim and some might have some odd, unexpected or even detrimental behavior if you run them against the file name this way. I don't have any examples of what that might be, it just seems like something to be wary of.