We Keep Coding

Execute current file in Vim without shebang

Is there a clean alias that I can put in my vimrc that will run the current file using python if there is a python extension?
At the moment I have nnoremap <leader>r :!%:p<Enter> as suggested in this question (when I hit \+r it runs the open file). It works great for bash files, where the convention is to add a shebang line and make the file executable, but for python files it obviously exits 1.
As a workaround I have added a new command - command PyBang :call append(0, "#!/usr/bin/env python") - that adds a python shebang to the top of the file. The problem is that this is not really convention for .py files and making them all executable seems like a lot of effort for some reason.
So I am struggling to write an alias that will run :!%:p<Enter> if there is no extension and prepend python if there is a .py extension on the file in the buffer.
Any ideas are really appreciated.

The easiest way to do this is to use vim's exclamation mark to run shell commands. For instance,
: ! python3 % will run the current file % with python3 outside of vim, in whatever shell you're in.
You can use this in combination with vim scripting to create your own shortcuts for this command.
To combine this with your current bash function, you will need conditional logic in your vim function to detect filetypes (see here and here for how to work with filetypes and their detection)

Issue Opening Py Files in Spyder Using Custom Automator Script

So I installed Miniconda using Homebrew and then installed Spyder using Conda. Then I wanted to make the process more "Mac" friendly by creating an application which opens Spyder so I used the solution by topoman which is below the accepted answer in this link:
Ways to invoke python and Spyder on OSX
Everything works more or less fine except I have ran into two issues (the second one isn't really an issue and more of an aesthetic related thing):
I downloaded py files from this GitHub (https://github.com/realpython/python-scripts) just to test that it will open py files. It works for them and I am also able to set Spyder as the default application by using the "SpyderOpener" solution provided by topoman in the above link.
The issue is that when I create a new file in spyder and save it then try to click-open it, it won't. I'm not sure what the difference is and why the "SpyderOpener" does not work on this py file originating from Spyder, but works fine for the ones I downloaded.
I was curious if it is possible to change the display icon for py files that have the default as "SpyderOpener". I did change the icon for the SpyderOpener application but it doesn't work. The icons for the files is just a blank printer sheet.
UPDATE:
I believe I found the issue. It depends on where the file is. When I put it on my desktop, no issue. When I put it in other certain places no issue. Based on experimenting it seems that the opener does not work when the file is within a folder that has a space in the name (e.g. folder name). The minute I change to folder_name or foldername it works fine.
Therefore, is someone able to explain why the opener script breaks down when there is a space at any place in the file path? Can the script be edited to handle this?
Does it boil down to the following stack threads (i.e. I need to apply double quotes somewhere in the script):
Shell Script and spaces in path
https://askubuntu.com/questions/1081512/how-to-pass-a-pathname-with-a-space-in-it-to-cd-inside-of-a-script
This thread also suggests the script shouldn’t use the $# argument unquoted because it will break as soon as you have “spaces or wildcards”:
https://unix.stackexchange.com/questions/41571/what-is-the-difference-between-and
Therefore looking at the script and previous steps you have:
#!/bin/bash
/usr/local/bin/spyder $#
Then the opener script has:
for f in "$#"
do
open /Applications/spyder.app --args $f
done
if [ -z "$f" ]; then
open /Applications/spyder.app --args ~
fi
As for the rest of the script, I assume $f isn’t going to cause problems? Anyways, it seems the issue comes from the initial setup?
Based on this, it should be handled by the above line:
Handle whitespaces in arguments to a bash script
So is it breaking down because of the args?

Running Python program with dot slash: No such file or directory [duplicate]

I have several python scripts which work just fine but one script has (as of this morning) started giving me this error if I try to run it from the bash:
: No such file or directory
I am able to run the 'broken' script by doing python script_name.py and after looking around a bit the general idea that I picked up was that maybe my line ending of the hashbang got changed (silently) so I looked at the line ending of a working script and a broken script via the :set list option in VI as indicated in this question -> View line-endings in a text file
Both files appear to end using the same character (a $) so I am kind of at a loss on how to proceed from here. Specifically, how to actually 'see' the line ending in case the set list was not the right method.
PS: The script is executable and the shebang is in there, I stated that it's just this 1 script that was working fine before the weekend but it started giving me this error as of this morning.
-- edit: --
Running the script through dos2unix does get it working again but I would like to know of any way to visualize the line ending somehow in VI(M) or why Geany somehow converted the line endings in the first place (as I never work on a dos/windows system anyhow).

From the comments above it looks like you have dos line endings, and so the hashbang line is not properly processed.
Line ending style are not shown with :set list in Vim because that option is only used when reading/writing the file. In memory line endings are always that, line-endings. The line ending style used for a file is kept in a Vim per-file option, weirdly called fileformat.
To see/change the line ending style from Vim, you can use the following commands:
:set fileformat
:set ff
It will show dos or unix. You want unix, of course ;-).
To change it quickly you can save the file with:
:w ++ff=unix
Or if you prefer:
:set ff=unix
And then save the file normally.
So see all the gory details just do :help fileformat, :help file-formats and :help fileformats

You can also use the dos2unix command to convert the file format
dos2unix
This helped me to run the python scripts
This normally happens when we open files in windows do changes and save it.
if you open the file locate the ^M characters at the end of every line
Thanks

Personally, I find it kinda wrong using direct path to python interpreter. As you dont use windows platform, you should have program env, usually in /usr/bin (/usr/bin/env). Try using following shebang:
#!/usr/bin/env python
Different distros store python binary in /bin or /usr/bin (or some weird locations), and this one makes your script config-independent (as far as possible, here we have possibility that env is stored elsewhere; still - it is less possible that env is not in /usr/bin than that python is mislocated).
I had similiar problem (if not exactly the same) and that worked for me.
Also, I have both python interpreters (2.7.x and 3.x) installed, so I need to use "python3" argument for env. AFAIR usually distros link different names to different binaries, so "env python" will run python2.7 on my system, "env python3" (also python33, or smth like that) will run p3k, and "env python2" (also python27, etc) will run python 2.7.x. Declaring which version of interpreter should be used seems like a good idea too.

I came across this problem editing my code on Windows, checking it in with git, and checking out and running it on Linux.
My solution was: tell git to Do The Right Thing. I issued this command on the Windows box:
git config --global core.autocrlf true
Modified the files and checked them in; voila, no such problem any more.
As discussed on the Git documentation.

When using Python Windows Launcher, is there any way to prevent having to type full path?

In Windows 8, I often use the Python Windows Launcher like
py C:/long/long/long/long/long/path/to/prog.py ...
Is there any way to set some environment setting, such as PATH or PYTHONPATH etc, to prevent having to type the full path to prog.py?
From my basic knowledge/research, PATH only helps with the py part of the command line and PYTHONPATH only helps with imports within prog.py, so how do I deal with the path to prog.py itself??
Notes:
I cannot modify the code, not even the "shebang" line, since it is needed to work on other platforms.
I cannot cd to the directory containing the programs to run them, because the programs will do something based on the directory they're run in (they'll modify the files in the directory they're run in).
I know that if I associate .py extension with the Python Windows Launcher, then I can run prog.py as the first item in the command line, and thus use PATH, but currently my .py extension is associated with my favorite editor and I'd like to keep it that way if possible (so I can double-click any Python file in Windows Explorer and edit it).
However, if someone suggests a solution where I can have a different association for Windows Explorer versus the command line, then that could be a potential solution! (i.e. in Windows Explorer, .py opens with the editor, while on command line, .py runs with Python Windows Launcher)

Add your long path to PYTHONPATH, then invoke your program as such:
python -m prog
Python will search for a module called prog and then run it as the main module.

Answer to my own question: Actually, I'm so silly. I could just set a variable for each program path (there are only a few programs paths), i.e.. prog=C:/long/path/to/prog.py and then do py %prog% .... I guess I figured out an answer to my own question that was acceptable to me.
Update: I just found something even better. I can do
doskey prog=py C:/long/path/to/prog.py $*
and then simply prog ... afterward
Now I just have to do some crazy stuff to get the doskey command into a file that will be run every time I start a console, as described here: https://stackoverflow.com/a/21040825/5182136

How to install python syntax support for Vim on Mac OSX?

I recently started programming in python and have fallen in love with Vim over the past few weeks. I know want to use Vim as my primary editor for python files. I know there are python plugins for Vim, but I am very confused as to where/how I can install these. I don't really understand where Vim is installed. I'm running the latest version of Mac OS X Snow Leopard.
Any help would be greatly appreciated. Thanks!

To best answer your initial question: "How to install python syntax support in Vim":
There is no need to install anything! If you have not made any modifications (e.g. no configuration changes for vim in ~/.vimrc) try the following:
Open a Python file with vim
type the following command :syntax on
You should now have VIM properly highlight your Python file.
To avoid having to re-type those command over and over again, I would suggest you keep a configuration file for VIM. This is usually located in your home directory, if there is not one there already, create a ~/.vimrc file and add the syntax on directive there to
have VIM automatically highlight your Python files.
If you need to know more about structure/installation of plugins, then Senthil's answer is better suited :)

You will find that you have a folder by name .vim in your home directory cd ~ and it will contain the following directories
ftdetect/ ftplugin/ plugin/ syntax/
You need to download the plugins and install them (copy them) to those directories.
Apart from that, in your .vimrc file have the following lines which will enable you to write python programs following PEP8.
set autoindent
set tabstop=4
set expandtab
set shiftwidth=4
filetype indent on
There are some good documentation out there as well.

for mac os x, the vimrc file is located in /usr/share/vim directory
edit the vimdc file with any text editor. Add the syntax on to the last line of the file. Then next time you start a file you can see color. This is a system wide setting. In other linux flavor it may be located in /etc/ you can find this file by find /etc -name vimdc. The edit will affect all the users on the machine.
These setting can overwritten by the $HOME/.vimrc file. In your home you may also have a .vim directory. To check that you have these, do ls -a in your home directory.