We Keep Coding

Debugging fails when reading input from file [duplicate]

I am developing FUSE filesystem with python. The problem is that after mounting a filesystem I have no access to stdin/stdout/stderr from my fuse script. I don't see anything, even tracebacks. I am trying to launch pdb like this:
import pdb
pdb.Pdb(None, open('pdb.in', 'r'), open('pdb.out', 'w')).set_trace()
All works fine but very inconvenient. I want to make pdb.in and pdb.out as fifo files but don't know how to connect it correctly. Ideally I want to type commands and see output in one terminal, but will be happy even with two terminals (in one put commands and see output in another). Questions:
1) Is it better/other way to run pdb without stdin/stdout?
2) How can I redirect stdin to pdb.in fifo (All what I type must go to pdb.in)? How can I redirect pdb.out to stdout (I had strange errors with "cat pdb.out" but maybe I don't understand something)

Ok. Exactly what I want, has been done in http://pypi.python.org/pypi/rpdb/0.1.1 .

Before starting the python app
mkfifo pdb.in
mkfifo pdb.out
Then when pdb is called you can interact with it using these two cat commands, one running in the background
cat pdb.out & cat > pdb.in
Note the readline support does not work (i.e. up arrow)

I just ran into a similar issue in a much simpler use-case:
debug a simple Python program running from the command line that had a file piped into sys.stdin, meaning, no way to use the console for pdb.
I ended up solving it by using wdb.
Quick rundown for my use-case. In the shell, install both the wdb server and the wdb client:
pip install wdb.server wdb
Now launch the wdb server with:
wdb.server.py
Now you can navigate to localhost:1984 with your browser and see an interface listing all Python programs running. The wdb project page above has instructions on what you can do if you want to debug any of these running programs.
As for a program under your control, you can you can debug it from the start with:
wdb myscript.py --script=args < and/stdin/redirection
Or, in your code, you can do:
import wdb; wdb.set_trace()
This will pop up an interface in your browser (if local) showing the traced program.
Or you can navigate to the wdb.server.py port to see all ongoing debugging sessions on top of the list of running Python programs, which you can then use to access the specific debugging session you want.
Notice that the commands for navigating the code during the trace are different from the standard pdb ones, for example, to step into a function you use .s instead of s and to step over use .n instead of n. See the wdb README in the link above for details.

How do I associate python with py files in bash

A common question is "how do I make my python script executable without explicitly calling python on the command line?", and the answer is chmod +x it and then add #!/usr/bin/env python at the start of the script.
That is not the question I'm asking.
What I would like to do is tell bash, or python, or whatever is responsible for file-handling to treat all .py files that have the execute bit set as if they have the shebang at the beginning whether or not they actually do.
I understand that in Windows this can be done, and apparently in Gnome for the use-case where you double-click on a .py script from the GUI. I could have sworn I remembered hearing about an equivalent way of specifying a handler from the shell.
Why I want to know how to do this (if it's actually possible):
Not every system uses shebang and I don't want to clutter up files in a cross-platform project with it.
If I'm submitting a patch to a project I don't own, it's slightly obnoxious for me to put stuff unrelated to the patch into it for my own convenience.
Thanks.

Do you mean binfmt_misc?
binfmt_misc is a capability of the Linux kernel which allows arbitrary executable file formats to be recognized and passed to certain user space applications, such as emulators and virtual machines.
So you want to register an entry to it, so everytime you want to execute a .py file, the kernel will pass it to /usr/bin/python.
You can do it by trying something like this
# load the binfmt_misc module
if [ ! -d /proc/sys/fs/binfmt_misc ]; then
/sbin/modprobe binfmt_misc
fi
if [ ! -f /proc/sys/fs/binfmt_misc/register ]; then
mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc
fi
echo ':Python:E::py::/usr/bin/python:' > /proc/sys/fs/binfmt_misc/register
If you're using Debian-based distribution, you have to install binfmt-support.
You can add :Python:E::py::/usr/bin/python: to /etc/binfmt.d/python.conf so it's permenent after reboot.

Rio6's answer is correct. Only it is supported on practically no operating systems. You will need binfmt, you can compile it yourself from source at This git address

Enthought Canopy: Where do os.environ variables come from?

I have the following problem. I wanted to use the matplotlib package animation to save an mp4 video file. The save function has a dependency for generating the mp4 file, the ffmpeg external library. So I installed ffmpeg on a Mac osx 10.8 via Macports, and it got installed in /opt/local/bin .
But now, running the script in canopy, the interpreter (ipython shell) can not see ffmpeg. I added the path to my .bash_profile, and I can run the program at my terminal, but when I type os.environ['PATH'] the actual PATH of my shell was not added, and /opt/local/bin is not there.
If I try to run the script, I get this error:
/Users/alejandrodelacallenegro/Library/Enthought/Canopy_64bit/User/lib/python2.7/site- packages/matplotlib/animation.py:695: UserWarning: MovieWriter ffmpeg unavailable
warnings.warn("MovieWriter %s unavailable" % writer)
Any ideas to fix the problem? What I have to do to change an environmental variable that python sees at startup? Did anyone have the same problem?
Thanks.

The problem here has nothing to do with Enthought; it's that OS X doesn't run bash when you launch things from Finder, LaunchDaemons, etc., and therefore doesn't access your .bash_profile. Instead, it runs them from launchd.
If you want to add some environment variables to affect anything run by launchd for the current user, that's easy:
launchctl setenv PATH $PATH:/opt/local/bin
If you want this to happen every time you log in, if you create a file ~/.launchd.conf, the subcommands in that file will be run through launchctl every time launchd starts (which is the first step in logging in a new user session).
If you want it to be system-wide, rather than just for your user, you can sudo launchctl and/or create/edit /etc/launchd.conf. However, you almost certainly don't want to change the environment used by root services, etc., unless you really know what you're doing.
If it helps: Using launchctl manually, editing ~/.launchd.conf, and editing /etc/launchd.conf are roughly equivalent to export, ~/.bash_profile, and /etc/profile (except of course that they affect launchd rather than bash/sh).
See the launchctl(1) man page for details, or just type launchctl to start an interactive session and use the built-in help. (The pages launchd(8) and launchd.conf(5) also have useful info.)
You can also use the deprecated environment.plist file to affect even things that aren't run by launchd, but… that's deprecated, and there really isn't anything for it to affect that you care about, except in (much) older versions of OS X.
People coming from other Unix systems are often caught out by this. Most file managers ask the shell to run programs for them; Finder.app (and the command-line tool open, and the AppleScript environment, and so on) ask launchd to do it. Plus, on most X11 systems, if you look up the process tree from your file manager, it was ultimately launched by a user shell too, whereas on OS X, Finder.app was launched by launchd, which was launched by the system-wide launchd; no shell in sight.
This also means that other shell-specific stuff like changing resource limits or default umask won't affect programs started outside the shell on a Mac. launchctl is again the answer.

Zsh/Bash: Path isn't what it should be

I stumbled upon something I just can't figure out. Following situation: I downloaded the python frontend to control dropbox via command line (dropbox.py). I put this file in the folder:
/home/username1/.dropbox-dist/dropbox.py
I made a simple bash script in /usr/bin called "dropbox":
#!/bin/bash
python /home/username1/.dropbox-dist/dropbox.py
Now when i run it following happens:
The whereis for the file:
root#linux_remote /home/username1 # whereis dropbox
dropbox: /usr/bin/dropbox
When i run it:
root#linux_remote /home/username1 # dropbox
zsh: no such file or directory: /home/username2/.dropbox-dist/dropboxd
Yeah. It tells me another username. To be specific: I'm logged in via SSH on this linuxbox. On the remote shell there is byobu running. In byobu runs zsh. Username2 equals the user that I'm currently logged in with on my local linuxbox, with which I connected:
username2#linux_local /home/username2 # ssh username1#linux_remote
Thats how I am connected.
So there must be a variable which was passed to my remote shell from my local shell, and python seems to read it, but I can't figure out which it would be.
Now.. look at that: When I type in the command that I wrote into the bash script:
username2#linux_remote /home/username2 # python /home/username1/.dropbox-dist/dropbox.py
Dropbox command-line interface
So it runs if I do it manually.
Another thing: If I run it with the whole path it works too:
root#linux_remote /home/username1 # /usr/bin/dropbox
Dropbox command-line interface
And it does work if I run it via login-shell, for example using "bash -l" and then trying to run "dropbox".
It doesn't work either if I change the hashbang to "#!/usr/bin/zsh"
Any ideas on this?

whereis doesn't do what you think: it searches a specific set of directories, not $PATH. which searches $PATH so you need to use which to find out which executable will be executed by a given name.
Edit: which as an external program (for shells that do not have a builtin command, such as bash) will not give a right answer for some cases, e.g. shell aliases. The type builtin should be used instead (it also should be available more widely as it's mandated by POSIX, though not necessarily as a builtin).

when we need use sudo python xxx.py or just python xxx.py or xxx.py

I have write a website,what confused me is when i run the website,first i need start the the app,
so there are 3 ways:
sudo python xxx.py
python xxx.py
xxx.py
I didn't clear with how to use each of them,the NO.3 method currently in my computer dosen't work well

sudo will run the application with superuser permissions. Considering that you're referring to a website, this is certainly not what you want to do. (For a webapp, if it requires superuser permissions, it's broken. That's far, far too big of a security risk to consider actually using.)
Under other circumstances you might have a python program that does some sort of system maintaince and requires being run as root. In this case, you'd use sudo, but you would never want to do this for something that's publicly accessible and could potentially be exploited. In fact, for anything other than testing, you should probably run the webapp as a separate user with very limited access (e.g. with their shell set to /dev/null, no read or write access to anything that they don't need, etc...).
The other two are effectively identical (in therms of what they do), but the last option (executing the script directly) will require:
the executable bit to be set (on
unix-y systems) (e.g. chmod +x whatever.py)
a shebang on the first line(e.g. #!
/usr/bin/python) pointing to the
python execuctable that you want to
run things with (again, this only applies to unix-y systems)
Calling python to run the code (python whatever.py) and following the steps above (resulting in a script that you can call directly with whatever.py)
do exactly the same thing (assuming that the shebang in the python file points to the same python executable as "python" does, anyway...)