We have a large number of scripts on an old CentOS system that begin with #!/usr/local/bin/python2.7. We are setting up a new host with RH EL7 and noticed that Python 2.7.5 is installed at /usr/bin/python2.7 instead of /user/local/bin/python2.7. This means that the old scripts won't be able to find python on the new RH system.
To avoid editing all the scripts, would simply adding at link at /usr/local/bin/python2.7 pointing to /usr/bin/python2.7 work? Is there a downfall to this approach?
Thank you!
On almost any modern distro, python points to python3 which in turn points to python3.7. So no, there's no down side to symlinking like this.
Just know what you're doing and why you're doing it.
Removed my comment and added it as an answer, since the question doesn't appear to be closing and others were posting information on the topic as answers.
Do it
"adding at link at /usr/local/bin/python2.7 pointing to /usr/bin/python2.7" is OK.
What is not ok is the other way round.
You put what you want in /usr/local/bin/, but avoid messing with /usr/bin/, which contains important stuff (but you don't do it so that's ok, just make sure you know what you're doing).
Xcode doesn't like symlinks, other than that, to my knowledge, there is no down side.
If you're on Mac (and use Xcode), you may want to read "Xcode, for whatever reason, will not let you use the symbolic link at /usr/local/bin/python" to fix that issue.
Related
I have the following issue:
I have some software that installs a particular version of IronPython to GAC. But I need to install a newer version of IronPython without affecting GAC. Hence the need for somehow using pyenv on windows with IronPython.
I am not from a programming background, more of a brick and mortar background, so please bear with me here.
[pyenv-win][1] doesn't support IronPython yet, and given my background, I have no idea how to modify a GIT repository and then install it (I'm trying to learn all that, but first I need to set this environment up, so that I don't mess things up, its a vicious cycle :P).
I downloaded a copy of the code and I was looking into how it is addressing different python versions.
It seems in [this file][2]
there are variables:
mirror, mirrorEnvPath, listEnv
that point to location of the exe that pyenv-win is using to install and maintain python version
So I somehow need to add an iron python mirror location and another array to the list that reads something like this
ironmirror = "https://github.com/IronLanguages/ironpython2/releases/download"
and add a line to listEnv
Array("ipy-2.7.9", ironmirror&"/ipy-2.7.9/", "IronPython-2.7.9.msi", "x64")_
That's how far I can get. If someone could help me put all this together, that would be nice. I have no idea how to run this modified code from my local hard drive. I would also like to somehow add this functionality to the package on GitHub as well so that others can use the same. Also, I am not sure if I am allowed to look into the code that others have shared and modify it. This is a new world for me. Apologies if that's the case.
Any help is appreciated.
[1]: https://github.com/pyenv-win/pyenv-win
[2]: https://github.com/pyenv-win/pyenv-win/blob/master/pyenv-win/libexec/pyenv-install.vbs
Recently, I've installed Anaconda3 in a MacOS laptop, but I need to set back the default python version to 2.7 because of some old codes involving the following syntax:
#! /usr/bin/env python
I read some comments and it seems like the easiest way to do it is by using an alias,
alias python="python2"
but even after setting this on my bash_profile, I'm still getting this:
$ which python
/anaconda3/bin/python
What am I doing wrong? Any suggestion is welcome. Thank you in advance!
IMO, you don't want to use an alias to do this. Rather, you want to manipulate your filesystem and/or PATH variable so that the first instance of a binary named 'python' found by the system on your PATH is the one you want to have running by default.
If it made sense to do so, and it was easy to do, an obvious fix would be to uninstall Anaconda. But I assume you still need it.
You could also dig into what the Mac might be doing in your case to manage multiple Python versions in some formal way. This might be the best solution, but I can't tell you how that works. You could Google for that information probably. If you want to take a more basic approach, read on.
What I'd suggest you do first is run the command ls -l `which python`. This will tell you which Python binary is currently the default one, and show you details about that binary. I'm guessing that that "binary" is actually a symbolic link, pointing to some other file. If so, you can just delete that link, or rename it to something else. The same thing will work if what you see is not a symbolic link, but rather a real executable, but it's a bigger deal to decide to delete or rename a real executable. If you just rename this file, you can obviously reverse what you've done any time you want.
Once you do this, do ls -l `which python` again. This should give you a new answer and be pointing at the original python installation. You can confirm which version of python is now the default by running python.
I have been working on getting pycharm to use python easy right.. wrong, when I try to add python 3.5 the gui, keeps going back to no SDK at all and it won't let me add one. to better explain the problem I made this video to help. what I am doing should work but it is not. note this is on an Ubuntu operating system.
https://www.youtube.com/watch?v=g5dy1jlIHCs
It seems weird beucase JetBrains' product detects local SDK first without pain, but you have really problem with that.
Anyway, I think, we can solve the problem.
Try to look PyCharm log. You may see interesting things over there.
Delete VirtualEnv and use /usr/bin/python3.5. (Maybe, it can solve)
Check JetBrains owner (chown), read and write permissions (chmod). Also, check .idea file
NOTE:
This invalid VCS doesn't effect your usage of SDK because JetBrains has to read .idea to find your VCS settings (or other things)
Thank you
You have two interpreters with the same name, not sure how it happened but PyCharm doesn't allow it
remove one, also you select an interpreter for a wrong project (you have multiple opened)
I used to use my Netbeans 6.9 for Python development. As well as Java and PHP. I had a cool debugger in PHP with xDebug, good Python support. Have no complaints whatsoever. I moved to another computer downloaded the latest netbeans(7.1) and now I have no more python plugin. I tried the solution here but this caused NetBeans not to start at all after the loading splash screen is finished NetBeans crashes.
Is there any way I can still code in Python with netbeans?
Thank you in advance
Ok, I fixed this. Say you've screwed up your netbeans installation by installing the pythonplugin then this might just work for you, provided you're using a non-windows OS. This is because Windows uses precompiled binaries to start the Netbeans IDE.
The problem that I solved is that, by default, a set of classes is not added to the Java classpath, which results in a crash. You can find whether this is also your problem by inspecting .netbeans//var/log/messages. If it displays some ClassNotFoundExceptions then we might have the same problem. If not, then at least you've got some pointers on what's going wrong and perhaps you might come up with some solution yourself. ;)
The java classpath is constructed in the file:
/<path>/<to>/<your>/<netbeans>/<installation>/platform/lib/nbexec
On OSX, this could be:
/Applications/NetBeans/NetBeans 7.1.app/Contents/Resources/NetBeans/platform/lib
In the main loop the function construct_classpath is called, which in turn calls the function build_classpath for two directories. I changed the function to this:
build_cp() {
base="$1"
append_jars_to_cp "${base}/lib/patches" "patches"
append_jars_to_cp "${base}/lib" "lib"
append_jars_to_cp "${base}/lib/locale" "locale"
# Added by me:
append_jars_to_cp "${base}/modules/ext" "ext"
}
After that modification, start your IDE and everything should work fine. Good luck!
The Solution for this problem could be found here
http://sahanlm.blogspot.com/2012/12/netbeans-7-2-crash-on-start.html
I am currently using the developer plugins on Netbeans 7.0.1 with no problem. Maybe they simply aren't compatible with the new version yet. I'd suggest just getting a 7.0 and using that.
Add org.eclipse.osgi_3.7.1.R37x_v20110808-1106.jar at
C:\Program Files\NetBeans 7.1.1\platform\lib\locale. Start NetBeans, remove the plugin or the reference with problem, later on, delete org.eclipse.osgi_3.7.1.R37x_v20110808-1106.jar
Please see the following link. It works for me:
http://wiki.netbeans.org/PythonInstall
Currently your NetBeans/Python choices are:
Try the latest development build updates against your current NetBeans version and mess with breakage at times as noted on the PythonInstall NetBeans wiki page or the link you gave.
Install the latest development version, but realize it's not a stable public release.
Wait for someone in the community to step up with continued development to keep the existing plugin in step with the latest public NetBeans release.
Install the NetBeans 6.9 (or older) version you were using with no complaints just for Python work.
I have had success with older versions and the development build. I am dabbling with other Python aware IDEs while I wait for main stream support, but I've stopped holding my breath.
If you can't change nbexec, like suggested by Bas Jacobs (e.g. on Windows), or don't want to do that, you can use the --cp:p startup parameter to append the necessary JARs to the classpath.
I only had to add the org.eclipse.osgi_3.7.1.R37x_v20110808-1106.jar file, so the complete command line under windows now looks like this:
"C:\Program Files\NetBeans 7.1\bin\netbeans.exe" --cp:a C:\\Users\\_YOUR_USERNAME_\\.netbeans\7.1\modules\ext\org.eclipse.osgi_3.7.1.R37x_v20110808-1106.jar
Anyone know this? I've never been able to find an answer.
If you're prone to installing python in various and interesting places on your PATH (as in $PATH in typical Unix shells, %PATH on typical Windows ones), using /usr/bin/env will accomodate your whim (well, in Unix-like environments at least) while going directly to /usr/bin/python won't. But losing control of what version of Python your scripts run under is no unalloyed bargain... if you look at my code you're more likely to see it start with, e.g., #!/usr/local/bin/python2.5 rather than with an open and accepting #!/usr/bin/env python -- assuming the script is important I like to ensure it's run with the specific version I have tested and developed it with, NOT a semi-random one;-).
From wikipedia
Shebangs specify absolute paths to system executables; this can cause
problems on systems which have non-standard file system layouts
Often, the program /usr/bin/env can be used to circumvent this
limitation
it finds the python executable in your environment and uses that. it's more portable because python may not always be in /usr/bin/python. env is always located in /usr/bin.
It finds 'python' also in /usr/local/bin, ~/bin, /opt/bin, ... or wherever it may hide.
You may find this post to be of interest:
http://mail.python.org/pipermail/python-list/2008-May/661514.html
This may be a better explanation:
http://mail.python.org/pipermail/tutor/2007-June/054816.html