if you are using a Bourne-compatible shell (bash, etc), or
rclone comand parameters |& less
rclone comand parameters >& txt.txt
if you are using a C-shell compatible one (tcsh, etc).
(and the issue is not stupid, actually it’s arguable whether rclone’s output shouldn’t be directed to stdout instead of stderr as it seems to be, for everything but basic 'usage: ’ messages. @ncw, what do you think? I’ve thought about opening an issue for that a few days ago, but ended up letting it slide).
The log messages are directed to stderr which I think is sensible, but the output of the check command is written as a log message which is probably the bit where we are going wrong - it should probably be written to stdout.
IMHO rclone would do well to follow the GUT (Great Unix Tradition): only error messages (including the one-line "usage: " message emitted in case of an error in the command-line) should go to stderr; everything else should be written to stdout.
Thank you for looping me into this conversation. I’ve worked around the way that rclone has used stderr, but I agree that only errors should go to stderr. In my familiarity with the command line, output that is reporting stuff (for example the check command) has typically gone to stdout.
The way I use the check command is to redirect the output to generate a status email. Having that go to stderr means I have to add 2>&1 to the command, which is fine just unconventional.