On most stock OSes, this will show your password to anyone who views the list of processes on the machine.
Try 'imapsync' [1] instead, as it uses a config file for your credentials instead of command-line arguments, keeping the secret(s) out of the process list.
Also, the author of this blog post is showing his inexperience:
> BaGoMa's output is pretty informative so I send it to log a file in case I ever want to check up on it and make sure the backups are still working.
You won't ever do that (no reason to check the logs when it's working), and it will fail (effectively-silently) one day without you noticing, and then you won't have backups when you actually find that you need them. Don't do it that way.
Instead, use a cronjob wrapper script (e.g. [2]) that is silent on success and outputs on error, so the "cronjob-output-as-email" feature works to notify you when it breaks.
> Try 'imapsync' [1] instead, as it uses a config file for your credentials instead of command-line arguments, keeping the secret(s) out of the process list.
Given where he said the box resides, I'd say he's got a major problem if unfriendlies are in s position to run ps -eF on it, no matter what is in the command strings, LOL!
And, if they can run ps, they can more than likely read the config files, too!
> Instead, use a cronjob wrapper script (e.g. [2]) that is silent on success and outputs on error, so the "cronjob-output-as-email" feature works to notify you when it breaks.
My point was that I don't want to use the password. Don't want it in my cronjob file, don't want it in my logfiles. It's really bad practice of programs to rely on the Password. On the bright side, gmail also allows you to generate application specific passwords.
Try 'imapsync' [1] instead, as it uses a config file for your credentials instead of command-line arguments, keeping the secret(s) out of the process list.
Also, the author of this blog post is showing his inexperience:
> BaGoMa's output is pretty informative so I send it to log a file in case I ever want to check up on it and make sure the backups are still working.
You won't ever do that (no reason to check the logs when it's working), and it will fail (effectively-silently) one day without you noticing, and then you won't have backups when you actually find that you need them. Don't do it that way.
Instead, use a cronjob wrapper script (e.g. [2]) that is silent on success and outputs on error, so the "cronjob-output-as-email" feature works to notify you when it breaks.
[1] http://imapsync.lamiral.info/
[2] https://github.com/sneak/misc/blob/master/cronify/cronify