[TW-1908] STDERR potentially abused for status messages while running 'task sync'
rjc on 2017-04-19T04:34:00Z says:
Hi,
Task is potentially abusing STDERR for some of its status messages. This issue is easily observed by running "task sync" from cron(8). Namely, when I run it from said cron(8) I would very much like to get an email only when there's a real issue running the above command. Obviously, I can just redirect STDOUT to /dev/null:
task sync > /dev/null
However, I still get this message on STDERR output:
Sync successful. No changes.
OK, let's try the other way around - redirect STDERR to /dev/null:
task sync 2> /dev/null
The problem with that approach is that I get another message, this time to STDOUT:
Syncing with my.task.server:53589
Sure, I can redirect both to /dev/null like so:
task sync > /dev/null 2>&1
and that's what I'm currently using but, in case there's a real error (i.e. error code != 0), I won't see it as I already redirected both STDOUT and STDERR to /dev/null, to merely silence the status messages of 'task sync'.
Currently I'm running something like this:
task sync > /dev/null 2>&1 || echo "Something went wrong - run 'task sync' again to see what it was."
I understand that STDERR was probably chosen for a reason but it feels like one needs to jump through quite a number of hoops to get 'task sync' working from cron(8) without emails for every single sync and with emails only when there's a failure. It's never too late to change it! :^)
Regards,
Raf
Migrated metadata:
Created: 2017-04-19T04:34:00Z
Modified: 2017-12-11T13:05:02Z
Philipp Woelfel on 2017-06-14T22:00:56Z says:
I agree, it is annoying that the message "Sync successful." gets sent to STDERR. Since it is a success message, it makes no sense.
As a workaround I use the following line in my crontab:
/bin/bash -c "/usr/bin/task sync 2> >(grep -v 'Sync successful.') 1> /dev/null"
Paul Beckingham on 2017-10-12T03:13:29Z says:
Good suggestion. A message on STDERR does not qualify as "Major Bug".
Note: Don't run sync from cron, it's a bad idea.
rjc on 2017-10-12T03:39:54Z says:
Not sure why I would have marked it as Major - must've selected it looking at the initial letter and thinking of Minor as per your system:
- Minor - Minor loss of function, or other problem where easy workaround is present.
- Trivial - Cosmetic problem like misspelt words or misaligned text.
Certainly not Trivial.
In terms of running task sync from cron - I have taskwarrior set up on multiple machines so, if I'm working on another one where tasks are out of sync, I'd have to run task sync manually before doing anything anyway. How is running it from cron any different and a bad idea? The Android app does it automatically, too. Is there a recommended way of achieving the same thing?
Paul Beckingham on 2017-12-02T19:31:49Z says:
CLI commands can collide with a cron command that just happens to be running. It is suspected that this causes data corruption, although we have no reproducible case. It is likely caused by cooperative file locking not working.
Thus, it is a bad idea to increase the likelihood of a not-well-understood potential data corruption bug.
rjc on 2017-12-11T13:05:02Z says:
OK, so what you describe here is two sync commands running at the same time - this is no different to opening two TTYs and running task sync on them, which is obviously plain silly.
I still maintain that a cron job itself is not in any way less secure than running sync command manually.
What you describe above - running a cron job and running a task sync command manually - can be easily mitigated by using a helper script in the form of:
test -f /tmp/task-sync-is-running || \{
touch /tmp/task-sync-is-running
task sync
rm /tmp/task-sync-is-running
} && \{
echo "'task sync' is currently running
exit 1
``}
Now, none of the above is related to the initial bug report which, IMVHO, still needs fixing.