You are not logged in.
Basically I have noclobber set to true in .zshrc... this prevents accidently overwriting files with the pipe command...
When I run the command in a console without the >! command and noclobber set to true it properly detects the file exists and fails to overwrite it.
curl http://static.die.net/earth/mercator/1600.jpg > /home/geota/geota/.worldmap
zsh: file exists: /home/geota/geota/.worldmap
Now when I exchange the pipe command to >! it properly overwrites the file when executed manually in the console... however if I have this command set in my crontab it instead of properly overwriting the file it just pipes it to a file named ! in my home directory...
# Reload Background Image
*/30 * * * * curl http://static.die.net/earth/mercator/1600.jpg >! /home/geota/geota/.worldmap && xfdesktop
I have tried a few different slight alterations to no avail such as
$(curl http://static.die.net/earth/mercator/1600.jpg >! /home/geota/geota/.worldmap)
`curl http://static.die.net/earth/mercator/1600.jpg >! /home/geota/geota/.worldmap`
Is there anyway I can get cron to excute the command and overwrite the file without setting noclobber to false?
Last edited by ugkbunb (2009-09-21 00:32:46)
Offline
Have you explicitly set SHELL=/bin/zsh in your user's crontab? It may be running the commands with /bin/sh and thus not looking at your zsh settings.
Offline
Have you explicitly set SHELL=/bin/zsh in your user's crontab? It may be running the commands with /bin/sh and thus not looking at your zsh settings.
hmm I just tried that and it had no effect. thanks though for the suggestion -- I guess it isn't so bad... I think since it is ignoring the noclobber command whether it is set or not... I can just drop the >! and leave it as >
marking this as solved
Last edited by ugkbunb (2009-09-21 00:33:03)
Offline
crontab provided by arch is dcron which is very basic:
Unlike other crond/crontabs, this crontab does not try to do everything
under the sun. Frankly, a shell script is much more able to manipulate
the environment then cron and I see no particular reason to use the
user's shell (from his password entry) to run cron commands when this
requires special casing of non-user crontabs, such as those for UUCP.
When a crontab command is run, this crontab runs it with /bin/sh and
sets up only three environment variables: USER, HOME, and SHELL.
Offline
^^
Interesting... thanks for the information! It seems if I just slap the crap in a script and execute it from cron that it runs the script and hence the enviroment that the script was written for just fine.
Offline