Opened 9 months ago
Last modified 3 months ago
#26999 new enhancement
tor_api: Some way to capture stdout/stderr
| Reported by: | nickm | Owned by: | |
|---|---|---|---|
| Priority: | Medium | Milestone: | Tor: unspecified |
| Component: | Core Tor/Tor | Version: | |
| Severity: | Normal | Keywords: | |
| Cc: | hellais | Actual Points: | |
| Parent ID: | #25510 | Points: | |
| Reviewer: | Sponsor: |
Description
In #25510, hellais says:
- Ability to get the output of tor_run_main() without having to mock standard out
There is a wealth of information inside of the log output of tor, which would be nice if it were exposed in a more API friendly way (maybe some sort of callback function?) so that a user of the library doesn't have to mock stdout/stderr.
Child Tickets
Change History (2)
comment:1 Changed 9 months ago by
comment:2 Changed 3 months ago by
| Sponsor: | Sponsor8-can |
|---|
Note: See
TracTickets for help on using
tickets.
If this is just about log messages, it's easier to do.
If it's about _everything_ sent over stdout or stderr, that is less easy.
A callback is not what I'd favor here, since libtorrunner.a couldn't support it easily, and since introducing a system of callbacks would complicated the control flow between tor and its embedding applications. But maybe we can make capturing this stuff easier. The early-log-messages ideas in #10059 might help here, as might some mechanism to have the owningcontrollerfd feature start out with a preconfigured set of events.