Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redirecting report output to STDOUT #18

Open
hellais opened this issue Sep 13, 2018 · 0 comments
Open

Redirecting report output to STDOUT #18

hellais opened this issue Sep 13, 2018 · 0 comments
Labels
enhancement New feature or request

Comments

@hellais
Copy link
Member

hellais commented Sep 13, 2018

@0xPoly commented on Fri Oct 02 2015

While working on network meter during the ooni mini-hackathon in Rome, we attempted to redirect the output of the report to STDOUT to be more easily parsed.

Running ooniprobe -i some.deck -o - creates report files called -.yamloo. ooniprobe -i some.deck -o /dev/stdout tries to create /dev/stdout.yamloo and fails due to lack of permissions.

Perhaps ooniprobe can detect the - option and redirect report output to STDOUT, or offer a way to specify file names while not adding the .yamloo extension.


@0xPoly commented on Fri Oct 02 2015

Talking to @bassosimone, we discussed how forcing you to write files to disk significantly reduces your plausible deniability. In network meter, we plan to bundle OONI by default - so if there are no disk traces it would be difficult to prove that you had run OONI and not just used any of the other measurement tools (like speed test).


@bassosimone commented on Sun Oct 11 2015

@0xPoly I think -o- is better than -o/dev/stdout because the former makes sense also on Windows operating systems while the latter is more UNIX specific. (Also there is prior art regarding -o-; see for example curl, wget, and tar).


@hellais commented on Wed Dec 02 2015

I like this a lot and it makes a lot of sense to support this. The only question I have is how to handle writing to standard out when you run a test deck.

In that we would have to take care of the following things either:

  • handle buffering
  • running of tests should happen sequentially when such flag is set
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant