2

I'm calling a subprocess and want to disable any output to my shell. I'm trying to do this with:

 with tempfile.TemporaryFile() as tempf:
        proc = Popen(cmd, stdout=tempf, stderr=tempf)
        proc.communicate()

But there is still some output (but less than normally) appearing at the terminal. Could the problem be that the called process uses os.execvp? Any suggestions to fully disable the output for all subprocesses?

Note

Redirecting to devnull is a better way of disabling output:

with open(os.devnull, 'w') as tempf:
    proc = Popen(cmd, stdout=tempf, stderr=tempf)
    proc.communicate()

Question answered!

Very simple solution: The called process uses CORBA and the server is actually printing out.

schlamar
  • 9,238
  • 3
  • 38
  • 76
  • Your example is using ``popen()``, not ``subprocess`` – Martin Tournoij Feb 05 '12 at 22:46
  • subprocess inherit the stdout's and stderr's from their parents by default. Short of going on the hunt for wild ttys, there's no way a subsubprocess can get your stdin. Which programs are you executing? – phihag Feb 05 '12 at 22:46
  • 1
    @Carpetsmoker: Popen lives in module subprocess in newer python versions – Johan Lundberg Feb 05 '12 at 22:47
  • @Carpetsmoker Nope, notice the upper-case `P`. He just executed `from subprocess import Popen`. `os.popen` does not take any keyword arguments anyways, and would therefore fail immediately. – phihag Feb 05 '12 at 22:48
  • 4
    Side note: Sending stderr and stdout to a temporary file is not a good way to discard output. Just open `os.devnull` for writing. – Marcelo Cantos Feb 05 '12 at 22:54
  • @MarceloCantos: Thanks for your advice, didn't know this will work. – schlamar Feb 05 '12 at 22:56
  • @phihag I'm calling "Salome", a pre processor fur numerical simulation. I'm using the command "runSession" as described here: http://docs.salome-platform.org/salome_6_4_0/gui/KERNEL/SALOME_Application.html – schlamar Feb 05 '12 at 22:59
  • Unfortunately, writing to `/dev/null` does not solve the issue. – schlamar Feb 05 '12 at 23:05
  • @ms4py Switching to /dev/null won't change the output, but will prevent a huge temporary file from being created. Salome looks to be really powerful - can you reproduce the problem with a command that's widely available/pre-installed? If not, you should post the output of `strace -ff python your-python-program.py` to [pastebin](http://pastebin.com) or so, so that we can detect how salome is writing stuff out. As I said, my guess would be that a component is going hunting for wild ttys (for secure password input or so) – phihag Feb 05 '12 at 23:14
  • @phihag `strace` is running for about 5 minutes now (execution usually needs about 30 secs) and is producing million lines of output. Another idea? – schlamar Feb 05 '12 at 23:26
  • strace will make it slower, but only by a factor of about 10. Are you using the `-o` option? You can also limit the output with `-e trace=fork,execve,open`. Also, you don't have to strace everything - you can abort strace and the program as soon as the error case (any output at all) occurs. – phihag Feb 05 '12 at 23:29
  • @phihag: Well, I have an output with >100 MB (output is already limited). – schlamar Feb 05 '12 at 23:39
  • Well, 100MB is handle-able. Can you upload that somewhere? I'd grep for `tty` or `/proc/`. By the way, have you absolutely excluded the possibility that another part of your top-level python program is causing the output? If you comment out the lines you included in this question, do you still get the offending output? – phihag Feb 06 '12 at 00:18
  • Oh, very simple solution. Salome is using CORBA and the server wasn't started with redirecting output to `/dev/null`. Thanks for the suggestions :-) – schlamar Feb 06 '12 at 00:33

1 Answers1

-2

As described above, the called process was calling a server, which produced the mysterios stdout.

schlamar
  • 9,238
  • 3
  • 38
  • 76