I am currently using PyCUDD, which is a SWIG-generated Python wrapper for the C package CUDD. I'm currently trying to get CUDD to print some debug information from inside the C code, but any printfs inside the C code don't seem to be producing any output - putting them in the .i files for SWIG produces output, putting them in the C code does not. I'm not sure if this is some property of SWIG specifically or of compiling the C code to a shared object library.
(Particularly frustrating is that I know that I have had this problem and gotten it working before, but I can't seem to find anything searching for the problem now, and I apparently forgot to leave notes on that one thing.)
I think problem is that Launched program closes (or redirects original stdout handler/descriptor to somewhere) stdout, so Library cannot gets Handler/descriptor. So I tried to recover devices and reopen.
In linux, console device is located at /dev/stdout (it is symbolic link to specific devices or file located in fd 1 at launched time), so reopen this file and recover file descriptor.
int fd = open("/dev/stdout", O_RDONLY);
if(fd != -1)
dup2(fd,1);
In Windows, AllocConsole tries to create new Console if current process does not have console. This is for the case when PyCUDD(Or any program) uses custom console. And freopen makes writable to our allocated console, so printf will work for new console.
AllocConsole();
freopen("CONOUT$", "w", stdout);
I still forget what my problem was before. However, I have found that what was causing my problem here was a linker issue - the linker was looking at an old version of the library, which did not have my changes.
Related
I'm building an electronjs python application and I'm using the pythonshell module. The electron application is supposed to log any messages my python script prints to the console, but rather than printing each message when it's supposed to be printed it waits until the script has finished executing and then prints everything. I've tried using sys.stdout.write("message") and then sys.stdout.flush(), but it still doesn't work.
The question I'm linking has a similar problem that I do, but the answer that worked for them didn't work for me on the electron application. It's flushing properly on the python backend, the frontend is what's causing the problem.
Similar question: Python sys.stdout.flush() doesn't work
file.flush() does not necessarily write the file’s data to disk!. you need to Use flush() followed by os.fsync(fd) to ensure this behavior.
see below:
sys.stdout.flush()
os.fsync(sys.stdout.fileno())
os.fsync(fd) documentation from python docs
Force write of file with file descriptor fd to disk. On Unix, this
calls the native fsync() function; on Windows, the MS _commit()
function.
If you’re starting with a Python file object f, first do f.flush(),
and then do os.fsync(f.fileno()), to ensure that all internal buffers
associated with f are written to disk.
I am running gnu linux (Linux Mint to be specific). The following is my desired workflow:
I open vim in (say) process 1000 and then start up a python interpreter in process 1001.
I write some code in vim and then select certain lines and then write those lines to the file /proc/1001/fd/0.
At this point I would like the python interpreter to interpret this as code and execute it as if it were typed in directly.
This does not work as desired. Instead the text is displayed on the interpreter's screen, but it is not executed (similar to when error messages of subprocesses are displayed in bash). I presume this has something to do with the fact that my workflow isn't playing well with readline (or some sort of equivalent library). Or my problem might just be that the python interpreter was never designed to be used this way (for presumably security and other reasons).
I understand there are many IDEs with similar functionality, but I was hoping that something simple might work. I'm curious if it's something that can be fixed or if there is something fundamental that I'm misunderstanding.
It exists and it's called vim-slime
The only requirement is that you run the Python interpreter inside tmux or screen, or even better: byobu
Installing the vim-slime plugin is easy if you're using vim-pathogen:
cd ~/.vim/bundle
git clone git://github.com/jpalardy/vim-slime.git
See the vim-slime page for configuration details, but if you're using tmux, simply add the following to your .vimrc and re-start Vim:
let g:slime_target = "tmux"
Trying it out
Type in some Python code inside Vim:
def fib():
a, b = 0, 1
while 1:
yield a
a, b = b, a + b
Then press Ctrl-c-Ctrl-c to tell vim-slime to send the contents of your current buffer to another window. The first time you run it, vim-slime will ask you which screen/tmux window to send it to, but after that, press the key-sequence and it will send it wherever you told it to the first time.
vim-slime is visual-mode aware, too! If you only want to send a few lines to Python, enter visual-line mode with V, highlight the lines you want, and press the same Ctrl-c-Ctrl-c key sequence to send just those line.
Edit: Oops! I accidentally posted code that didn't match my question. I started writing this post before I was done experimenting, so I posted code from an intermediate point in my testing process. I've amended this question to reflect what I really meant to post by changing the code slightly.
The following Python code works as expected with one problem: unless I If verbose == False, the file produced by the Perl script is not created. Why do I have to call output.stdout.read() for the underlying Perl script to successfully create a file?
cmdStringList = ["perl","script.pl","arg1",...]
output = subprocess.Popen(cmdStringList,stdout=subprocess.PIPE)
if verbose:
print output.stdout.read()
I didn't even realize anything was wrong until I tried to execute my Python script with verbose=False in a production environment. I did some google-fu to try to understand the behavior of Popen and subprocess, but I haven't come up with a reason for this behavior. Any help would be greatly appreciated.
You actually have the following code, right?
if verbose:
outputRead = output.stdout.read()
print outputRead
It's quite likely that the problem is that the child is blocked trying to write to STDOUT. Until you make some space in the pipe by reading from it, the child won't be able to finish writing to STDOUT and move on to where it creates the file to which you refer.
If you want to prevent the child from blocking without reading, redirect its stdout to nul (Windows) or /dev/null (elsewhere). This should work everywhere but Windows:
cmdStringList = ["sh","-c","\"$0\"" \"$#\" >/dev/null","perl","script.pl","arg1",...]
(Pardon any syntax errors. I don't know Python at all.)
You should keep reading a stream, otherwise the buffer may become full, then your perl process may get blocked. It has nothing to do with a specific language but the underyling operating system.
I encountered a similar problem when I use Java.
I'm trying to run an external, separate program from Python. It wouldn't be a problem normally, but the program is a game, and has a Python interpreter built into it. When I use subprocess.Popen, it starts the separate program, but does so under the original program's Python instance, so that they share the first Python console. I can end the first program fine, but I would rather have separate consoles (mainly because I have the console start off hidden, but it gets shown when I start the program from Python with subprocess.POpen).
I would like it if I could start the second program wholly on its own, as though I just 'double-clicked on it'. Also, os.system won't work because I'm aiming for cross-platform compatibility, and that's only available on Windows.
I would like it if I could start the second program wholly on its own, as though I just 'double-clicked on it'.
As of 2.7 and 3.3, Python doesn't have a cross-platform way to do this. A new shutil.open method may be added in the future (possibly not under that name); see http://bugs.python.org/issue3177 for details. But until then, you'll have to write your own code for each platform you care about.
Fortunately, what you're trying to do is simpler and less general than what shutil.open is ultimately hoped to provide, which means it's not that hard to code:
On OS X, there's a command called open that does exactly what you want: "The open command opens a file (or a directory or URL), just as if you had double-clicked the file's icon." So, you can just popen open /Applications/MyGame.app.
On Windows, the equivalent command is start, but unfortunately, that's part of the cmd.exe shell rather than a standalone program. Fortunately, Python comes with a function os.startfile that does the same thing, so just os.startfile(r'C:\Program Files\MyGame\MyGame.exe').
On FreeDesktop-compatible *nix systems (which includes most modern linux distros, etc.), there's a very similar command called xdg-open: "xdg-open opens a file or URL in the user's preferred application." Again, just popen xdg-open /usr/local/bin/mygame.
If you expect to run on other platforms, you'll need to do a bit of research to find the best equivalent. Otherwise, for anything besides Mac and Windows, I'd just try to popen xdg-open, and throw an error if that fails.
See http://pastebin.com/XVp46f7X for an (untested) example.
Note that this will only work to run something that actually can be double-clicked to launch in Finder/Explorer/Nautilus/etc. For example, if you try to launch './script.py', depending on your settings, it may just fire up a text editor with your script in it.
Also, on OS X, you want to run the .app bundle, not the UNIX executable inside it. (In some cases, launching a UNIX executable—whether inside an .app bundle or standalone—may work, but don't count on it.)
Also, keep in mind that launching a program this way is not the same as running it from the command line—in particular, it will inherit its environment, current directory/drive, etc. from the Windows/Launch Services/GNOME/KDE/etc. session, not from your terminal session. If you need more control over the child process, you will need to look at the documentation for open, xdg-open, and os.startfile and/or come up with a different solution.
Finally, just because open/xdg-open/os.startfile succeeds doesn't actually mean that the game started up properly. For example, if it launches and then crashes before it can even create a window, it'll still look like success to you.
You may want to look around PyPI for libraries that do what you want. http://pypi.python.org/pypi/desktop looks like a possibility.
Or you could look through the patches in issue 3177, and pick the one you like best. As far as I know, they're all pure Python, and you can easily just drop the added function in your own module instead of in os or shutil.
As a quick hack, you may be able to (ab)use webbrowser.open. "Note that on some platforms, trying to open a filename using this function, may work and start the operating system’s associated program. However, this is neither supported nor portable." In particular, IIRC, it will not work on OS X 10.5+. However, I believe that making a file: URL out of the filename actually does work on OS X and Windows, and also works on linux for most, but not all, configurations. If so, it may be good enough for a quick&dirty script. Just keep in mind that it's not documented to work, it may break for some of your users, it may break in the future, and it's explicitly considered abuse by the Python developers, so I wouldn't count on it for anything more serious. And it will have the same problems launching 'script.py' or 'Foo.app/Contents/MacOS/foo', passing env variables, etc. as the more correct method above.
Almost everything else in your question is both irrelevant and wrong:
It wouldn't be a problem normally, but the program is a game, and has a Python interpreter built into it.
That doesn't matter. If the game were writing to stdout from C code, it would do the exact same thing.
When I use subprocess.Popen, it starts the separate program, but does so under the original program's Python instance
No it doesn't. It starts an entirely new process, whose embedded Python interpreter is an entirely new instance of Python. You can verify that by, e.g., running a different version of Python than the game embeds.
so that they share the first Python console.
No they don't. They may share the same tty/cmd window, but that's not the same thing.
I can end the first program fine, but I would rather have separate consoles (mainly because I have the console start off hidden, but it gets shown when I start the program from Python with subprocess.POpen).
You could always pipe the child's stdout and stderr to, e.g., a logfile, which you could then view separately from the parent process's output, if you wanted to. But I think this is going off on a tangent that has nothing to do with what you actually care about.
Also, os.system won't work because I'm aiming for cross-platform compatibility, and that's only available on Windows.
Wrong; os.system is available on "Unix, Windows"--which is probably everywhere you care about. However, it won't work because it runs the child program in a subshell of your script, using the same tty. (And it's got lots of other problems—e.g., blocking until the child finishes.)
When I use subprocess.Popen, it starts the separate program, but does so under the original program's Python instance...
Incorrect.
... so that they share the first Python console.
This is the crux of your problem. If you want it to run in another console then you must run another console and tell it to run your program instead.
... I'm aiming for cross-platform compatibility ...
Sorry, there's no cross-platform way to do it. You'll need to run the console/terminal appropriate for the platform.
file_read = open("/var/www/rajaneesh/file/_config.php", "r")
contents = file_read.read()
print contents
file_read.close()
The output is empty, but in that file all contents are there. Please help me how to do read and replace a string in __conifg.php.
Usually, when there is such kind of issues, it is very useful to start the interactive shell and analyze all commands.
For instance, it could be that the file does not exists (see comment from freiksenet) or you do not have privileges to it, or it is locked by another process.
If you execute the script in some system (like a web server, as the path could suggest), the exception could go to a log - or simply be swallowed by other components in the system.
On the contrary, if you execute it in the interactive shell, you can immediately see what the problem was, and eventually inspect the object (by using help(), dir() or the module inspect). By the way, this is also a good method for developing a script - just by tinkering around with the concept in the shell, then putting altogether.
While we are here, I strongly suggest you usage of IPython. It is an evolution of the standard shell, with powerful aids for introspection (just press tab, or a put a question mark after an object). Unfortunately in the latest weeks the site is not often not available, but there are good chances you already have it installed on your system.
I copied your code onto my own system, and changed the filename so that it works on my system. Also, I changed the indenting (putting everything at the same level) from what shows in your question. With those changes, the code worked fine.
Thus, I think it's something else specific to your system that we probably cannot solve here (easily).
Would it be possible that you don't have read access to the file you are trying to open?