Closed kevincox closed 3 years ago
Side note: A workaround is using -q
to disable the logs, however it is a shame to lose the logs.
Hmm, indeed. I really didn't know we should write logs and messages to stderr
and thought stdout
should be the default. I searched the Internet and it seems there's mixed opinions regarding that. Is there any particular reason why informative logs should be on the stderr? I guess if we consider them debugging, yes.
I can make a PR for this soon.
Yes, that is what stderr is for. It is for human readable output.
For example when you install packages and smilar npx writes the logs to stderr so that something like npx sometool >result
will properly store the output of tool, the the logs and errors of npx itself. Many tools work like this for example nix-build
will write the logs to stderr and the result path to stdout. That is why there are two output streams. There is one for the output of the program (which in this case appear to just be the hash) and another stream for helpful messages such as logs and errors.
Basically stdout is for robots (and humans too) and stderr is for humans.
Here's a PR: https://github.com/ipfs-shipyard/ipfs-deploy/pull/216
Thanks for explaining this!
Previously only the final CID was printed to stdout. This was really useful because you could simply redirect the CID to a file. However now all long output is printed to stdout. Since this log output is intended for humans not robots it is better suited for stderr.
Compare the difference: