I use TextMate to debug python script, as I like the feature of using 'Command-R' for running python from TextMate, and I learned that emacs provide similar feature.
I need to know if the python is run from command line or from TextMate/emacs. How can I do that?
ADDED
I use TextMate for python coding/debugging, and it's pretty useful. But, sometimes I need to run the test using command line. I normally turn on debugging/logging mode with TextMate, and off with command line mode. This is the reason I asked the question. Also, I plan to use emacs for python debugging, so I wanted to ask the case for emacs.
I got an answer in the case with emacs, and I happen to solve this issue with TextMate.
Set variables in Preferences -> Advanced -> Shell Variables, and I found that TM_ORGANIZATION_NAME is already there to be used. So, I'll just use this variable.
Use this variable, if os.environ['TM_ORGANIZATION_NAME']: return True
I guess the shell variable from TextMate disappear when I'm done using it.
For Emacs: If python is run as an inferior process, then the environment variable INSIDE_EMACS will be set.
From docs:
Emacs sets the environment variable
INSIDE_EMACS in the subshell to a
comma-separated list including the
Emacs version. Programs can check this
variable to determine whether they are
running inside an Emacs subshell.
sys.argv will tell you how Python was invoked. I don't know about TextMate, but when I tell Emacs to eval buffer, its value is ['-c']. That means it's executing a specified command, according to the man page. If Python's run directly from the command line with no parameters, sys.argv will be []. If you run a python script, it will have the script name and whatever arguments you pass it. You might want to set up your python-mode in Emacs and whatever the equivalent in TextMate is to put something special like -t in the command line.
That's pretty hackish though. Maybe there's a better way.
From the docs for sys.path:
As initialized upon program startup,
the first item of this list, path[0],
is the directory containing the script
that was used to invoke the Python
interpreter. If the script directory
is not available (e.g. if the
interpreter is invoked interactively
or if the script is read from standard
input), path[0] is the empty string,
which directs Python to search modules
in the current directory first. Notice
that the script directory is inserted
before the entries inserted as a
result of PYTHONPATH.
So
if sys.path[0]:
# python was run interactively
else:
# python is running a script.
Or, for example, from the IPython prompt (inside Emacs):
In [65]: sys.path
Out[65]:
['', <-------------------- first entry is empty string
'/usr/bin',
'/usr/local/lib/python2.6/dist-packages/scikits.statsmodels-0.2.0-py2.6.egg',
'/usr/local/lib/python2.6/dist-packages/pyinterval-1.0b21-py2.6-linux-i686.egg',
... ]
Use Command-R to run the script directly
Use Shift-Command-R to run the script from terminal.
Related
I can change the order to python2,3 folders in the system PATH variable. But what are other ways to do this?
There should be more elegant way to change versions of python i want to run.
e.g. in console:
python file.py #will run python2
and after i change python command to use python3, it should be the same:
python file.py #will use python3
I suppose you are trying to run your script with the correct interpreter depending on which python version was used. On Unix/Linux this is done with a so called “shebang” which is written in the very first line of the file. E.g.:
#!/usr/bin/env python3.6
If your installation of Python3 is newer than Python 3.3 you can use the python launcher for windows, which should be able to launch the correct version of Python depending on the shebang, even on window.
Also see here for more informations on shebangs.
If your concern is what Python version is executed when calling python in a console, then an alias or a stub script are the two ways to go.
This post will explain you how you can do this on Windows.
The alias way, just like it would be on a Unix system, is to create an alias, either temporary to the session or permanent, so that python now means C:\Python27\python, or whatever version you want.
The script approach consists in putting a script named python in a directory referred to in your PATH, and have that script run the right version of Python.
I highly doubt that this will affect all the batch scripts that call python, but it will definitely fire the right Python when you'll type python in a console.
Now, if you're concerned about what version a script is executed with, you can specify an explicit version with a shebang line, or manually select it by right-clicking the .py file and clicking open with.
Excuse the awkward question wording.
I've made a script. I would like for others to download it from github, and run it by typing programName argument1 argument2, similar to any other popular app used through the terminal such as Jupyter or even opening Atom/Sublime/etc. (ex:jupyter notebook, atom .). However, unlike Jupyter or sublime, my script isn't launching another app, it's a small app meant to be used in the shell.
Currently, to use my script, one must type into the command line python programName.py arg1 etc from within the file's directory.
How do I allow others to dl it and use it from anywhere (not having to be within the directory), without having to type out the whole python programName.py part, and only having to type programName arg1?
This blog post explains step by step how to create a distribution that you can install and it would turn into an executable.
You can refer to this github repo for a sample application.
The full documentation of setuptools is available here.
In general, you should configure your setup.py in order to use the command in the entry-point option:
setup(
name = "your_app_name",
packages = ["package_name"],
entry_points = {
"console_scripts": ['cmd_name = package_name.package_name:main']
},
....
)
This solution would work on every OS where you have installed python.
Your script may need to have an interpreter, "shebang", besides being "reachable" by the $PATH
#!interpreter [optional-arg]
For example, you could have something like
#!/usr/bin/env python
or to force a specific version
#!/usr/local/bin/python2.7
Next, your script needs to be available within the $PATH, check this answer that covers that part: https://unix.stackexchange.com/q/29608/53084
You can simply add your script to PATH variable in order to launch it from anywhere.
In Linux distros, you can simply do it by using a bash command PATH=$PATH:/path/to/your/script.
Make sure you don't have the space around the "=" operator.
Now, the second thing is you don't want your script to be named as pythonProgram.py.You can simply remove the extension .py from PythonProgram.py by adding a single line to the starting of your script.
Open up your script and at the very begining type #!/usr/bin/python.This should be the first line of your code.This line is called shebang and is used to tell the bash which interpreter to be used for compiling the script.
If everything went right, you will be able to run your script as pythonProgram arg1.
In addition to mabe02: Python is a scripting language and usually not compiled, which means you will need an interpreter to run your program.
Programms made in C f.e. can be run on its own because they were compiled into machine code by a compiler.
An interpreter is similar to a compiler as it reads your script and interprets it at runntime. That is why you need to write python before your programm, to tell your computer to interpret your script on runntime, using python. This doesn't mean that there are no possibilities to compile python as can be seen in the other answer and in this link Can a python program be run on a computer without Python? What about C/C++? (py2exe and py2app).
Is it possible to use a "more complex" shell than just a single command shell? We have written a python shell that is a command loop, and it works fine in /etc/passwd like this:
user:x:1000:1000::/home/user:/usr/bin/ourshell.py
Of course the Python file has the shebang line for /usr/bin/python in it. However, we'd like to compile the Python shell into a .pyc file to save a bit of time on execution in login. So, after compiling, I've been trying to "quote" the shell line in /etc/passwd as "python ourshell.pyc", and I even tried making the shell a bash script which simply executes that same command (with the initial arguments).
Of course none of this has worked. When we SSH in, there is always some kind of error. Is there any special trick to what I am trying to do?
CPython's .pyc files are not text, and do not allow use of a shebang line. The traditional method is to have your called script be tiny; it would simply import a module with the rest of the program, which can then be precompiled. For instance, here is the main script of xonsh:
#!/usr/bin/env python3 -u
from xonsh.main import main
main()
This script takes negligible time to compile. It is also possible to run installed modules using -m, but that takes module names, not filenames, so is not suitable for a shebang script.
I suggest to code a small C wrapper program running your python shell.
(notice that execve(2) forbids nested shebang interpreters; I don't know if that applies for your case)
Look into your log files, probably /var/log/messages and /var/log/auth.log
You may also need to explicitly add (the compiled C executable for the wrapper) to /etc/shells; see shells(5)
Look also into scsh.
Your sshd daemon is probably using Linux Plugin Authentification Modules. So read more about PAM.
Create a file /usr/bin/shell_wrapper that contains this one line:
#!/usr/bin/python /usr/bin/ourshell.pyc
The compiled bytecode ourshell.pyc has to live in /usr/bin, or else change the path accordingly. The python path should go to the same version that compiled the bytecode.
Then make sure to have your /etc/passwd use /usr/bin/shell_wrapper for the shell executable:
user:x:1000:1000::/home/user:/usr/bin/shell_wrapper
I'd like to replace python (symbolic link) with a shortcut that calls it as an ld.so argument:
e.g.
/home/user/my_libc_env/lib/x86_64-linux-gnu/ld-2.17.so /home/user/anaconda2/envs/tf_011g/bin/python2.7
instead of (the default)
/home/user/anaconda2/envs/tf_011g/bin/python2.7
Notes:
I need it as a link and not as an alias because my IDE debugger (pycharm) explicitly calls the link.
It should be able to support additional command line arguments if exist
Just using ln -s won't work, because it doesn't accepts arguments. I tried to wrap it as a bash script instead, but it doesn't works as well (works ok from command line, but SegFault when being called from the IDE debugger)
Is there another way for doing that?
EDIT (for clarification):
Here is what I tried for the bash script (works ok from the command line, but yield segmentation fault when being called from the IDE debugger)
#!/bin/bash
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda-7.5/lib64:/usr/local/cuda-8.0/lib64/cuda/lib64:$HOME/my_libc_env/lib/x86_64-linux-gnu/:$HOME/my_libc_env/usr/lib64/:$HOME/my_libc_env/usr/lib/" $HOME/my_libc_env/lib/x86_64-linux-gnu/ld-2.17.so $HOME/anaconda2/envs/tf_011g/bin/python2.7 "${#}"
You can specify where to find a particular shared library by setting the value of the environment variable LD_LIBRARY_PATH. The value is a colon-separated list of directory names; in this case, you want to prepend a specific directory so that it will be checked first.
LD_LIBRARY_PATH=/home/user/my_libc_env/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH /home/user/anaconda2/envs/tf_011g/bin/python2.7
A wrapper script makes this simpler, forgoing the need to remember either the library path or the path to your Python executable.
#!/bin/bash
export LD_LIBRARY_PATH=/home/user/my_libc_env/lib/x86_64-linux-gnu/:$LD_LIBRARY_PATH
/home/user/anaconda2/envs/tf_011g/bin/python2.7 "$#"
You can use subprocess.call("/usr/bin/python") to open Python shell within a piece of Python code. Now my question is is it possible to predefine some variables/functions before initialization of this shell? In other words, inside Python code, I can define a bunch of useful variables and functions and I want them to be available in the Python shell opened later by subprocess call. It is useful in the sense that sometimes you want a customized Python shell to test your environment.
You can do this using the -i switch. This will run a script, and then drop into the interpreter for interactive use.
python -i scriptname.py
Not directly, but I wouldn't do it this way anyways; I'd use code.
Yes, that's something that it's possible and it's useful. In fact, that's something that django provides with the python manage.py shell command.
Looking at the source code for this command should be helpful not only as an example to open a shell with some default configuration, but also to use any shell you like (ipython, bpython or the default one).