Nvchecker redirects its standard output into stderr

[Antiz96]

Hi,

nvchecker redirects its standard output in stderr (2) instead of stdout (1).

Steps to reproduce:

• Run nvchecker > /dev/null and see the standard nvchecker's output (xxx updated from x.x.x to x.x.x) still being displayed.
• Run nvchecker 2> /dev/null and see the standard nvchecker's output not being displayed.

This "non-standard" behavior forces to redirect stderr (2) instead of stdout (1) (or to redirect stderr into stdout first (2>&1)) when redirecting nvchecker's output (in a file or in a variable inside a script for instance), which is unexpected I guess. :smile:

Thanks for your amazing work on nvchecker by the way! :slightly_smiling_face:

[lilydjwg]

I consider this output to be logs, which are usually sent to stderr.

What's your use case to redirect the output? If you want to parse it, you should use the json log. If you want to show the result, you may use nvcmp.

[Antiz96]

I consider this output to be logs, which are usually sent to stderr.

Fair enough. What's your use case to redirect the output? If you want to parse it, you should use the json log. If you want to show the result, you may use nvcmp.

My use case is to have nvchecker being executed as a cron/scheduled job on a remote server and have its output sent to me by mail (thus redirect it into the mail body). nvcmp would work but does not provide the URL which is an important info to me. I'll take a look at the json log though.

However, I'm aware that this is an unconventional way to run nvchecker and that it is not necessarily meant to be ran like that. If you consider this the expected behavior, I can just continue using nvchecker 2>&1 on my side for the time being :)

[Antiz96]

I assume the actual issue is that I considered a "standard output" what is considered as logs on your side. I guess this issue can just be closed then? Sorry for the noise.

[lilydjwg]

My use case is to have nvchecker being executed as a cron/scheduled job on a remote server and have its output sent to me by mail.

I remember that cron daemons usually capture stderr as well? Anyway 2>&1 should work for you.

I assume the actual issue is that I considered a "standard output" what is considered as logs on your side.

Yes. And there may be other messages interleaved, e.g. a failed curl cmd.

[Antiz96]

Alright, sticking to 2>&1 makes sense for my specific case then.

I guess we can consider this issue closed. Thanks a lot for your time and your explanations!