Skip to content

(FACT-865) Split stdout and stderr handling in execution.#900

Merged
MikaelSmith merged 1 commit intopuppetlabs:masterfrom
peterhuene:splitting-stderr
Apr 8, 2015
Merged

(FACT-865) Split stdout and stderr handling in execution.#900
MikaelSmith merged 1 commit intopuppetlabs:masterfrom
peterhuene:splitting-stderr

Conversation

@peterhuene
Copy link

This implements a new pipe for reading stderr in addition to stdout from
child processes. Previously, stderr was optionally redirected to
stdout or to the null device if not merging the two streams. This change
allows child process execution to treat stdout and stderr as two
separate streams, enabling the ability to process stdout while logging
stderr messages (e.g. external executable facts).

The execute functions now return a tuple of both the stdout and stderr
contents. The each_line functions now take an additional function
object to call when a line of stderr is read.

@peterhuene peterhuene added the PL label Mar 30, 2015
@peterhuene peterhuene force-pushed the splitting-stderr branch 2 times, most recently from 2e1b759 to 2b31c89 Compare March 31, 2015 01:13
@puppetcla
Copy link

CLA signed by all contributors.

@MikaelSmith MikaelSmith self-assigned this Mar 31, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we specify which pipe we're closing?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should really be "closing child pipes", as both pipes will close when we stop processing. Will fix.

@MikaelSmith
Copy link

I'd argue for always logging stderr if redirect_stderr_to_null is chosen and a severity level of DEBUG or more is chosen.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No equivalent test on Windows?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add one for the PS resolver too.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also run batch and cmd files on Windows. That's more what I was thinking of, but batch and PS are good.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, was just going to add a batch + another test for the PS resolver specifically.

@MikaelSmith
Copy link

First review pass done, nice work.

@peterhuene
Copy link
Author

I'll see about logging output when redirecting to null with a log level of >= debug.

@peterhuene peterhuene force-pushed the splitting-stderr branch 2 times, most recently from 949d598 to 1cdcbdd Compare April 7, 2015 21:24
This implements a new pipe for reading stderr in addition to stdout from
child processes.  Previously, stderr was optionally redirected to
stdout or to the null device if not merging the two streams.  This change
allows child process execution to treat stdout and stderr as two
separate streams, enabling the ability to process stdout while logging
stderr messages (e.g. external executable facts).

The execute functions now return a tuple of both the stdout and stderr
contents.  The each_line functions now take an additional function
object to call when a line of stderr is read.
@peterhuene
Copy link
Author

Okay, all feedback taken into account and this should now (hopefully) pass CI. Ready for one last review.

@MikaelSmith
Copy link

👍 Looks good to me.

MikaelSmith pushed a commit that referenced this pull request Apr 8, 2015
(FACT-865) Split stdout and stderr handling in execution.
@MikaelSmith MikaelSmith merged commit 7b344e0 into puppetlabs:master Apr 8, 2015
@peterhuene peterhuene deleted the splitting-stderr branch April 8, 2015 18:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants