Otherwise stdout output is lost if we pass the same filename for stdout and stderr. --- iutil.py | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/iutil.py b/iutil.py index c482b18..9a53b16 100644 --- a/iutil.py +++ b/iutil.py @@ -36,15 +36,24 @@ def execWithRedirect(command, argv, stdin = 0, stdout = 1, stderr = 2, if not searchPath and not os.access (command, os.X_OK): raise RuntimeError, command + " can not be run"
+ def try_truncate(f): + try: + f.truncate(0) + except IOError, e: + # will fail for e.g. for /dev/tty5 + pass + if type(stdin) == type("string"): if os.access(stdin, os.R_OK): stdin = open(stdin) else: stdin = 0 if type(stdout) == type("string"): - stdout = open(stdout, "w") + stdout = open(stdout, "a") + try_truncate(stdout) if type(stderr) == type("string"): - stderr = open(stderr, "w") + stderr = open(stderr, "a") + try_truncate(stderr)
try: proc = subprocess.Popen([command] + argv, stdin=stdin, stdout=stdout,
On Mon, Aug 29, 2011 at 05:17:23PM +0200, Ales Kozumplik wrote:
Otherwise stdout output is lost if we pass the same filename for stdout and stderr.
iutil.py | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/iutil.py b/iutil.py index c482b18..9a53b16 100644 --- a/iutil.py +++ b/iutil.py @@ -36,15 +36,24 @@ def execWithRedirect(command, argv, stdin = 0, stdout = 1, stderr = 2, if not searchPath and not os.access (command, os.X_OK): raise RuntimeError, command + " can not be run"
- def try_truncate(f):
try:f.truncate(0)except IOError, e:# will fail for e.g. for /dev/tty5pass- if type(stdin) == type("string"): if os.access(stdin, os.R_OK): stdin = open(stdin) else: stdin = 0 if type(stdout) == type("string"):
stdout = open(stdout, "w")
stdout = open(stdout, "a")try_truncate(stdout)
stderr = open(stderr, "w")
stderr = open(stderr, "a")try_truncate(stderr)try: proc = subprocess.Popen([command] + argv, stdin=stdin, stdout=stdout,
-- 1.7.6
Is this any safer? Seems like Popen is still going to have the same file open twice. In RHEL6 we seem to be using pipes and tee to manage the output streams from the process.
On 08/29/2011 08:50 PM, Brian C. Lane wrote:
Is this any safer? Seems like Popen is still going to have the same file open twice. In RHEL6 we seem to be using pipes and tee to manage the output streams from the process.
Yes, but I wouldn't like to fix this particular bug at the cost of merging all of that.
I think in fact both of the ways are 'safe': it is just the operating system doesn't advance the seek position of each of the (underlying) descriptors (which are indeed used by subprocess.py by calling .fileno() on the file object) in the old version, but it does that in the second, just as described by man 2 open, section O_APPEND.
Does that convince you? We might see a bug or two about this in the future but it is already broken at the moment.
Ales
On Tue, Aug 30, 2011 at 08:31:04AM +0200, Ales Kozumplik wrote:
On 08/29/2011 08:50 PM, Brian C. Lane wrote:
Is this any safer? Seems like Popen is still going to have the same file open twice. In RHEL6 we seem to be using pipes and tee to manage the output streams from the process.
Yes, but I wouldn't like to fix this particular bug at the cost of merging all of that.
I think in fact both of the ways are 'safe': it is just the operating system doesn't advance the seek position of each of the (underlying) descriptors (which are indeed used by subprocess.py by calling .fileno() on the file object) in the old version, but it does that in the second, just as described by man 2 open, section O_APPEND.
Does that convince you? We might see a bug or two about this in the future but it is already broken at the moment.
Yep :) Ack.
anaconda-devel@lists.stg.fedoraproject.org
-
Ales Kozumplik -
Brian C. Lane