Pipe into text or grep not working

Help and Support
1

Hi there

I have a very stupid issue, do you have an idea, why the following commands are not working?

./rclone check “/mypath with spaces” “gdrive:/myremote path with space foldernames/” > txt.txt (this is writing an EMTPY text file

./rclone check “/mypath with spaces” “gdrive:/myremote path with space foldernames/” | grep something

both commands are printing a lot of stuff. But it’s not written into the text file, nor the grep is working :slight_smile: Thanks for your help!

2

Howdy Steve,

Please try:

rclone comand parameters 2>&1 | less
rclone comand parameters >txt.txt 2>&1

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).

Cheers,

Durval.

3

Hi Durval, awesome, thanks a lot for your help. This works!

4

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.

What do you think?

5

Hi Nick,

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.

Cheers,

Durval.

6

I think there is a lot to be said for that.

Note this is also under discussion here...

7

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.

1 Like