# the above will never work unless you start script as you
# say you are user fred, this full path will always work
Cron works with different permissions and PATH than user, in other words cron basically is its own user (root), with its own PATH etc. Don't use ~/, that refers to another home directory, not yours, when cron starts the job, that ~/ is relative to the home directory of the user in the system that starts the job (root in this case). Use the full path for 'brew update' (and if you can, get rid of that directory name with the space in it, if it's under your control). I have no idea what cron even does with ~/ in terms of generating a path because it will never work predictably so I never thought about that.
With cron, ALWAYS use full system paths, or you will get these kinds of errors.
what user will [cron] run as?
They all run as root. If you need otherwise, use su in the script or
add a crontab entry to the user's crontab (man crontab) or the
system-wide crontab (whose location I couldn't tell you on CentOS).
So in theory, you could use ~/ which would translate to the home of root, /root/, but that's a very bad idea re readability and testing etc.
[update]As noted, the issue here was 'brew' being in /usr/local/bin, which is not in $PATH Of cron, which made the command 'brew' fail, file not found. I missed that last line. But all the more reason to always use full paths. Full paths on all the programs and files will resolve all these issues.